The statement
"we believe that the underlying problem (not being notified when some checks fail/data starts missing) has been solved by the internal events both on item turning unsupported and trigger turning unknown."
from richlv is not fully true.
Yes, we can create a action when this happens.
But it the overview of data and triggers those are not shown any more.
So, if maintenance personal want to see, which parts are missing (possibly by removing hardware, because thats to original reason for SNMP status "not supported" as the OID is not present for not existing hardware) together with faults, they are not able to see, because removed from list.
Therefore, it is vital for the monitoring system to identify items and triggers, which are not working as expected (configured) and not just ignore them.
This can be either by different color or complete empty, by text, question mark (obvious the best way to signal unknown state) or similar.
Original issue: ZBX-1003.
there might be more issues on this topic, but for now this seems to be the only one still open.
indeed, internal events might be not enough - a notable case being larger organisations with multiple admin teams. notifications about unsupported items should go to various recipients, thus recreating all actions for internal events is not sensible.
We are struggling a lot without having any possibility to trigger on item becoming unsupported. I will give you a couple examples so that you can understand how important it may be.
1. We monitor linecards on some networking chassis. From time to time linecards become invisible to the chassis because of hardware or software failure. There is an SNMP OID which indicates some parameters of the linecard, but once linecard "dies" SNMP OID returns "(noSuchName) There is no such variable name in this MIB.", therefore item becomes unsupported. So currently we don't have a possibility to monitor linecard status without building an ugly cludge with external scripts.
Here how it looks snmp wise:
Linecard present:
root@zabby-proxy:~# snmpget -v1 -c* 172.27.252.60 .1.3.6.1.4.1.8059.1.2.2.1.1.1.2.1.1.9
iso.3.6.1.4.1.8059.1.2.2.1.1.1.2.1.1.9 = INTEGER: 9
Linecard got lost:
snmpget -v1 -c* 172.27.252.60 .1.3.6.1.4.1.8059.1.2.2.1.1.1.2.1.1.9
Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: iso.3.6.1.4.1.8059.1.2.2.1.1.1.2.1.1.9
2. OSPF sessions monitoring is an alike case. While an OSPF session is established we can get it's status via SNMP, but if session goes down - the OID returns "There is no such variable name in this MIB.", item turns unsupported and we cannot trigger on OSPF session being down.
The nature of SNMP design is so that OIDs regarding dynamic entities(such as linecards and ospf sessions) may appear and disappear on the device, currently zabbix is not capable of monitoring such things without external scripts.
Hi, could just add that I have some problems with this as well. We have some Dell Servers and Equallogic disk arrays. They also behave in the same "dynamic" way. If I remove a disk from the array the SNMP-OID for the disk just disapeares, and so the items and triggers just turn "Not Supported". The big issue right now is that the power-supplies work the same way, we had one of them fail a while ago, and the corresponding triggers just turned gray, completly silently. It was not until someone happened to look at the back of the servers it was noticed.
It would be very helpful if "Nodata" would work as one might expect even if the item turn "Not supported". I think that the dangerous thing is that the triggers also turn "Not supported" without warning.
I think this is the one major issue with zabbix as I can see, as triggers just turn gray without any warning and that is a big dangerous. Other than that I think it's totally awesome 
yes, yes, yes, "nodata" should also help with unsupported items :]
ZBXNEXT-1791 asks for an ability to use nodata() on notsupported items and seems to be the same thing as in this issue - closing as a duplicate.
if you had votes on this issue, please vote on ZBXNEXT-1791