How to manage host dependencies

WAS THIS PAGE HELPFUL? Leave Feedback

Overview

The use of host and service dependencies can help save resources by not running checks on/and sending notifications about hosts and services that are obviously unavailable. Dependencies allow you to control the behavior of hosts and services based on the status of one or more other hosts or services.

When a monitored device is not on the same subnet as the monitoring server, monitoring is dependent upon the intervening switches and routers. For example, if a service on Monitor3 turns red, you might think that a notification should be sent. But fortunately the monitoring system is more careful than that. If a service on Monitor3 turns red, before any notifications can be sent, the monitoring system will ping the host itself, that is to say it will ping the Monitor3 host Server2. If that host does not respond to ping then the monitoring server will ping the nearest upstream switch, Switch2. If Switch2 does not respond, the monitoring server will ping the next upstream device which would be Router 2 and so on.

In this fashion, the system walks the dependency tree in an attempt to determine the root cause failure. When that determination is made then the system will send out a single notification on the root cause failure and it will suppress notifications on perhaps hundreds or thousands of downstream services that are about to turn red and because of this blocking outage. This type of dependency relationship is called a physical dependency, because it is dependent upon the physical architecture of the network. Physical dependencies are defined in the host record using the parents directive.

Additionally, there are other kinds of dependencies. In this diagram Monitor1 could be an application server which is dependent upon a database server in a totally separate network, Monitor5. This would be called a logical dependency. Logical dependencies are defined in the host record using the host dependency directive. The following image represents dependency relationships. There is a third type of dependency called a service dependency. If one is employing an agent to monitor a given host, for example using SNMP to monitor several hundred ports of a Cisco router, an independent check of the SNMP service’s availability should be set up. For example we might want to ask SNMP on a Cisco router to return the IOS version. Then we could make all the hundreds of port checks internal to that router dependent on this independent check of SNMP functionality. That way in case the SNMP agent on the router was to stop responding we would only receive one notification, and hundreds of other spurious notifications would be automatically suppressed. GroundWork Monitor standard dependency relationships include: monitoring on upstream switches and routers, availability of port-based monitoring agents, and status of services on hosts.

Figure: Dependency Relationships

Steps

Host Dependencies allow you to suppress notifications for hosts based on the status of one or more other hosts.

Defining host dependencies

1. Select Configuration > Hosts, expand the Host Dependencies drop-down menu and select New.
2. In the Host Dependency Properties screen, select a required Dependent Host, the host that will be dependent on the master host, and select a required Master Host, the host that is being dependent upon.
   • Determine whether or not to check the Inherit Master Host Dependencies box for this to host dependency;
     Host dependencies are not inherited by default. This directive indicates whether or not this dependency inherits dependencies of the host that is being depended upon (also referred to as the master host ). In other words, if you have a master host dependency inheritance enabled (checked box), the master host is dependent upon other hosts, and if any one of those dependencies fail, this dependency will also fail.
   • Select the Execution Failure Criteria;
     This directive is optional and is used to specify the criteria that determines when the dependent host should not be actively checked. If the master host is in one of the failure states you specify, the dependent host will not be actively checked. Valid options are a combination of one or more of the following (multiple options are separated with commas); o = fail on an UP state, d = fail on a DOWN state, u = fail on an UNREACHABLE state, and p = fail on a PENDING state (e.g., the Host has not yet been checked). If you specify n (none) as an option, the execution dependency will never fail and the dependent host will always be actively checked (if other conditions allow for it to be). Example: If you specify u,d, in this field, the dependent host will not be actively checked if the master host is in either an UNREACHABLE or DOWN state.
   • Select the Notification Failure Criteria;
     This directive is required and is used to define the criteria that determines when notifications for the dependent host should not be sent out. If the master host is in one of the failure states you specify, notifications for the dependent host will not be sent to contacts. Valid options are a combination of one or more of the following: o = fail on an UP state, d = fail on a DOWN state, u = fail on an UNREACHABLE state, and p =  fail on a PENDING state (e.g., the host has not yet been checked). If you specify n (none) as an option the notification dependency will never fail and notifications for the dependent host will always be sent out. Example: If you specify d in this field, the notifications for the dependent host will not be sent out if the master host is in a DOWN state.
3. Select Add to create the new host dependency.
   
   Figure: Host Dependencies