This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Create dependency on trigger other than node down

We have several dependencies created so that when a Switch is down anything "under" it won't trigger, standard network dependency on alerts. But we also need to have the same dependency logic with regards to our Response Time alerts, is this possible?

When one of the Switch interface reaches the limit bandwidth available, which we have an alert for, pretty much everything in our network that goes through that starts to trigger alerts on slow response time which means hundreads of alerts and emails. When I look at the dependencies menu I can only see "The status of dependent child objects are UNREACHABLE instead of DOWN or UNKNOWN. Any alerts where the trigger condition includes Node status is equal to DOWN are not triggered." , does this mean it is not possible to create other dependencies other than node down ?

Thank you

  • You are correct, the dependency feature only covers node down issues.

    With some custom sql/swql you could probably cook up an alert logic that checked the dependencies and if the parent of a dependency already has a response time alert active suppress it for the downstream devices.  Probably need to do some kind of self join recursion to get it to go all the way up the tree.

  • The dependencies feature isnt going to help you for latency here, at least not directly.

    Should be able to do it, how complicated it is depends on how complicated your network is, Without custom sql/swql:

    • If everything runs through a single bottleneck you could add some logic to the alert condition so that it doesnt trigger when your bottleneck interface is highly utilized, or discards are piling up, or latency's getting higher, or all 3 in a logic group. Likely using the Advanced checkbox on the trigger condition page. (or custom swql)
    • If you've got a few possible bottlenecks you could put all those interfaces in a group or logic group and check all their statuses in the alert logic in the same way.
    • If you've got loads of fractal bottlenecks to worry about you could try and do something clever with custom properties - If a node is in a group or has a neighbour with high latency write to a variable called LatencyImpacted, clear that variable on reset. Latency alert checks for LatencyImpacted = null & latency high

    Or you go custom and write some script. Or nab someone else's if anyone's been down this path already. Sounds useful, might be something about... Probably a custom job in a decently complicated environment.

    I'd recommend adding your SLW boxes to the logic as if they're bottlenecks to stop noise if they bug out