SURVIVOR: dependency.cf
About dependency.cf
syntax
  • Whitespace is generally ignored, unless otherwise noted.
  • boldface denotes keywords.
  • [brackets] denote optional keywords.
  • Separators (|) denote mutually exclusive keywords.
  • Comments begin with a # symbol, and may appear anywhere. Comments must be terminated with newlines.
     <name> : [a-zA-Z0-9\.+%@_-]+
     <number> : [0-9]+
  

dependency.cf defines Type I and Type II Dependencies, which prevent the execution of Checks and Fixes when specified services are in a failed status, and a Maximum Dependencies indication to prevent infinite recursion of Type II Dependencies. Dependencies are useful to prevent large numbers of alert notificationss from being generated when a more basic or underlying problem is found.

For both Type I and Type II Dependencies, when a Dependency prevents a Check from running, the state for that Check will not be updated. If the Check was previously in a failed state, it will not be rechecked until the Dependency error clears. However, alert notifications may continue to be transmitted according to the configuration. Rescheduling the Check, or acknowledging or inhibiting the service, can be used to discontinue these alerts.

When a Dependency fails, an entry is written into the Dependent Check's history log.

Type I Dependencies
syntax
     depend {
         (checks { <name> ... }
	 |all checks [except { <name> [...] }])
	 (for hosts { <name> ... }
	 |for groups { <name> ... }
	 |for all hosts except { <name> ... }
	 |for all hosts except groups { <name> ... }
	 |for all hosts)
	 on <name>[@<name>] status
     }
 

About Type I Dependencies

A Type I Dependency prevents the execution of the specified Checks (Depending Checks) on the specified set of hosts when the specified dependency Check (Dependency Check) is in a failed (ie: not MODEXEC_OK) status, either on the host being checked or another specified host, as long as that other host is in the same Group (ie: it would ordinarily be monitored with the same Check). (For hosts that are not in the same Group, use a Type II Dependency.)

Type I Dependencies do not execute in real time, rather the Dependency is based on whether or not a previous Check resulted in a failed status. If the dependency Check has not yet executed, then the Type I Dependency will not prevent the depending Check from executing.

Mutual Type I Dependencies are not permitted, as they can result in deadlock. For example, if mod1 depends on mod2, neither has an outstanding error, both are then scheduled, both fail their Checks and are put into error status, then neither will be rescheduled as each is dependent on the other, which is in a failed state.

Dependencies

  • The Depending Checks specified by the checks keyword must be defined in check.cf.
  • The Dependency Check specified by the on keyword must be defined in check.cf.
  • The hosts specified by the for hosts and for all hosts except keywords must be defined in host.cf.
  • The host Groups specified by the for groups and for all hosts except groups keywords must be defined in host.cf.
  • If a hostname is provided for the on keyword, it must be a member of the Group specified.

Type I Dependency Stanza Keywords

depend Define a new Dependency.
checks Specify the Depending Checks, those Checks that depend on the Dependency.
all checks [except] Specify that all Checks are Depending Checks, except those specified in the exception list. The Dependency Check (specified by the on keyword) is automatically excepted.
for hosts Specify the hosts for which the Dependency applies.
for groups Specify the hosts for which the Dependency applies as a list of Groups.
for all hosts [except [groups]] Specify that the Dependency applies to all hosts, except those hosts or Groups explicitly listed.
on <name>[@<name>] Specify the Dependency Check, ie: the Check whose status must be MODEXEC_OK for the Depending Check to run. If a hostname is specified, then the Dependency Check must be MODEXEC_OK for that host, otherwise for the host being checked.
status Indicate that this is a Type I Dependency.

Examples

  1. In this example, if server1 and server2 are to be checked for http, both will first be examined for an outstanding failure of ping before the http Check is run.
         depend {
           checks { http }
           for all hosts
           on ping status
         }
         
    Replacing checks { http } with all checks would make everything depend on ping.

  2. If only server2 needed to be dependent, the following could be used:
         depend {
           checks { http }
           for hosts { server2 }
           on ping status
         }
         
  3. If all hosts in the Group mroom1 depended on mroom-router being up, it would make sense to ping the router before pinging the hosts. If mroom-router is monitored by the scheduler for ping also (ie: mroom-router must also be a member of the ping group).
         depend {
           checks { ping }
           for groups { mroom1 }
           on ping@mroom-router status
         }
         

