Log File Monitoring with dependent items

[tcweb]

I have a master item to monitor a log file for all logs containing a keyword. This works fine.
I have dependent items setup, that do preprocessing, to use regex. If no regex match, it drops the result:


I then create triggers on these dependent items:


This appears to work, with a small (and important) exception: the detailed data reported in the problem alert is one alert behind! Let's say an alert fires at 1pm, and the data is "server A". Then another alert fires at 2pm, and the data is "server B". And a third alert at 3pm with data "Server C".

The problems page shows "ServerA" as the detail for the second alert, and "ServerB" as the detail for the 3rd alert.

It's as if the alert is pulling old values for {ITEM.LASTDATA}.

Is this not the correct approach for monitoring a log? I assume using dependent items is better than having 4-5 triggers on the master log item? (or not?)

I have been searching the forums for some examples, but have come up empty. any ideas?

Thanks,

-Tom

[cyber]

And your master item config is... ??
Can you elaborate a bit on this "I have a master item to monitor a log file for all logs containing a keyword" ?? What is "log file for all logs"?

[tcweb]

Sorry my description was not very good. My master item is very straightforward - it just uses a simple log[] with a regex to look in ONE log file, for any lines with the string "SystemMonitoring".

My dependent items then use preprocessing to use a different regex to look for keywords (severity) like "Critical" or "Warning".
the overall goal is to be able to put some less critical messages in a zabbix dashboard, e-mail some, and page (via e-mail) for the most critical.

This appears to be working...except for the situation I mention above - {ITEM.LASDATA} appears to always be for the N-1 log entry.

-Tom

[cyber]

Have you tried with {ITEM.VALUE} instead of {ITEM.LASTVALUE}?

All my logic tries to hard here.. There is a case described in docs, where you can get a latest value instead of second to last, but not vice versa.

[Brewer]

Check out this page:

https://www.zabbix.com/documentation/current/en/manual/appendix/macros/supported_by_location

Look for the section called:
{ITEM.LASTVALUE}

I believe this talks about your exact issue, specifically this part:

"When used in notifications, in some cases the macro might not resolve to the latest item value at the moment the trigger fired. For example, if an item quickly receives two values, "A" and "B", and the trigger fires for "A", notifications might show "B" as the latest value due to a slight processing delay - the latest item value changed between the time the trigger fired and when the notification was created. To avoid this, you can use the {ITEM.VALUE} macro, which resolves to the value at the moment the trigger fires, ensuring the correct value is used in the notification."

Sidenote - - - I stole my answer from this posted question: https://www.zabbix.com/forum/zabbix-...item-lastvalue

[cyber]

Check out this page:

https://www.zabbix.com/documentation/current/en/manual/appendix/macros/supported_by_location

Look for the section called:
{ITEM.LASTVALUE}

I believe this talks about your exact issue, specifically this part:

"When used in notifications, in some cases the macro might not resolve to the latest item value at the moment the trigger fired. For example, if an item quickly receives two values, "A" and "B", and the trigger fires for "A", notifications might show "B" as the latest value due to a slight processing delay - the latest item value changed between the time the trigger fired and when the notification was created. To avoid this, you can use the {ITEM.VALUE} macro, which resolves to the value at the moment the trigger fires, ensuring the correct value is used in the notification."

that is exact opposite, what is going on here... OP is getting previous value not the latest value that was aqcuired between trigger firing and action executed... And it is not a very quick update... theres 1h between events and they still get older value....

[Brewer]

I agree the example is the exact opposite... but given that they say "in some cases" and "might", insists that the opposite is true as well. Resulting in Value A taking lead of the notification triggered by Value B. That is why I posted the article.

We have no indication of the interval his Items are running at or if it's a constant read. OP's example simply has the alerts/notifications triggering an hour apart, which does not mean the Master/Dependent Items aren't set to check frequently. Unless I'm misreading something, which I totally could be!

This opens up the theory of the Items being configured to a fast interval or even a constant read, and thus receiving both results back to back would be plausible. Server A would continue to exist in the log all the way up until Server B came in. Resulting in 2 different values received "quickly".

It then goes on to state the same resolution you offered, trying {ITEM.VALUE} instead. Specifically stating that it "resolves to the value at the moment the trigger fires"; which is the resolution we are looking for.

I'm just reading between the lines but maybe I've gone too far; connecting dots that aren't there haha
------
My second thought is that if his Master Item is pulling both Server A and Server B into the same value (because both are in the log at the same time), like a list, then perhaps his Dependent Items are only pulling what's at index 0? Depending on when the log rolls, which I doubt is every hour and half but let's pretend it is for the sake of the example, Server A would drop off by the time Server C shows up. Leaving Server B and Server C to make up the new list. This would make Server B take the place of Server A at index 0 in the list. Resulting in Server B showing up for Notification C.

That theory is a stretch but I guess there is just more detail needed?

I'd be interested in seeing the full Master and Dependent Item's, the value returned by both, and the logs roll time.