ipSentry provides a method to set devices to be checked depending on the status of another device. This feature is known as a dependency.
Say for instance that you are monitoring several web servers that reside on the other side of a critical router. There may be no need to attempt access to the web servers if you know the router is non-functioning. This presents us with an ideal case for a dependency structure where the web servers should not be checked if the router is down.
In this example, we will make a couple of assumptions.
You have already configured three web server entries for the servers WEB_A, WEB_B, WEB_C
You have configured a monitoring entry for ROUTER_A using simple ICMP-Ping.
You have configured the alert functions of each.
The only task remaining is to tell ipSentry that WEB_A, WEB_B, and WEB_C should only be checked if ROUTER_A is accessible.
To accomplish this, the following steps provide the quickest solution.
From the ipSentry active display console, select Action, Edit Devices.
Drag WEB A device onto ROUTER A
Drag WEB B device onto ROUTER A
Drag WEB C device onto ROUTER A
The above will cause the following scenario to exist.
ROUTER_A is checked
If OK then WEB_A, WEB_B, and WEB_C are checked.
Otherwise, if ROUTER_A fails, the alerts are triggered and WEB_A, WEB_B, WEB_C are skipped due to ROUTER_A failure.
This avoids having alerts generated on devices that can not be reached due to a failure in front of them in the network.This can go even a step further such that ROUTER_A is dependent on yet another device - ROUTER_B. You can then simply drag ROUTER A onto ROUTER B. This would then cause the following scenario.
ROUTER_B is checked.
If OK - ROUTER_A is checked
If OK - WEB_A, WEB_B, and WEB_C are checked.Notice that in the above case, WEB_A, WEB_B, WEB_C are only checked if BOTH ROUTER_B and ROUTER_A are accessible.
Note: The limit of nesting level of dependencies is 50 devices but the number of devices that can be tied to a parent is not limited.