Dependencies

Orion allows for two types of dependencies, implicit dependencies and explicit dependencies. Implicit dependencies are part of the Orion code and are implemented automatically. These dependencies handle cases in which objects are always dependent on high level (parent) objects. Volumes and interfaces are implicitly child objects of the node they belong to. For Application Performance Monitor, applications are implicitly children of a node status as well. In IP SLA Manager, IP SLA operations are implicit children to the status of the node at both ends of an operation.

Explicit dependencies are dependencies you define. They operate by checking the status of a parent object you have defined. If the parent object status is Unreachable or Down, the child is set to Unreachable.

Unreachable is a new status that is not propagated by Orion alerting by default, allowing for a suppression of false positive alerts. Whenever an objects parent object has failed, or is part of a larger failure, the status assignment of Unreachable to all child objects prevents a cascade of child object alerts. This is most commonly used in the case where a portion of the network is separated from the location housing the SolarWinds Platform server by a WAN connection.

Let’s consider remote site A. This site is connected to the headquarters, where the SolarWinds Platform server is installed, by two WAN connections. In site A there are several switches, servers and network users. Site A is completely dependent on the two WAN connections back to headquarters for all operations. To create a dependency which reflects this we will first create a group for the two WAN ports at the headquarters and call it Site A WAN. Then we will create a group called Site A and add all managed objects completely contained in Site A. The end of the WAN connections will be made into a group called Site A WAN. That group will only contain the two WAN interfaces at the headquarters that are connected to Site A.

Both groups will use Mixed status rollup. We go on to create a dependency for the Site A group as the child of the Site A WAN group. And then, we create an alert for Site A ensuring we are alerted when the site A group status in not equal to Up and indicate in the alert action the status of the offending managed object. This will alert when site A has an issue with any object of site A and tell us what is causing it. If the WAN connections fail to site A, the interfaces on the headquarters side will go down and we will only receive an alert that the WAN group has failed. We can insert an alert action noting that site A is now unreachable.

In an alternate solution which yields more granularity, we would group like items in Site A and create dependencies which flow from the WAN links down into Site one layer at a time. Here is what you would create to accomplish this.

• Group “Site A WAN”, containing WAN links to site A
• Group Site A Routers, containing the routers
• Group Site A Switches, containing the Switches
• Group Site A Servers. containing the Servers Then we would create the following dependencies

Parent	Child
Site A WAN	Site A Routers
Site A Routers	Site A Switches
Site A Switches	Site A Servers

Keep in mind that you can assign multiple parents by membership in multiple groups which may cause difficulties in troubleshooting dependency problems. Because of the flexibility built into these features, you may create very complex and interdependent groups and dependencies. Whenever you are creating groups and dependencies, the simplest method will be the best. Most groupings designs can be achieved with only a single layer of sub grouping.