4.5. Dependencies
SysOrb can maintain dependencies between checks an/or nodes, in order to limit the amount of alerts sent to administrators when faults occur. For example, when a backbone router is down, there is no point in alerting everyone that ICMP (ping) checks to all nodes behind the backbone router are failing. Dependencies allow SysOrb to "filter out" alerts from nodes that are marked as depending on other failing nodes or checks.
4.5.1. Implicit dependencies
There are both implicit and explicit dependencies in the system. Implicit dependencies are dependencies that SysOrb knows will invariably exist - they cannot be configured in any way.
The following implicit dependencies exist in the system:
-
Exported domains depend on the synchronization status between the master and the importing satellite. No remote check/node alerts are sent if the domain is not synchronized.
-
Agent Checks depend on the Agent Checkin status. No agent check alerts are sent if the agent does not check in.
The picture illustrates an exported domain, with a number of nodes. The domain synchronization has failed (marked with a red cross in the "checkin" column), and the implicit dependencies in SysOrb now cause all actual checks performed on nodes in the domain to be marked as "Dependent".
The end result is, that administrators will receive alerts on the failing domain sync, but they will not receive alerts on all nodes and checks inside the domain. This lets the administrators focus on the actual problem at hand, rather than being overwhelmed with alerts from hundreds or thousands of checks that cannot be performed (because of the failing sync).
4.5.2. Explicit dependencies
There is no mechanism in SysOrb (yet) to automatically determine relationships between checks and nodes, across a large site setup (short of the previously mentioned implicit dependencies). It is therefore up to the administrators to explicitly configure in the system which dependencies there exist between nodes and checks.
Remember, dependencies are a tool to help "filter out" irrelevant alert messages - SysOrb will function without the dependencies set up, but once set up they can significantly improve the quality of the alerts from SysOrb by limiting the number of irrelevant alerts being transmitted.
4.5.3. Simple dependency setup
In this example we will configure a dependency between an office firewall and the local LAN switch. The SysOrb Server is located on the LAN, and it follows that SysOrb cannot check the firewall if the LAN is down.
In order to keep this example very simple, we have only configured an ICMP (ping) check on the firewall and one on the LAN switch. We wish to set up a dependency so that the firewall ICMP check depends on the LAN switch ICMP check - so, if the firewall fails we will receive alerts on that, but if the LAN switch fails we will only receive alerts on the LAN switch failure, not from the firewall ICMP check (which will also fail because SysOrb cannot ping the firewall when the switch is down).
Now, we press , and choose to edit the Firewall node. Under we click the checkbox next to the ICMP check, and notice that the button at the bottom of the screen is activated.
We click the button and are now prompted to select which nodes or checks the firewall ICMP check will depend upon. We could select any domain, node or check in the domain hierarchy - we navigate to the LAN switch and simple select the LAN switch node.
That's it! We have now told SysOrb that if the LAN Switch node fails in any way, then we do not want to receive alerts from the Firewall ICMP check. If, however, the Firewall ICMP check is failing and the LAN Switch is fine, then we will receive alerts from the Firewall ICMP check (as we would expect).
Pulling the plug on the LAN switch will result in both the LAN switch and the Firewall checks failing - but because of the dependency we defined, only the LAN switch will be marked as failing. The Firewall will be marked as "Dependent" - meaning, its status is ignored because it depends on a check which is currently failing.
As seen on the screen shot above, when we unplug the LAN switch, the ICMP check on that switch fails. And the ICMP check on the firewall (which is now unreachable because the entire LAN is down), is also failing. But the firewall ICMP check is marked with a different icon; a greyed out icon with an arrow that tells us this check is depending on another check. Alerts will thus not be sent from the firewall ICMP check, only from the switch ICMP check.
4.5.4. NodeClass dependencies
Dependencies can be used in conjunction with NodeClasses as well - for a thorough description of the NodeClass concept, please see Section 4.6.
If, for example, we wish to make all ICMP checks depend on the LAN switch from the previous example, we could choose to configure the dependency on the ICMP check NodeClass rather than on each individual ICMP check. In order for this dependency to work, the ICMP checks must of course be configured via the NodeClass, rather than set up independently.
To configure a dependency on a NodeClass check, locate the check under the relevant NodeClass. Now, one can again select the check by marking the check-box, and click the button at the bottom of the screen. From there on, the dependency configuration is identical to the previous example.