Actions: another conception

[lostpoint]

I have an idea.
Can you add "trigger interval" parameter into action conditions?
For example, when certain service is unavailable for 5 minutes, Zabbix will try to restart it using agent; when trigger time will reach 10 minutes (restart failed to restore service), alert the respective administrator.

The system we have for this moment is total mess when you want to have different actions done for different downtimes: you have to create unique trigger for each downtime period.
And if you need to make them dependant on something unusual (for example, make "No ping over VPN tunnel" dependant on "No ping on external interface" for remote offices), you can't even use templates!

[James Wells]

Greetings,

Can you add "trigger interval" parameter into action conditions? For example, when certain service is unavailable for 5 minutes, Zabbix will try to restart it using agent; when trigger time will reach 10 minutes (restart failed to restore service), alert the respective administrator.

What you are talking about here is an escalation system. Zabbix actually had one in the 1.1 Alpha / Beta phases, but it was removed for some unknown reason. Having said that, you can actually do something like this right now, though it is a bit painful.

To make this work, you have to use time based triggers, ie

{HOST:Item_We_Wisth_To_Monitor.avg(600)}<1

This trigger will fire as soon as the item we wish to monitor fails, but we also want this one to depend on the next trigger we are going to create below. Instead of sending this one to an email action, you would send this one to a script action to try to correct the item. Obviously, you will want to use slightly better trigger check. At this point, we create a second trigger check that checks the same thing, but is a longer period, something like;

{HOST:Item_We_Wisth_To_Monitor.max(600)}<1

We will send this trigger to an email action, and disable the trigger above from firing the script action.

Hope this helps.

[lostpoint]

Currently, I'm using exactly the same scheme you're talking about.

It's *really* boring to create lots of different triggers for each parameter to monitor.

For example, there are 5 triggers for "no ping" with different periods on my current installation.

And when I need to change some host-specific dependencies for some template-inherited triggers -- I end up disabling inherited triggers and creating lots of those time-multiplied ones.

Without period-driven actions or ability to change dependencies for inherited triggers, it's real pain in the a$$.