Here, we assume that you have already followed the Allowing and submitting passive checks recipe in this chapter. In this recipe, we will build on the configuration established in that recipe; specifically, we will assume that you already have a host with a service configured only to accept passive checks.

You will need to be able to install software on both the monitoring server (the NSCA server) and on the server that will submit passive checks (the NSCA client) and ideally be generally familiar with the ./configure, make, and make install process to install software from source on Unix-like systems.

You should also be able to define any necessary firewall configuration to allow the NSCA client to send information to TCP port 5667 on the NSCA server. A firewall is absolutely necessary to protect the nsca daemon from abuse.

We can set up the NSCA server on the monitoring server (in this example, olympus.example.net) as follows:

We can set up the NSCA client on the monitored server (in this example, ithaca.example.net) as follows:

If this worked correctly, you should see in the web interface that the passive check result was successfully read by the monitoring server and was applied appropriately.

The nsca daemon installed on the monitoring server is designed to listen for submitted service checks from the send_nsca client, provided the password is correct and the data is in the appropriate format:

<host_name>	<service_description>	<check_result>	<check_output>

Our example passive check took this form:

ithaca.example.net	BACKUP	0	Backup was successful, this check submitted by NSCA

Here, as with locally submitted passive checks, the check_result command corresponds to a numeric value, which is one of the following values:

Once received by the nsca daemon on the monitoring server, this is translated into a passive check result command that is written to the Nagios Core external commands file at /usr/local/nagios/var/rw/nagios.cmd and processed in the same way as a locally submitted passive check would be.

This allows us to include calls to send_nsca at the end of scripts, such as those managing backups, to immediately and automatically send a passive check result corresponding to whether the backup script succeeded.

Because of the NSCA daemon's very simple design and very basic security checks, it's important to apply a firewall policy to ensure that only the appropriate hosts can write to the NSCA port on the host monitoring system. A password, as implemented here, is a good first step, but it is not sufficient to keep things secure. Make sure you read the SECURITY file included in the NSCA sources to ensure that your configuration for the daemon is secure. Similar security guidelines apply to the installation of NRPE, as discussed in Chapter 6, Enabling Remote Execution.

To supplement this setup, it's often a good idea to also have Nagios Core check the freshness of its services. If we have a process that needs to run regularly, such as backups, we will likely want to be notified if we haven't received any passive checks from the host in a given period of time.

This can be managed by configuring the service to run an active check after a certain period of time has elapsed with no passive checks. The configuration might look like this, adding values for check_freshness and freshness_threshold:

define service {
    use                     generic-service
    host_name               ithaca.example.net
    service_description     BACKUP
    active_checks_enabled   0
    passive_checks_enabled  1
    check_freshness         1
    freshness_threshold     86400
    check_command           check_dummy!1!"No backups have run for 24 hours"
}

In this case, freshness_threshold is 86400 seconds, or 24 hours; if there have been no passive checks submitted for 24 hours, check_command will be run even though active checks are disabled. The check_command is defined to flag a WARNING state for the service with an appropriate explanatory message using the check_dummy command and plugin whenever it is actually run.

Check freshness is discussed in more detail in the Nagios Core documentation in the section entitled Service and Host Freshness Checks, which you can find at https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/freshness.html.

Note that there's no reason that the status of a service has to come from the same host. You can send a passive check from one host to submit information about another host. In fact, this is the basis of a distributed monitoring setup; one host can submit check results for any number of other hosts.