Dependencies - Do you create your own with groups or use automatic calculations?

Hello -

We are looking at dependencies and wondering how others configure theirs. Auto dependencies look like it creates a one to one dependency while if we create a user-defined one we can create a parent with a group. The Parent to Child using a group looks like a better way to do this.

Just looking for opinions

Thanks!

Dave

Find more posts tagged with

Accepted answers

All comments

yer

Hi, that was the way I created my dependencies, I created child groups, with an automatic query on the child dependencies and exclude the parent from the child, to tie the parent/child dependency. I tried automatic, but the way I use my platform, it didn't work for me, so I opted to create them manually. And it works wonders for me eliminating unnecessary alerts, since now I only receive the alert from the parent if that is the root of the problem of course. But just to make you clear I will suggest to try automatic calculations first, because if it manually, it took take a lot of time if your environment is as big as mine is.

SW_United

Can you give an idea of what sort of Parent-Child groupings your talking about. I can think of Site > Nodes, but anything else?

martian_monster

I did create a few groups manually using the Meraki dashboard. The next ones I am going to work on setting up an automatic query to add members to groups. I will probably disable the automatic dependencies since it creates a whole bunch of one to one dependencies instead of the parent and children dependencies. Thank you!

martian_monster

I am starting out with infrastructure equipment and then will expand to my VMware Centers then location based.

The Parent was the Meraki Security device and the children I added to the group are all the other Meraki devices. If the security device goes down or we cannot get to it the rest of the Meraki items behind the security device will not alert. Hope that helps a bit.

yer

the basic one would be the firewall/router/gateway ip, child would be the switches behind or the servers, behind those firewall/router.

another option would be servers and application, you don't want to receive a false alert that the application is down, when really it is the server that is down, or like the other example above, you don't want to receive false alerts delaying the troubleshooting time of the IT staff, when really it is the gateway/firewall/router. these parent/child dependencies are good for simplify you the TS. Also refers to this article for more details: https://support.solarwinds.com/SuccessCenter/s/article/Why-should-I-use-dependencies?kbloader=1828

Technically, a dependency exists when a device or application relies on another piece of equipment to function — if that parent device goes down, anything depending on it becomes unreachable. As the article points out, if a switch goes down, all its interfaces become unresponsive, even if they’re technically still working. But since the switch (the parent) is offline, we can’t determine their true status. That’s why I set child objects as "unreachable" when configuring parent/child dependencies — it avoids confusion and ensures cleaner alerting.

yer

your welcome

ronan.tonilon

You can use automatic dependency calculations, but creating your own groups and dependencies is often necessary—especially for accuracy and control.

Automatic Dependency Calculation:

SolarWinds NPM can automatically create dependencies using:

Topology polling protocols (like CDP, LLDP, STP).
Orion Maps or Network Atlas (if you've defined relationships visually).

Pros:

Fast and easy.
Useful in well-structured, flat networks.
Automatically updates with topology changes.

Cons:

Relies heavily on accurate topology data.
May miss logical or service-based dependencies (e.g., app servers behind a firewall).
Can't reflect business logic (e.g., grouping nodes under a site or service).

Manually Creating Groups and Dependencies:

Manually created groups allow you to define:

Logical relationships (e.g., all devices at Site A).
Hierarchical alert suppression (e.g., don’t alert on access switches if the core router is down).
Service-based grouping (e.g., app-tier and DB-tier dependencies).

Pros:

Tailored to your actual network and operational needs.
Better for alert suppression (avoids alert storms).
Essential for complex or distributed networks.

Cons:

Requires more effort to set up and maintain.
Needs periodic review when topology changes.

Best Practice: Hybrid Approach

Use Case	Recommendation
Small/medium network with good topology polling	Use automatic dependencies
Complex network with multiple sites, services, or business units	️ Create manual groups/dependencies
Want full control over alert noise and suppression	️ Manual setup is strongly recommended
Combine both methods for flexibility and reliability	Hybrid (auto + manual) approach

Conclusion:

You can rely on automatic calculations, but you should create your own groups/dependencies for accuracy, alert suppression, and reflecting your actual operational structure. In most environments, manual setup is essential for meaningful and manageable alerting.

Hope this helps.