How to configure a time delay between trigger dependencies?

[pzn]

Hello,

I need advice about how to configure trigger dependencies with some sort of "time delay".

This is the network topology:

• Zabbix - internet - router1 - many devices (about 200 devices)
• Zabbix - internet - router2 - many devices
• ...

The devices are simple low-end micro-controlled devices that send telemetry information via "Zabbix trapper" every 5 minutes. They "sleep" between sending the traps, so I can't ping them.

Routers are monitored via Zabbix-agent.

I have these triggers configured:

• TriggerA: nodata(/deviceX/someinfo,1200)=1
• TriggerB: nodata(/routerX/ping,900)=1
• TriggerA depends on TriggerB

Then suppose the following timeline (hour:minute):

• 10:00 traps received from all the devices
• 10:05 traps received from all the devices
• 10:10 traps received from all the devices
• 10:11 network is down at router1
• 10:26 TriggerB -> notification "host is down" for router1
• All OK here, since triggerA depends on triggerB, I won't receive 200x notifications for all devices down
• 11:01 network is up at router1
• 11:01 TriggerB solved -> notification "host is down RESOLVED" for router1
• 11:02~11:04 zabbix generates about 200x TriggerA notifications (for every device)
• 11:05 traps received from all the devices, zabbix generates about 200x TriggerA RESOLVED notifications

How can I solve this scenario?
Should I use another function instead of "nodata()" at the trigger?
Can I set up a "time delay" that keeps TriggerA "in standby mode" after some minutes that TriggerB gets solved?

Thanks in advance,
Pedro

[tim.mooney]

First, you don't say what version of Zabbix, which is always good info to include.

There are two general approaches to setting up a notification delay:

1. modify your actions or use escalations so that even though the problem is still detected quickly, the notifications don't happen immediately. If the issues resolves before the notification action would happen, then there's no notification
2. modify your triggers so that they delay generating a problem event until something has happened for longer. In some ways this makes Zabbix less "sensitive" -- brief problems that resolve themselves won't show up as problems in the web interface or elsewhere.

In your specific case, you don't say how frequently you check the routers that are part of the intermediate network topology. In my experience, even if you only need to check your "leaf" devices every 5 or 10 minutes (or they only report in on that frequency), it still makes sense to check your topology devices more frequently. This can reduce but not eliminate these kinds of false positives when the real problem is between Zabbix and the leaf device.

For your specific case, you might want to try something like

min(/routerX/ping, 900) < 1

for Trigger B. With your current nodata() TriggerB, the problem for TriggerB will clear as soon as data is received. With min(), it won't clear until every value in the given time period is no longer < 1. Your topology devices will stay in the problem state longer, which hopefully gives your leaf devices time to start filling in the data that was missing.

[pzn]

Hi Tim,

More question details, to someone that would search this topic in the future: Zabbix 6.0.13 / I ping the routers every minute.

Your answer rocks! Now I have all the information needed to solve the problem! Thanks!