Introduction

Service and host dependencies are an advanced feature that allow you to control the behavior of hosts and services based on the status of one or more other hosts or services. I'll explain how dependencies work, along with the differences between host and service dependencies.

Service Dependencies Overview

The image below shows an example logical layout of service dependencies. There are a few things you should notice:

1. A service can be dependent on one or more other services
2. A service can be dependent on services which are not associated with the same host
3. Service dependencies are not inherited
4. 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)

Defining Service Dependencies

First, the basics. You create service dependencies by adding service dependency definitions in your object config file(s). In each definition you specify the dependent service, the service you are depending on, and the criteria (if any) that cause the execution and notification dependencies to fail (these are described later).

You can create several dependencies for a given service, but you must add a separate service dependency definition for each dependency you create.

In the image above, the dependency definitions for Service F on Host C would be defined as follows:

define servicedependency{
	host_name			Host B
	service_description		Service D
	dependent_host_name		Host C
	dependent_service_description	Service F
	execution_failure_criteria	o
	notification_failure_criteria	n
	}

define servicedependency{
	host_name			Host B
	service_description		Service E
	dependent_host_name		Host C
	dependent_service_description	Service F
	execution_failure_criteria	n
	notification_failure_criteria	w,u,c
	}

define servicedependency{
	host_name			Host B
	service_description		Service C
	dependent_host_name		Host C
	dependent_service_description	Service F
	execution_failure_criteria	w
	notification_failure_criteria	c
	}

How Service Dependencies Are Tested

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:

1. Nagios gets the current status^* of the service that is being depended upon.
2. 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).
3. 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.
4. 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.

This cycle continues until either all dependencies for the service have been checked or until one dependency check fails.

^*One important thing to note is that by default, Nagios will use the most current hard state of the service(s) that is/are being depended upon when it does the dependeny checks. If you want Nagios to use the most current state of the services (regardless of whether its a soft or hard state), enable the soft_service_dependencies option.

Service Execution Dependencies

If all of the execution dependency tests for the service passed, Nagios will execute the check of the service as it normally would. If even just one of the execution dependencies for a service fails, Nagios will temporarily prevent the execution of checks for that (dependent) service. At some point in the future the execution dependency tests for the service may all pass. If this happens, Nagios will start checking the service again as it normally would. More information on the check scheduling logic can be found here.

In the example above, Service E would have failed execution dependencies if Service B is in a WARNING or UNKNOWN state. If this was the case, the service check would not be performed and the check would be scheduled for (potential) execution at a later time.

Service Notification Dependencies

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. At some point in the future the notification dependency tests for the service may all pass. If this happens, Nagios will start sending out notifications again as it normally would for the service. More information on the notification logic can be found here.

In the example above, Service F would have failed notification dependencies if Service C is in a CRITICAL state, and/or Service D is in a WARNING or UNKNOWN state, and/or if Service E is in a WARNING, UNKNOWN, or CRITICAL state. If this were the case, notifications for the service would not be sent out.

Service Dependency Inheritance

As mentioned before, service dependencies are not inherited. In the example above you can see that Service F is dependent on Service E. However, it does not automatically inherit Service E's dependencies on Service B and Service C. In order to make Service F dependent on Service C we had to add another service dependency definition. There is no dependency definition for Service B, so Service F is not dependent on Service B. In some cases the lack of inheritance means you're going to have to add some additional dependency definitions in your config file, but I think it makes things much more flexible. For instance, in the example above we might have good reason for not making Service F dependent on Service B. If dependencies were automatically inherited, this would not be possible.

Host Dependencies

As you'd probably expect, host dependencies work in a similiar fashion to service dependencies. The big difference is that they're for hosts, not services. Another difference is that host dependencies only work for suppressing host notifications, not host checks.

The image below shows an example of the logical layout of host dependencies.

In the image above, the dependency definitions for Host C would be defined as follows:

define hostdependency{
	host_name			Host A
	dependent_host_name		Host C
	notification_failure_criteria	d
	}

define hostdependency{
	host_name			Host B
	dependent_host_name		Host C
	notification_failure_criteria	d,u
	}

As with service dependencies, host dependencies are not inherited. In the example image you can see that Host C does not inherit the host dependencies of Host B. In order for Host C to be dependent on Host A, a new host dependency definition must be defined.

Host notification dependencies work in a similiar manner to service dependencies. If all of the notification dependency tests for the host pass, Nagios will send notifications out for the host as it normally would. If even just one of the notification dependencies for a host fails, Nagios will temporarily repress notifications for that (dependent) host. At some point in the future the notification dependency tests for the host may all pass. If this happens, Nagios will start sending out notifications again as it normally would for the host. More information on the notification logic can be found here.