Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have zabbix set with an item to monitor a log file on a zabbix client:

log["/var/log/program_name/client.log","ERROR:","UTF-8",100]

And a trigger to determine when that log file get's more ERRORs:

{Template_Linux:log["/var/log/program_name/client.log","ERROR:","UTF-8",100].change(0)}#0

This trigger gets tripped when the log file gets ERRORs the first time, but then that first trigger just sits around for ever in Monitoring->Triggers. My understanding is that the next time the server checks the value of log["/var/log/program_name/client.log","ERROR:","UTF-8",100] and sees that it hasn't changed that the trigger would go away. Obviously this isn't the case. Could someone explain why this first trigger isn't going away?

Ultimately my goal is to receive an email whenever ERRORs are added to that log file, but I would like to understand how triggers are working first.

share|improve this question
add comment

2 Answers

up vote 1 down vote accepted

The "log" agent item checks the whole log by default, you must tell it to use the "skip" mode to avoid processing of older data. Simply add a ",skip" to the end of your parameters to the log item. Check carefully this page in the documententation.

share|improve this answer
    
This was from like 3 years ago, I'm not sure that option existed back then. But I'll mark this as resolved since this seems like it would have solved the problem. Thanks! –  Mediocre Gopher Jan 17 at 17:26
    
sorry, I actually didn't notice the age of the question, serverfault gave it to me in first page probably because no voted answers were given. Indeed this is how Zabbix works from 2.0 version; worked liked you thought in 1.x While it might be useless at this point, the problem was probably in the change() trigger, which triggers everytime there's a change in output (so it would trigger even when you supposed it to detrigger). For what you wanted, you'd have better use the regexp trigger. –  stoned Jan 18 at 10:47
add comment

Both the templated item & Trigger seem OK.

  • is the item attached to that host the original templated one or did you clone it and made some changes?
  • Is the item being correctly updated? (Check Monitoring | Latest Data)?

.change(0) behaves as you'd expect, it returns 1, if the last and previous string are different.

Just for debugging sake try the following:

{Template_Linux:log["/var/log/program_name/client.log","ERROR:","UTF-8",100].last(0)}#{Template_Linux:log["/var/log/program_name/client.log","ERROR:","UTF-8",100].prev(0)}
share|improve this answer
    
Well, I kind of have the problem sorted out. Turned on Normal + Multiple True events for the trigger and that makes it trigger multiple times even if the last triggers haven't gone away, so that's good for my email alerts. The triggers still don't go away though, so the event log is gonna get filled up real quick. As far as your questions, it's attached to the original template, and it's not a clone of anything. The item is being correctly updated as well. I'm kind of scared to change the trigger at this point, the whole setup seems kind of fragile <__< –  Mediocre Gopher May 17 '11 at 15:50
    
You can clone the Trigger, temporarily disable it and experiment with some variations on the active cloned Trigger(s). Did you try using the last() and prev() functions instead of change() ? –  Joao Figueiredo May 31 '11 at 15:03
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.