Receiving notifications for UNKNOWN events?

[andrewd]

Do you have any triggers that you definitely know are in unknown state?

As a test you can create a item the checks the size of a test file, then add a trigger that check if the size is greater than a certain amount. Delete the file and the trigger will go into unknown state.

You could then go straight to the database and run the statement

 select h.host, t.description, i.key_ from items i left join hosts h on i.hostid = h.hostid left join functions f on i.itemid = f.itemid left join triggers t on f.triggerid = t.triggerid where t.status=0 and t.status=2 and h.status=0;

I'm just trying it now and it seems to be reliable. Filtering by items in error (i.status=3) should have given the same results but it doesn't. Using t.value=2 (which I looks like triggers in error) works better.

[andrewd]

I'll run some more tests. There are minor differences between the results from the sql statements. Just need to figure out why...

[andrewd]

The script is designed to detected triggers that cannot function because their associated items are in unsupported state (item.status=3).

So far I've seen one case where a trigger can have trigger.value=2 when the item is ok. I have also found several disabled triggers that have trigger.value=2. At this point, it doesn't look like trigger.value alone is enough to set the status to unsupported.
Have you found any triggers that are listed as unknown in the GUI and don't have a corresponding item that is unsupported?

[vpaul]

I would agree with you, not enough. But my concern for now is items in unknown state.
For instance, I have bunch of snmp triggers but if it fails to get the snmp info for a reason the state switches to unknown. Mostly I should process somehow triggers like these and looks trigger.value=2 helps this way.

[andrewd]

Well I have this template installed running at my staging box at work and so far it's detected all unknown items. I'll should be working with some SNMP hosts later this week so I'll post an update when I'm done.

[vpaul]

OK. Thanx. I've double checked the db and in my case t.status=0 for my unknown triggers but t.value=2. Not sure if it is snmp triggers make sense but would be nice to get your update.

[andrewd]

0.52 is working for SNMP hosts

Hi vpaul,

I've tried these latest templates (0.52) with some SNMP hosts and it works fine. It shouldn't matter how the check is performed because the script is not aware of the method, just the status of the item.

Do you have the right template applied to the SNMP host?

The monitored host should have 'Template_unsupported_items' and the zabbix server should have 'Template_unsupported_items_collector'. The script is run only by the zabbix server.

[vpaul]

Hi andrewd,

yes, I have templates set correct. I don't think templates make sense but sql query. My fix for unknown items works just fine for me. I've upgraded zabbix to 1.8.5, btw.

[scottmace]

Separate mysql server

I imported these templates on a different Zabbix system at work and I discovered that my previous testing didn't properly handle hosts that didn't have Template_unsupported_items applied. I've fixed this.

Note that you may have to change the 'Allowed hosts' for all items in Template_unupported_items to the LAN IP address of your zabbix server. 127.0.0.1 doesn't for all installations.

I've noticed that the very first time you add the template to a host, the 'collector' item (which runs on the server only) may report an error. Not exactly sure why this is but it clears on the next check.

So how does this work if the Zabbix server and DB server are different boxes?
EDIT: Nevermind, I edited this line:
my $dbh = DBI->connect('dbi:mysql:zabbix',$dbUser, $dbPassword)
to look like:
my $dbh = DBI->connect('dbi:mysql:zabbix:<ipaddress>:3306',$dbUs er, $dbPassword)

Running it from command line gives:
Info from server: "Processed 0 Failed 16 Total 16 Seconds spent 0.001969"
sent: 16; skipped: 0; total: 16

[andrewd]

The most likely cause is the value in 'Allowed Hosts' in items under Template_unsupported_items. It's set to 127.0.0.1 by default. Try changing this to the IP of your zabbix server.

[scottmace]

Yep, that was it This is very useful, thanks for putting it together. This, along with the new 1.8.5 internal checks, I'm able to finally get this running like a well oiled machine.

[andrewd]

Thanks, glad it works for you

[pdwalker]

Perfect!

Yes, wonderful piece of work.

Knowing what things are unsupported is VERY helpful.

Thank you.

[andrewd]

Thank you!

[pdwalker]

related zabbix feature request

...for those interested in following this request:

https://support.zabbix.com/browse/ZBXNEXT-341