How to create Nagios Core host and service dependencies

Nagios Core dependencies let one host or service pause checks or notifications when an upstream object is already in a failing state. They fit layered monitoring paths where an edge router, shared endpoint, or parent service failure would otherwise create duplicate alerts from every dependent object.

Dependency objects are standard Nagios Core object definitions. The master object appears in host_name and service_description, and the dependent object appears in the matching dependent_* directives. Failure criteria decide which master states block active checks, notifications, or both.

Use parents on host objects when the goal is network reachability mapping in status views. Use hostdependency or servicedependency objects when the policy should suppress execution or notifications based on a specific object state. On Debian and Ubuntu package installs, /etc/nagios4/conf.d/*.cfg is loaded from /etc/nagios4/nagios.cfg.

1. Identify the master object, dependent object, and failure criteria.

   router01.example.net is the master host in this example, and web01.example.net is the dependent host. Both hosts already have an HTTP service definition.
   Related: How to add a host in Nagios Core
   Related: How to add a service check in Nagios Core

2. Create a local object file for the dependency definitions.

   $ sudoedit /etc/nagios4/conf.d/deps.cfg

   Use a separate .cfg file so dependency policy can be validated, reviewed, or removed without editing packaged sample objects.

3. Add the host dependency object.

   /etc/nagios4/conf.d/deps.cfg

   define hostdependency {
       host_name router01.example.net
       dependent_host_name web01.example.net
       execution_failure_criteria d,u
       notification_failure_criteria d,u
   }

   d,u means the dependency fails when the master host is DOWN or UNREACHABLE. Nagios Core suppresses active checks and notifications for web01.example.net while the matching dependency side fails.

4. Add the service dependency object.

   /etc/nagios4/conf.d/deps.cfg

   define servicedependency {
       host_name router01.example.net
       service_description HTTP
       dependent_host_name web01.example.net
       dependent_service_description HTTP
       execution_failure_criteria w,u,c
       notification_failure_criteria w,u,c
   }

   w,u,c means the dependency fails when the master service is WARNING, UNKNOWN, or CRITICAL. Use n only when that side of the dependency should never block checks or notifications.

5. Validate the Nagios Core configuration.

   $ sudo nagios4 -v /etc/nagios4/nagios.cfg
   Nagios Core 4.4.6
   ##### snipped #####
   Reading configuration data...
      Read main config file okay...
      Read object config files okay...
   ##### snipped #####
   Checking for circular paths...
   	Checked 3 hosts
   	Checked 2 service dependencies
   	Checked 2 host dependencies
   	Checked 5 timeperiods
   ##### snipped #####
   Total Warnings: 0
   Total Errors:   0
   
   Things look okay - No serious problems were detected during the pre-flight check

   Nagios Core stores execution and notification criteria as separate dependency checks internally, so one servicedependency object and one hostdependency object with both criteria can appear as two checked entries each.
   Related: How to validate the Nagios Core configuration

6. Reload Nagios Core to load the validated dependency objects.

   $ sudo systemctl reload nagios4

   Ubuntu and Debian package installs use the nagios4 service name. Source installs may use a different service path or reload method.
   Related: How to manage the Nagios Core system service

7. Confirm the dependency objects reached the runtime cache.

   $ sudo grep -F "dependency {" \
     /var/lib/nagios4/objects.cache
   define servicedependency {
   define servicedependency {
   define hostdependency {
   define hostdependency {

   The cache should show service and host dependency blocks after the reload. Test notification suppression in a maintenance window or lab before relying on the new dependency policy for production alert routing.