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:
nagios-nsca
package, which runs as a server listening for connections, accepts check results from remote hosts and writes them to Icinga's processing queue.nagios-nsca-client
package, and in Windows you can use the NSClient++. The NSCA client submits the given check result to the given NSCA server.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:
host_name
is the hostname of the server, which is defined in the host definition, and on which the check is runningsvc_description
is the service description of the service check, which is defined in the service definitionreturn_code
is one of the exit codes (0
is OK, 1
is WARNING, and 2
is CRITICAL)plugin_output
is the additional information used for debugging the problemAn 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.
3.141.28.107