You will need a monitoring server with Nagios Core 4.0 or newer installed. You should also have a UNIX-like target host that you intend to monitor that can run the NRPE daemon. Most modern UNIX-like systems including Linux and BSD should be able to do this. Both the monitoring server and the target host will need internet connectivity and you should already be monitoring the target host itself with a host definition to which we'll be adding service checks.

If your servers don't have a direct gateway to the internet, you can work around this by uploading the relevant files after downloading them onto a workstation, or another machine with internet access.

You should understand the basics of configuring, compiling, and installing software from source. In most cases, a simple ./configure, make, and make install will be all that's necessary and the recipe will walk you through this. You will need to have make(1) installed along with any other tools needed for the process, including a C compiler like gcc(1).

You should also have a good grasp on how hosts and services interrelate in Nagios Core, which is discussed in the recipes in Chapter 1, Understanding Hosts, Services, and Contacts, and how Nagios Core uses commands and plugins, discussed in Chapter 2, Working with Commands and Plugins. You should not need an in-depth understanding of the use of any particular plugin; the recipe will demonstrate the usage of the plugins to which it refers.

Finally, you should be able to configure any firewalls to allow connectivity from the Nagios Core server to the server being monitored with the TCP destination port 5666.

This first part of the recipe is done on the target server.

If you would like the nrpe daemon to start on boot, add an init script appropriate to your system. An example init-script is generated at ./configure time in the source directory. Versions are also generated for Debian-derived systems and SUSE systems in init-script.debian and init-script.suse respectively. Exactly how this should be done will depend on your particular system, for which you may need to consult its documentation.

This next part of the recipe is done on the monitoring server.

With this done, a new service with the description LOAD should appear in the web interface, ready to be checked, and with an appropriate status, including the load average as read from the nrpe daemon on the target host, as shown in the following screenshot:

We can see more detail about how the check was performed and its results in the details page for the service:

If the load average on roma.example.net exceeds the limits defined for the check_load command in /usr/local/nagios/etc/nrpe.cfg on the target host, the service will enter WARNING or CRITICAL states, and will send notifications if configured to do so, all in the same manner as a non-NRPE service.

The NRPE plugin and daemon are used to run Nagios Core plugins on the target host rather than on the monitoring server itself. The results of the check are then passed back to the monitoring server and recorded and analyzed by Nagios Core the same way as if the service was running a plugin on the monitoring server, for example, check_http or check_ssh.

The recipe we followed does four main things:

Like other Nagios Core plugins, the check_nrpe program can be run directly from the command line. If we wanted to test the response of the configuration we've arranged in the preceding recipe, we might run the following:

$ /usr/local/nagios/libexec/check_nrpe -H roma.example.net -c check_load
OK - load average: 0.00, 0.00, 0.00|load1=0.000;15.000;30.000;0;
load5=0.000;10.000;25.000;0; load15=0.000;5.000;20.000;0;

In this case, the state of OK and the load average values, as retrieved by check_load, were returned by the nrpe daemon as the result of the check_nrpe call.

It's very important to note that this simple configuration of NRPE is not completely secure by default. The recipes listed under See also for this recipe provide some basic means to secure NRPE instances from abuse. These should be used in concert with a sensible firewall policy.

Of course, check_load is not the only plugin that can be run on the target server this way. If we inspect the file /usr/local/nagios/etc/nrpe.cfg on the target host, near the end of the file we find some other example definitions of commands that check_nrpe will run upon requests issued from the monitoring server:

command[check_users]=/usr/local/nagios/libexec/check_users -w 5 -c 10
command[check_load]=/usr/local/nagios/libexec/check_load -w 15,10,5 -c 30,25,20
command[check_hda1]=/usr/local/nagios/libexec/check_disk -w 20% -c 10% -p /dev/hda1
command[check_zombie_procs]=/usr/local/nagios/libexec/check_procs -w 5 -c 10 -s Z
command[check_total_procs]=/usr/local/nagios/libexec/check_procs -w 150 -c 200

We recognize check_load as the second of these. Note that it already includes some thresholds for WARNING and CRITICAL alerts in its -w and -c parameters.

If we also wanted to check the number of processes on this server, we could add a service check for roma.example.net, defined like this:

define service {
    use                  generic-service
    host_name            roma.example.net
    service_description  PROCS
    check_command        check_nrpe!check_total_procs
}

This service will generate a WARNING alert if the number of processes exceeds 150 and a CRITICAL alert if it exceeds 200. Again, the plugin is run on the target server and not the monitoring server.

Another useful and common application of check_nrpe is to make remote checks on database servers with plugins like check_mysql and check_pgsql in the case where the servers do not listen on network interfaces for security reasons. Instead, they listen only on localhost or UNIX sockets and are hence inaccessible to the monitoring server. To work around this problem, we could add a new command definition to the end of nrpe.cfg on the target server as follows:

command[check_mysql]=/usr/local/nagios/libexec/check_mysql -u nagios -d nagios -p wGG7H233bq

A corresponding check that uses the check_mysql command can then be made on the monitoring server:

define service {
    use                  generic-service
    host_name            roma.example.net
    service_description  MYSQL
    check_command        check_nrpe!check_mysql
}

See the Monitoring database services recipe in Chapter 5, Monitoring Methods, for some detail on how to use the check_mysql and check_pgsql plugins.

NRPE is thus useful not just for making checks of system properties or hardware, but for any plugin that needs to be run on the target host rather than on the monitoring host.

Finally, it's important to note that the command definitions included in the default nrpe.cfg file are intended as examples; you will probably want to fine-tune the parameters for some of them and remove the ones you don't use along with adding your own.