Setting Up Dependencies

h6. Contents

This page reviews host and service dependencies.
{toc:minLevel=4|maxLevel=4|printable=false}

h4. 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
!dependencies_1.gif!

h4. 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
!dependencies_2.gif!

h5. 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 Host{*}s using the *Add* button, and select *Save* to create the parent child relationship.
\\
\\
Figure: Parent Child
!dependencies_3.jpg|border=1!

h4. Host Dependencies

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

h5. 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
!dependencies_4.jpg|border=1!

h4. 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.

h5. 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*.
\\
\\

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

h5. 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
!dependencies_6.jpg|border=1!

h6. 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
!dependencies_7.jpg|border=1!

h5. 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
!dependencies_8.jpg|border=1!