Ping Triggers Update
I have updated my triggers that check availability through icmpping. I have made them check the ping result for a period of time instead of a single check.
The reason for this change is that sometimes there may be a small network hiccup that makes the server lose connectivity just for a small amount of time. When that happens, Zabbix thinks the server has dropped and come back within 30 seconds and sends the appropriate notifications, possibly flooding the recipient if the problem persists.
With the change in the trigger, it is now activated only if the target is persistently offline for the amount of time specified.
The new trigger is this:
{Router:icmpping.max(120)}<1
What this does is check to see if the server has failed persistently for the last 2 minutes. If it has, then the trigger is activated.
I also specified different time frames for each type. For example, Routers need to be down for 2 minutes, Workstations for 5 and Clocks for 10. In effect, A simple reboot of a workstation isn’t likely to register as a problem.
The added bonus is that while a trigger is activated on a persistent failure of, say, 2 minutes, it is de-activated as soon as the first packet arrives, letting you know as soon as it is restored.
I guess one could make a reverse trigger, that is actually checking the network generic health. It is activated as soon as the ping fails and de-activates as soon as the connection is persistent for at least the time frame specified.
{Router:icmpping.min(120)}<1
Which means that if the minimum of the pings is 0 the trigger is activated (such as when one of the pings within the last 2 minutes has failed) but it is de-activated only if no ping within the last 2 minutes has failed.
PS: Forgot to mention that as of 1.1beta9 this trigger will not work if the icmpping is stored in an integer value, It will always return an Unknown status. This is scheduled to be fixed in 1.1beta10.
Personally, I used floats in my Simple Ping item.
