A list of "not supported" or "unknown" items and triggers...

[makini]

Hi,

As a suggestion - make a web page in UI with all the items and triggers' names that gone into "not supported" and UNKNOWN status (in addition to the count in Reports>Status page). It would also be very useful to get some alert or Action that could notify about those items and triggers.

Would be very much appreciated.

[exkg]

In windows agents is possible to use:

agent[unsupported_requests]

And in ZABBIX Server can be:

zabbix[items_unsupported]


[]s,
Luciano

[makini]

Sure, but...

In windows agents is possible to use:

agent[unsupported_requests]

And in ZABBIX Server can be:

zabbix[items_unsupported]


[]s,
Luciano

We mostly got *nix machines.
The zabbix[items_unsupported] is documented as "Number of unsupported items in ZABBIX database", not really useful - its the same number as in the Reports>Status. Names to identify those that became 'not supported' is the issue. UNKNOWN triggers were visible in the Monitoring>Triggers page in previous versions, now those are filtered and viewing "all" issues is totally cluttering the screen.

[exkg]

Hmmm ... with a ExternalCheck ?

# grep "Not supported by ZABBIX agent" /tmp/zabbix_server.log |grep <HOST> |wc -l
4111


[]s,
Luciano

[exkg]

Ok ... a little bit better:

# tail -1000 /tmp/zabbix_server.log |grep "Not supported by ZABBIX agent" |grep <HOST> |awk {'print $3'} |sort |uniq |wc -l


Its can be a ExternalCheck in a template for all *nix hosts.


[]s,
Luciano

[makini]

All true...

Ok ... a little bit better:

# tail -1000 /tmp/zabbix_server.log |grep "Not supported by ZABBIX agent" |grep <HOST> |awk {'print $3'} |sort |uniq |wc -l

Its can be a ExternalCheck in a template for all *nix hosts.

It's really not a problem to discover those items from the Server log, we do use similar ways to what you're proposing.
However, since it's the Server that discovers and disables those erroneous items and triggers (or turns temporarily "not supported") it could also notify or simply list those on a separate centralized page, or perhaps include a filter for those on the Monitoring>Triggers page. It is of course possible to make work-arounds for this but wouldn't it be the best if the system itself had some simple solution?