Logical dependencies

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

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 Monitor 3 turns red, you might think that a notification should be sent, but fortunately the monitoring system is more careful. If a service on Monitor 3 turns red, before any notifications can be sent, the monitoring system will ping the host itself, that is to say it will ping the Monitor 3 host Server 2.
If that host does not respond to ping then the monitoring server will ping the nearest upstream switch, Switch 2. 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 Monitor 1 could be an application server which is dependent upon a database server in a totally separate network, Monitor 5. This would be called a logical dependency. Logical dependencies are defined in the host record using the host dependency directive. The image above 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 services 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.

host and service dependencies

Use Case

Host dependency

Host A .100 is a load balancer, the depended-on host.
Host B .209 is one of the pool of hosts (one of many behind the load balancer).
So if Host A .100, the load balancer stops, so ceases all the traffic it would receive and distribute to the pool, of which Host B .209 is a member, making .209 dependent on .100.

Host and service dependencies

Host A .100 is the depended-on host running Service A the depended on service mysql database.
Host B .209 is the dependent host running Service B the dependent service cacti.
- Cacti is installed on this host and its configured to point to .100 for the database location, in other words it needs mysql.
This mean if Host A .100 goes down, the Host B .209 dependency is clear as it needs Host A .100 to be running or Cacti will fail.
- The host down alert will come for Host A .100 with a previously set dependency rule of don't notify about Host B .209 dependency, or even don't check if .209 is up.
This also means, if Host A .100 is running, but for some reason Service A mysql database fails or is not started up, then Host B .209 Service B cacti will not work and the service dependency is satisfied.
- You will get an alert about Host A .100 Service A mysql database is down, and you can suppress alerts from Host B .209 Service B cacti, or suppress checking for cacti running.

Configuring host dependencies

Tips

Host dependencies work in a similar fashion to service dependencies, just for host versus services.

A host can be dependent on one or more other hosts
Host dependencies are not inherited (unless specifically configured)
Host dependencies can be used to cause host check execution and host notifications to be suppressed under different circumstances (UP, DOWN, and/or UNREACHABLE states)
Host dependencies might only be valid during specific time periods

Do not confuse host dependencies with parent child host relationships. You should be using parent/child host relationships for most cases, rather than host dependencies.

Select Configuration > Nagios Monitoring > Hosts, and expand the Host dependencies options, and select New. For existing dependencies select Modify to edit.
In the Host Dependency Properties screen, select values for the following directives:
- Dependent Host: Select a required dependent host, the host that will be dependent on the master host.
- Master host: Select a required master host, the host that is being dependent upon.
- Inherit master host dependencies: Determine whether or not to check this 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.
- 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); fail on an UP state, fail on a DOWN state, fail on an UNREACHABLE state, fail on a PENDING state (e.g., the host has not yet been checked). If you specify 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 unreachable and down 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: fail on an UP state, fail on a DOWN state, fail on an UNREACHABLE state, fail on a PENDING state (e.g., the host has not yet been checked). If you specify 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 down 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.

Configuring service dependencies

Tips

Service dependencies, an optional directive, allows for the suppression of 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 does not 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, each dependency entry is checked 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

Service dependency template

You create service dependencies by adding service dependency definitions. In each definition you specify the dependent service, the service you are depending on, and the criteria that cause the execution and notification dependencies to fail. You can create several dependencies for a given service, but you must add a separate service dependency definition for each dependency you create.

Go to Configuration > Nagios Monitoring > Services, expand Service Dependencies, and select New. For existing dependencies select Modify to edit, or choose Copy to create a new dependency from an existing.
In the Service Dependency Template Properties screen, specify the following:
- Service dependency template name: Specify a Name for the template.
- Service name: Specify a master service from the drop-down box. This is the service being dependent upon.
- 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 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
  - Critical checked fail on a CRITICAL state
  - None checked, 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.
- 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 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
  - Critical checked fail on a CRITICAL state
  - None checked, 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 Add.

Applying service dependencies

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

Manage Service

Select Configuration > Nagios Monitoring > 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 following:
- Dependency: This is the previously defined service dependency template.
  Select the template that defines a master service relationship on a given host. This configuration will create a service dependency relationship on a host assigned this service name.
  To define a dependency for a service running on a different host use Configuration > Nagios Monitoring > Hosts >, and navigate to the host service Service Dependencies and determine Dependency and Master service host. Be careful to ensure that the master service is assigned to the master host definition and is included in the relevant service profiles.
- Master service host: Select the host on which the master service runs. Choose same host if the master and dependent services reside on the same host.
- Master service: This is the service referenced by the chosen service dependency.
Select Add Dependency.
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 Hosts screen carefully as caution should be taken before any actions.
Select the Apply Hosts tab, and the Hosts drop-down box lists all hosts that have this service.
- The checked Service properties action(s) will be applied to the host-service on all of these hosts.
Select the Service properties action(s) to apply.
Select the 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.

Manage Host Service

Select Configuration > Nagios Monitoring > Hosts, select the dependent Host, and select a Service. The Manage Host Service screen will be displayed.
Select the Service Dependencies tab and determine the following:
- Dependency: Select the service dependency template that defines a master service relationship on this host.
- Master service host: Select from the list a host where the master service resides.
- Master service: This is the service referenced by the chosen service dependency.
Click Add Dependency.

How to configure host and service dependencies