Misleading effect of trigger dependency on network maps

[Jurgen]

Using trigger dependency to suppress excessive event notifications is great. But when triggers are used to change host icons and link indicators on a hierarchical network map, trigger dependency becomes misleading at least.

Let's suppose that we have a central office router co-gw, a branch router branch-gw and three switches (branch-sw-1, branch-sw-2, branch-sw-3) behind the branch router. All network devices have an ICMP ping item and a trigger. Triggers of branch-sw-1, branch-sw-2 and branch-sw-3 depend on the trigger of branch-gw.

When the link between co-gw and branch-gw goes down, trigger of branch-gw changes its state from OK to PROBLEM, but the dependent tiriggers of branch-sw-1, branch-sw-2 and branch-sw-3 remain OK in full accordance to Zabbix documentation. As a result, on a network map all three branch switches are OK, which is definitely not true.

Would not it be more logical make trigger dependency work in the opposite to the current implementation?

[kwilliams]

Hi Jurgen,

Just curious if you found a fix or work-around for this. We've been setting up dependencies between our devices to help alleviate the amount of emails hitting our NOC but they typically reference the maps/screens to see the live situation.

[steve.destivelle]

Hi Jurgen,

What is the configuration of the trigger for the different link ?

Maybe you should adjust the link status with the trigger of the host that is on the left on your map.

And then you should have your 3 links in Problem state because of the status of the Gw.

Regards.

[steeladept]

Actually, they ideally would go into a new state - unknown. Maybe in another color - blue maybe - to identify it as unknown rather than good or bad.