How to use Dependencies/Groups to reflect Parent/Child in Alerting

I think *maybe* I understand uniswtc? You need to have a single item be the "head parent", otherwise the rest doesn't get suppressed.

So it has to be parent (1 object)-> child (many). The object can be a group or a node or whatever, but until that parent is down the child won't suppress alerts. That's a dependency thing. Or my version is router (to WAN connection) -> child nodes (all switches on site). So if the router goes down, all the switches don't alert. This works the same with servers.

If you have a child that has TWO parent objects, it's not going to go down when one of the parents go down. Make sure your dynamic groups that are parents don't pull in multiple things that can be a parent elsewhere.

AKA: don't have an "ALL NODES" group that also is a dependency in addition to site specific dependency, because the site will never get unmanaged.

Also pick a parent node and a child node and check the dependencies for each to be sure that's the case (there's a component you can add to the pages with node details to see "all dependencies for this node" or some equivalent IIRC.

All comments

mprobus

I do not currently have anything like this set up. It sounds like it would need to be done with some type of SQL / SWQL query (possibly complex alerting). Unless someone else already has something set up, then challenge accepted!

mrxinu

I'm a little confused by the question because you already used the terms "groups" and "dependencies" so it sounds like you know that's what you need. Are you looking for help automating it? Setting it up? Planning it out?

I think *maybe* I understand uniswtc? You need to have a single item be the "head parent", otherwise the rest doesn't get suppressed.

AKA: don't have an "ALL NODES" group that also is a dependency in addition to site specific dependency, because the site will never get unmanaged.

Define and use dependencies in Orion NPM - SolarWinds Worldwide, LLC. Help and Support

I think this is what you are after and if so it is Very worth while doing
Stops alot of 'Noise' and hence allows you to see the problem quicker and hence resolve it quicker

There is also An auto dependencies feature which works very well. The main reason I go through the manual setup is to get the mindset.

Create dependencies between network objects automatically

HTH

@Steven Klassen - Yes, Some automatic dependencies were created and Groups were created. I got confused how to used them in an alert. When I tried to search in alerting rule, I could find a group based fields, but not the dependencies. The only confusion for me is how to use the dependencies.

Based on the suggestion from designerfx, I would try with a group having only 2 devices, with 1 parent.

I am looking the help how to write or use the dependencies/groups in the alert rule to test it.

designerfx - Thanks for the details information with suggestions. The only thing I got confused how to use the dependency in the alert rule.

I would create a new group with the child devices (max 2) and the parent, I need to create under dependency with these 2 devices, right? Then I can use the group status in the alert rule? Please correct my understanding. As per rhidians, I would like to go with manual creation for better understanding.

We have a site with 2 Routers and other devices like Access Points, Switches and Servers. As per your suggestion, I would go with one router and the 2 devices belong to them for testing.

So, please guide me what fields I have to use in the alert rule, Group Status (Node)? I could see a Child Status field is also available. These 2 fields are enough or any other field which would help and make easy to check the Parent/Child status.

Many thanks,

Naren.

uniswtc the alert rule is that you're alerting on down nodes. If you want to take it a step more granular you can use a custom property on the related nodes. You can simply alert on node status down, because if the parent node goes down the child node's alerts will be suppressed as they'll be marked unreachable. This requires you to go into manage dependencies and create the dependency to do this. You can have as many child nodes as you want, you just have to have a single parent at the top and not include the parent in the child group. This part is basically up to you how you logically define it

agusst

I have the type of thing setup for all my remote sites..

The second link in RhidianS post is basically what I did....although I didn't follow this particular document, I fumbled my way though it and ended up with the same thing. I set it up a couple years ago and it's been great when we have remote site outages in terms of not being spammed with alerts.

I have been extremely unwilling to test out auto dependency. I thought once you turn it on it immediately makes the new dependencies. Does it work without doing that now or do you have to sort all the auto dependencies first?

Well lets take a step back and then go one step further. My approach to a new installation is as much about getting people to understand the Orion platform as it is the individual modules. So here is the way I go through a fresh install.

Before starting I like people to start thinking about Logical containers (it's how I describe custom properties to people new to Solarwinds). How to reflect the enviroment to be monitored. And this means thinking about how to apply custom properties. Not an easy concept as it can be reflected in so many ways with the versitility of custom properties. So it's not uncommon to start with locations as the first basis.

Locations can be as simple as country / county / city. Or building / floor / cabinet. It really doesn't matter what at this stage, it matters to get people to start thinking that way even before the install. Then once they have started down that path:

1) Get the nodes in and go through the pain of identifying the critical interfaces (esp the interfaces that link the core infrastructure)

2) Assign the custom properties to the nodes and use them in the Node list resource is the first reflection

3) Use the custom properties in Dynamic queries, it will save alot of managing the system later. And the queries will create the groups.

4) From there I go to creating Maps for the Groups (What ever you named the Groups, use that as the map name and on the group maps edit the the resource and set the Maps to use the ${Name} (It could be caption, not sure) variable and the maps will drop onto the right group page.

At this stage it's easier to see the edge nodes for connecting the Maps and hence what to use for the Dependencies.

(it's also easier to go through selecting the correct interfaces for the Network Atlas Connect now feature)

5) Back in Groups create an exclusion for the edge devices and create a parent group with the edge devices. It easier to start with one device, but can be done with 2 or 3, just be wary of the logic as more things in the parent group the more complex the logic

6) Then in the Manage Dependencies set the Child group to be dependant on the Parent group to make the dependency itself.

Now if an Group goes down you will get a group down alert. Fair enough. And an alert from the node / nodes in the parent group, but the system will automatically upress all the child nodes. No need to alter the alert logic.

I'm not going to pretend that this can be alot of work and it really is only a starting point at this stage, but I find it helps to take people through these steps to see how things hang together and then we can start to build on the basics an go further like fleshing out the modules (IP groups for NTA, Assigning templates and having the server locations already there, putting the correct nodes in NCM and setting up back up and inventory jobs etc

It's certainly not the only way, just a way of doing things and one of the aims is to keep the management overhead down. To much Management overhead and the new monitoring systems can be to vocal and apathy sets in and that don't lead to good use

I realise I have taken a wider approach to the topic in the thread but felt it may just give some context to setting up the dependencies

Cheers

PS I wrote this late last night and forgot the final step. Kind of important!

They work well, I just like to know what is being suppressed and with auto dependencies I don't find it easy going through all the indivdual dependecy that are created.

Hi,

I have created a group with 2 VMs of the same site and created a dependency of a Switch as a Parent under the via Manage Dependencies. Here, the 2 VMs are under the that Switch. When I selected the parent and clicked on "Alerts on Child", it shows as below. In the Parent, chosen the group I have created.

As per the below screen shot, no need to crate a separate alert rule for the Switch, right. When the existing Node down alert rule creates an alert for this Switch, then no alert will be generated for the 2 VMs in the Group.

If my understanding is correct, I think I am on it . Please confirm.

Thanks,

Naren.

Hi Rhidian,

Thanks for the detailed write-up, which definitely helps .