Type II Dependencies
syntax
     depend {
         (checks { <name> ... }
         |fixes { <name> ... }
	 |all checks [except { <name> [...] }])
	 |all fixes [except { <name> [...] }])
	 (for hosts { <name> ... }
	 |for groups { <name> ... }
	 |for all hosts except { <name> ... }
	 |for all hosts except groups { <name> ... }
	 |for all hosts)
	 on <name>@<name>
     }
 

About Type II Dependencies

A Type II Dependency is executed for the specified hostname prior to the execution of the Depending Checks or Fixes. The Dependency Check must return MODEXEC_OK or the Depending Checks and/or Fixes will not be run. The target host may be any host, it need not be defined in host.cf.

Type II Dependencies should be used with care. If the Dependency Check is run against a host that is not monitored by the scheduler and the Dependency Check fails, no notification of the error will be sent, since the Depending Checks will return MODEXEC_DEPEND and nothing is monitoring the source of the underlying problem.

Dependencies

  • The Depending Checks specified by the checks keyword must be defined in check.cf.
  • The Depending Fixes specified by the fixes keyword must be defined in check.cf.
  • The Dependency Check specified by the on keyword must be defined in check.cf.
  • The hosts specified by the for hosts and for all hosts except keywords must be defined in host.cf.
  • The host Groups specified by the for groups and for all hosts except groups keywords must be defined in host.cf.

Type II Dependency Stanza Keywords

depend Define a new Dependency.
checks Specify the Depending Checks, those Checks that depend on the Dependency.
fixes Specify the Depending Fixes, those Fixes that depend on the Dependency.
all checks [except] Specify that all Checks are Depending Checks, except those specified in the exception list. The Dependency Check (specified by the on keyword) is automatically excepted.
all fixes [except] Specify that all Fixes are Depending Fixes, except those specified in the exception list.
for hosts Specify the hosts for which the Dependency applies.
for groups Specify the hosts for which the Dependency applies as a list of Groups.
for all hosts [except [groups]] Specify that the Dependency applies to all hosts, except those hosts or Groups explicitly listed.
on <name>@<name> Specify the Dependency Check, ie: the Check that must return MODEXEC_OK for the Depending Check to run. The form is service@host.

Examples

  1. In this example, all servers that are monitored for http will only be checked if the fileserver holding their data is up:
         depend {
           checks { http }
           for all hosts
           on ping@webfileserver
         }
         
  2. In this example, the servers running the application widget in the Group widget1 depend on the database server db1.
         depend {
           checks { widget }
           for groups { widget1 }
           on dbcheck@db1
         
  3. In this example, the Fix restart-app is dependent on the application's keyserver running.
         depend {
           fixes { restart-app }
           for all hosts
           on keyserver@securehost1
         }
         

Maximum Dependencies
syntax
     maximum <number> dependencies
 

About Maximum Dependencies

A maximum number of Dependencies can be set to prevent infinite Dependency recursion. By default, this limit is 10 Dependencies for a single Check or Fix.

This limit only applies to Type II Dependencies because Type I Dependencies only examine existing data and so cannot loop.

Dependencies

  • None.

Maximum Dependency Stanza Keywords

maximum <number> dependencies Set the maximum number of Type II Dependencies for recursion. If set to 0, recursion detection is disabled.

Examples

  1. In this example, the maximum number of Dependencies is set to 5.
         maximum 5 dependencies
         


$Date: 2006/11/19 16:37:10 $
$Revision: 0.10 $
keywords
all checks I
all checks II
all fixes
checks I
checks II
fixes
depend I
depend II
for all hosts I
for all hosts II
for groups I
for groups II
for hosts I
for hosts II
on I
on II
status