'Nested' dependencies question

We have a bunch of remote sites we monitor, each site goes:

ISP router > Palo Alto firewall > core switch > secondary switches > servers

For each site, I setup a dependency with the PAN firewall node as the parent, and a group containing all remaining nodes (switches + servers) as the child. In case the core switch fails, do I need to create a second dependency for it, in order to avoid multiple alerts? In creating dependencies, what are the implications in selecting the whole node vs an interface (for instance the WAN interface of the firewall) as the parent?

Thanks,

Luca

Find more posts tagged with

dependency_alerts_grouping_groups_suppression_suppress

Accepted answers

All comments

-luca-

Dependencies don't seem to be working. For instance, I have a dependency for each site based on the firewall node as parent and core switch+aux switches+servers in a group as child. I still receive separate alerts for the firewall being down, then one each for all the switches. Are we supposed to do anything else other than setup a dependency? Is node as parent > group as child the right way to do this?

superfly

To answer your first questions, yes you would need to setup 2 dependencies. One with the firewall as parent, the other with the core switch as the parent.

When you get the down notifications, do they all come at the same time?

Can you show us your dependency setup?

-luca-

Yes all alerts arrive at the same time. I'll try changing polling time for nodes down in the hierarchy and report back.

jkrenzien

I recently fought a similar issue. My setup is slightly different than yours, but the logic of it should be the same

RTR > Core Switch > Other Switches > Misc Nodes

First I tried the Auto dependency which almost worked, but when it failed it was horrid. What I ended up doing was creating a group that contains all of the nodes at the lowest end. I decided to lump other switches and Misc Nodes together since separating them made no sense. I then for ease of scripting the dependacy generation and maintance I created a group with only the Core Switch in it (static assignment to reduce dynamic query overhead). Created Than created the Core Switch Group -> Site Node Group dependency.

This is how my groups looked after that:

Dep - Core Switch
- 01 Core Switch
- 02 Core Switch
Dep - Site Nodes
- 01 Site Nodes
- 02 Site Nodes

Auto dependency was able to figure out where my routers went after that so I haven't taken the time to create that level yet, but the next dependecy for me will be a Node parent to a group child.

RTR-01 > 01 Core Switch

I will be doing a similar setup with our VMs and their ESX hosts, but we have a lot of non-clustered ESX hosts. I am not sure if this will work with a proper ESX cluster, but that is atleast 6 months down the road for me. When it comes down to it you just need to find the balance between spending days or weeks creating groups and dependencies and a bit of alert spam. Yes I said days and weeks, my site node groups took 7.5 hours to create after I had scripted and optimized the script until the only thing slowing me down was NPM itself. Please let me know if this helps or if you need further clarification.

-luca-

Changing the polling worked for me. In hindsight, it make a lot of sense. I setup timing as follows:

- firewalls: 60 sec

- core switches: 120 sec

- user access switches, servers: 180 sec

Then I have created 2 dependencies per site:

dep. 1: firewall > site_group (core sw. + user access switches + servers)

dep. 2: core sw. > smaller_site_group (user access switches + servers)

all my groups are static, as we still have some inconsistencies in equipment naming. Very helpful that you can change settings such as polling on multiple nodes at once.