Checks that are run by the remote hosts themselves and the status is submitted to the Icinga monitoring server are classified as passive checks. In simpler terms, Icinga does not actively execute the checks; it just sits and waits for hosts to submit the check status periodically.

While active checks are a sure way of getting up-to-date status of the services, passive checks are useful in many cases to offload a part of the monitoring to the remote servers themselves. Also, passive checks are often used to monitor only the private services; it does not make sense to check for the network (public) services on servers themselves. External reachability and status should be checked by the monitoring server only.

We need to ensure two things in configuration to enable passive checks:

We would need to have service definitions for passive checks in the same format as we have for other usual checks, with just one added directive as noted previously. Although Icinga won't do anything about the passive checks, but it needs to know that it should expect the check results for that service—hence the service definition.

We also require agents to be deployed on both Icinga and remote servers. The following are the required agents:

The remote server executes the check script periodically, using cron jobs (for Linux) or Task Scheduler (for Windows) or when a relevant event is triggered. Then, it executes the send_nsca command, provided by the NSCA client package, that takes a string from standard input in the following format and sends it to the Icinga server to report the check results:

<host_name>[tab]<svc_description>[tab]<return_code>[tab]<plugin_output>[newline]

In the preceding line, the description of the parameters is as follows:

An example of this is given in the next section.

The NSCA client, which is called by the remote scripts, submits the check results by connecting to the NSCA server. Then the server forwards the check results to Icinga after doing some basic validation.

Let's look at an example configuration for adding a passive check to monitor whether /home exists on server1.example.org:

define service {
  use                     generic-service
  host_name               server1.example.org
  service_description     Data
  active_checks_enabled   0
  normal_check_interval   30
  check_command           check_dummy!2!Check result not received
}

Note that the template service generic-service has both active_checks_enabled and passive_checks_enabled set to 1, so we need to set the former to 0 in order to make it strictly a passive check. The script on the remote server is to be run every 30 minutes, so we set normal_check_interval to 30. Also, we use check_dummy in the check command to make the check fail if check results are not submitted within the last normal_check_interval minutes. This is done to make sure of the freshness of the present check status. See the help section of the check_dummy check plugin to know its usage.

The check script to check for existence of a directory, which will be run on the remote server, is as follows:

NSCA_HOST="icinga.example.org"  # Icinga server running the NSCA server
NSCA_CONF="/etc/nagios/send_nsca.cfg"

if [[ –d /var/data ]]; then
    ret=0
    output="/var/data exists"
else
    ret=2
    output="/var/data does not exist"
fi

echo "server1.example.org	Data	$ret	$output
" | /usr/bin/send_nsca –H $NSCA_HOST –c $NSCA_CONF

This check script is run as a cron job on server1.example.org and will keep submitting check results every 30 minutes. Note that server1.example.org and Data in the echo string passed to send_nsca should match the host_name directive in the host definition and the service_description directive in service definition respectively.