Bug Report : Triggers not parsing properly

[spblue]

We just recently took at look at the 1.7 alpha release to see if it would help with our disk I/O performance problems. We've found a few bugs... the upgrade MySQL script for the database didn't even parse properly, but I fixed it manually.

A more serious bug is that some of our triggers stopped working. The new trigger handling code seems to fail if the time(0) function is used. For example, we monitor the state of a service that interface with our AS/400. However, due to a full AS/400 nightly backup, that service shuts down for 3 hours each night. Here was my previous trigger condition :

{Mines Wabush - PN WPWEBS02:service_state[Magic 9.4 Broker].time(0)}>030000 & {Mines Wabush - PN WPWEBS02:service_state[Magic 9.4 Broker].time(0)}<235500 & {Mines Wabush - PN WPWEBS02:service_state[Magic 9.4 Broker].last(0)}#0 & {Mines Wabush - PN WPWEBS02:service_state[Magic 9.4 Broker].last(0)}#2

Basically, four expressions with AND between each:

service state#2 AND service state#0 AND time<11:55pm AND time>3:05AM

That trigger used to work just fine. But now, when it is parsed with 1.7.2, the time(0) and last(0) values are reversed, as seen in the screenshot below. This happens no matter what order I put the expressions in too!

Maybe I'm missing something here?

[richlv]

ah, new trigger editor. maybe similar problem to https://support.zabbix.com/browse/ZBX-1316 ?
is the ordering correct if you switch to direct expression editing ?

[spblue]

Since the time(0) function isn't available (AFAIK) with the editor, that expression was typed in manually. The bug doesn't seem to be only with the editor, as the trigger does NOT work properly, while it used to. The test also fails.

Basically, this is what I get after entering the expression the old way, without using the editor.

[richlv]

tested nodata() function in latest trunk - seems to work correctly

[spblue]

The bug seems to be with time() and not nodata()

[richlv]

ah, sorry, pebkac.
tested time() in current trunk (single condition), and it also works correctly.
i'd suggest breaking down trigger expression in smaller parts and see what exactly does not work as expected

[rincewind]

Confirm bug on trunk 8387. I have this one trigger:
{CUS_OIK_Templateroc.num[Zerver.exe].last(0)}=0 | {CUS_OIK_Templateerf_counter[\Процесс(Zerver)\% загруженности процессора].last(0)}>3 | {CUS_OIK_Templateerf_counter[\Процесс(Zerver)\Байт виртуальной памяти].last(0)}>100000000
(sorry for Russian in tags body). And it represent in the new trigger editor as in attach - data items misequal to their expressions.

[richlv]

expression editor problem is a known one - https://support.zabbix.com/browse/ZBX-1316
question is, do we have another problem with the trigger evaluation as well

[rincewind]

expression editor problem is a known one - https://support.zabbix.com/browse/ZBX-1316
question is, do we have another problem with the trigger evaluation as well

I have another one bug, but Im not shure is this bug or feature... In case data items in trigger evaluation is null (one or more), it does not fires up and server log file write this lines:

 16990:20091126:095156.840 Expression [{12714}=0|{12713}>1000000000|{12712}>0|{12711}>10|{12710}>1000000000|{12709}=0|{12708}>10|{12707}>1000000000|{12706}=0] for item [22982][BE_CUS_RZA:agent.ping] cannot be evaluated: unable to get function value: lastvalue IS NULL for function [12711][BE_CUS_RZA:perf_counter[\<D0><9F><D1><80><D0><BE><D1><86><D0><B5><D1><81><D1><81>(Rel)\% <D0><B7><D0><B0><D0><B3><D1><80><D1><83><D0><B6><D0><B5><D0><BD><D0><BD><D0><BE><D1><81><D1>
<82><D0><B8> <D0><BF><D1><80><D0><BE><D1><86><D0><B5><D1><81><D1><81><D0><BE><D1><80><D0><B0>].last(0)]

As to me, it is a point to discuss what to do if dataitem is null. In my opinion it must me a trigger fire up action, may be optional. Logically, if expression is true or dataitem is null, than fire up trigger. Because in most of cases triggers is setting up for monitoring critical services and no data is critical situation. But, as I sayd before, this is point of discuss...

[richlv]

that might backfire. let's say you are monitoring 10 mounted partitions for avg(300) pfree. if you miss data for 5 minutes, all their triggers would fire...

[rincewind]

that might backfire. let's say you are monitoring 10 mounted partitions for avg(300) pfree. if you miss data for 5 minutes, all their triggers would fire...

May be option in trigger definition can resolve this collision? Something like
1. Threat NULL or no data as TRUE
2. Do nothing with no data or NULL

[richlv]

complicated, but might work. please submit this on the feature request tracker

[stefstef]

I'm still dealing with this problem in 1.8. After reading the support site, I thought this problem had been fixed. Has anyone gotten this to work in 1.8?

Kind regards
Stebbi

[spblue]

Edit: followed email link and post went into wrong thread.