Setting Up Dependencies

About Dependencies

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

Parent Child Relationships

We'll continue with discussion on setting up the different types of dependencies:

parent-child relationships (for taking physical dependencies into account during outages),
host dependencies (for taking logical dependencies into account during outages), and
service dependencies.

Parent Child Relationships may only be defined for hosts. Parent hosts are typically routers, switches, firewalls, etc. that lie between the monitoring host and a remote host . A router, switch, etc. which is closest to the remote host is considered to be that host's parent. If this host is on the same network segment as the host doing the monitoring (without any intermediate routers, etc.) the host is considered to be on the local network and will not have a parent host .

Any host definition can optionally specify a parent directive; for example: if the parent of host A goes down, host A will be considered UNREACHABLE instead of DOWN, and while a host is in an UNREACHABLE state host and service checks and notifications will not run for that host . However, if you want you can setup notifications to be sent out for hosts with an UNREACHABLE status.

Figure: Parent Child Relationships

Defining Parent Child Relationships

Select Configuration > Hosts, expand the Parent Child drop-down menu, and select New.
In the Parent Child screen, select a Parent Host from the drop-down box, select the dependent Child Hosts using the Add button, and select Save to create the parent child relationship.

Figure: Parent Child

Host Dependencies

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

Defining Host Dependencies

Select Configuration > Hosts, expand the Host Dependencies drop-down menu and select New.
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.
Select Add to create the new host dependency.

Figure: Host Dependencies

Service Dependencies

Service Dependencies are optional and allow you to suppress notifications and active checks of services based on the status of one or more other services.

A service can be dependent on one or more other services
A service can be dependent on services which are not associated with the same host
Service dependencies are not inherited (unless specifically configured)
Service dependencies can be used to cause service execution and service notifications to be suppressed under different circumstances (OK, WARNING, UNKNOWN, and/or CRITICAL states)

Before Nagios executes a service check or sends notifications out for a service, it will check to see if the service has any dependencies. If it doesn't have any dependencies, the check is executed or the notification is sent out as it normally would be. If the service does have one or more dependencies, Nagios will check each dependency entry as follows:

Nagios gets the current status of the service that is being depended upon.
Nagios compares the current status of the service that is being depended upon against either the execution or notification failure options in the dependency definition (whichever one is relevant at the time).
If the current status of the service that is being depended upon matches one of the failure options, the dependency is said to have failed and Nagios will break out of the dependency check loop.
If the current state of the service that is being depended upon does not match any of the failure options for the dependency entry, the dependency is said to have passed and Nagios will go on and check the next dependency entry.

Defining Service Dependencies

Select Configuration > Services, select Service Dependencies from the navigation tree, and select New.
In the Service Dependency Template screen, specify a Name for the template, and select a Master Service name from the drop-down box. This specifies the service being dependent upon.
- Next, select the Execution Failure Criteria;
  Execution dependencies are used to restrict when active checks of a service can be performed. Passive checks are not restricted by execution dependencies. This criteria determines when the dependent service should not be executed. If the service that is being depended upon (e.g. ssh_disk_root) is in one of the failure states we specify, the dependent service will not be executed. Valid options are a combination of one or more of the following: Okay checked fail on an OK state, Warning checked fail on a WARNING state, Unknown checked fail on an UNKNOWN state, and Critical checked fail on a CRITICAL state. If you specify n (none) as an option, the execution dependency will never fail and checks of the dependent service will always be executed. Example: If you specify Okay, Critical, and Unknown for execution failure criteria, the dependent service will not be executed if the service that's being depended upon is in either an OK, a CRITICAL, or an UNKNOWN state.
- Continue with selecting the Notification Failure Criteria;
  If all of the notification dependency tests for the service passed, Nagios will send notifications out for the service as it normally would. If even just one of the notification dependencies for a service fails, Nagios will temporarily repress notifications for that (dependent) service . This criteria determines when notifications for the dependent service should not be sent out. If the service that is being depended upon (e.g. ssh_disk_root) is in one of the failure states we specify, notifications for the dependent service will not be sent out to contacts. Valid options are a combination of one or more of the following: Okay checked fail on an OK state, Warning checked fail on a WARNING state, Unknown checked fail on an UNKNOWN state, and Critical checked fail on a CRITICAL state. If you specify n (none) as an option, the notification dependency will never fail and notifications for the dependent service will always be sent out. Example: If you specify Warning in this field, the notifications for the dependent service will not be sent out if the service that is being depended upon is in a WARNING state.
Select Save.

Figure: Service Dependency Template

Applying Service Dependencies

Service Dependencies can be applied through the Manage Service or the Manage Host Service dependencies screens.

Applying a Service Dependency through Manage Service

Select Configuration > Services, expand the Services navigation tree and select the dependent service, the Manage Service screen will be displayed.
Select the Service Dependencies tab, and select the desired Dependency template, previously defined along with a Parent Host from the list displayed or select same host if the dependency is for services on the same host. Select Add Dependency.

Figure: Service Dependencies

Apply Hosts

After making any service changes you will need to use the Apply Hosts tab to indicate the Service properties action(s) and Host services action to be taken. Please read the Apply screen carefully as caution should be taken before any actions.

Select the Apply Hosts tab. The Hosts drop-down box lists all hosts that have this service. The checked service properties actions (e.g. Apply dependencies) will be applied to the host-service on all of these hosts.
Check Service properties action(s) to apply and check Host services action to apply. Double check your service changes, the set of hosts that are assigned this service, the service properties you have checked to apply, and how you want to modify the existing host-services.
When you're ready, select Apply.

Figure: Apply Hosts

Adding a Service Dependency through Manage Host Service

Select Configuration > Hosts, select the dependent Host by expanding the Hosts navigation tree, select a Host Group, select the dependent Host, and select a Service. The Manage Host Service screen will be displayed.
Select the Service Dependencies tab and the desired Dependency template and then choose the Parent Host from the list. Click Add Dependency.

Figure: Adding a service dependency