LInux Debian Lenny
Mysql 5.0
Zabbix 1.6.5

Hi,

I wrote the patch. And well... it's more a quick hack to the source than a real patch.

Anyway, from a less "patchy" point of view, I would really like to be able to run .nodata() against unsupported items or have another way of detecting that a specific item has gone unsupported (.unsupported(0) ?).

That way we could detect scripts or other items returning unexpected values (or no values at all) and improve fault detection.

Currently zabbix[items_unsupported] can help you detect global changes, but this is usefull for zabbix administrators. It's not suitable for "service triggers" as you only get the global figure.

related issues :
ZBX-2877 - host going down (possibly a config issue);
ZBXNEXT-341 - alerting on unknown trigger state

It is very likely this will be addressed in 2.2.

I've looked into this and modified 1.8.14 to enable nodata() for unsupported items.
Patch highlights:

• Trigger evaluation won't fail with nodata() calls on unsupported items;
• nodata() processing for unsupported items is a bit more expensive (one additional sql query every 30 seconds on nodata re-evaluation), because we cannot rely on item's lastclock as it updates each time item tries to receive new data (successfully or not);
• Actions fire properly;
• Frontend supports and properly displays such triggers everywhere, on triggers/events/dashboard/etc pages.

Feedback is welcome.

Is this still an issue in 2.0.x versions of Zabbix?

would the internal events that allow alerting on unknown/unsupported states solve this issue ? see ZBXNEXT-1575 for more detail

One would have to still setup a separate trigger for each trigger to determine if it's gone rogue "aka not supported". It would be much nicer if the trigger itself had a way to report it was not operational rather than have to rely on another trigger. (Unless I am misunderstanding ZBXNEXT-1575)

no, you would create an action with condition "event type - trigger in unknown state" and that's it - not additional triggers required.
optionally, you may also filter by host or host group

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.

thus closing this issue.

This doesn't solve the use case where you don't want to use actions. For instance, if you have a NOC monitoring the dashboard or events page. The trigger status shouldn't stay OK, if it went to PROBLEM, this issue would be resolved.

An unsupported trigger severity would be very helpful for this.

an unsupported trigger would be awesome, not email. :[