Nagios Core Administration Cookbook: The ideal book for System Administrators who want to move their network monitoring to an advanced level. This book covers the powerful features and flexibility of Nagios Core, and its recipes can be applied to virtually any network.

Nagios Core is perhaps best thought of less as a monitoring tool, and more as a monitoring framework. Its modular design can use any kind of program which returns appropriate values based on some kind of check, such as a check_command plugin for a host or service. This is where the concepts of commands and plugins come into play.

For Nagios Core, a plugin is any program that can be used to gather information about a host or service. To ensure that a host was responding to PING requests, we'd use a plugin, such as check_ping, which when run against a hostname or address—whether by Nagios Core or not—would return a status code to whatever called it, based on whether a response was received to the PING request within a certain period of time. This status code and any accompanying message is what Nagios Core uses to establish what state a host or service is in.

Plugins are generally just like any other program on a Unix-like system; they can be run from the command line, are subject...

In this recipe, we'll follow a good procedure for finding a plugin appropriate to a specific monitoring task. We'll start by checking to see if an existing plugin is already available to do just what we need. If we can't find one, we'll check to see if we can use another more generic plugin to solve the problem. If we still find that nothing suits, we'll visit Nagios Exchange and search for an appropriate plugin there.

In this recipe, we'll install a custom plugin that we retrieved from Nagios Exchange onto a Nagios Core server, so that we can use it as a Nagios Core command and hence check a service with it.

In this recipe, we'll remove a plugin that we no longer need as part of our Nagios Core installation. Perhaps it's not working correctly, the service it monitors is no longer available, or there are security or licensing concerns with its usage.

In this recipe, we'll create a new command for a plugin that was just installed into the /usr/local/nagios/libexec directory on the Nagios Core server. This will define the way in which Nagios Core should use the plugin, and thereby allow it to be used as part of a service definition.

In this recipe, we'll customize an existing command definition. There are a number of reasons why you might want to do this, but a common one is if a check is "overzealous", sending notifications for WARNING or CRITICAL states, which aren't actually terribly worrisome. It can also be useful if a check is too "forgiving" and doesn't detect actual problems with hosts or services.

Another reason is to account for peculiarities in your own network. For example, if you run HTTP daemons on a large number of hosts on the alternative port 8080 that you need to check, it would be convenient to have a check_http_altport command available. We can do this by copying and altering the definition for the vanilla check_http command.

In this recipe, we'll learn how to deal with a slightly tricky case in network monitoring—monitoring a server that doesn't respond to PING, but still provides some network service that requires checking.

It's good practice to allow PING where you can, as it's one of the stipulations in RFC 1122 and a very useful diagnostic tool not just for monitoring, but also for troubleshooting. However, sometimes servers that are accessed only by a few people might be configured not to respond to these messages, perhaps for reasons of secrecy. It's quite common for domestic routers to be configured this way.

Another very common reason for this problem, and the example we'll address here, is checking servers that are behind an IPv4 NAT firewall. It's not possible to address the host directly via an RFC1918 address, such as 192.168.1.20, from the public Internet. Pinging the public interface of the router therefore doesn't tell us whether the host for which it...

Even given the very useful standard plugins in the Nagios Plugins set, and the large number of custom plugins available on Nagios Exchange, occasionally as our monitoring setup grows more refined, we may find that there is some service or property of a host that we would like to check, but for which there doesn't seem to be any suitable plugin available. Every network is different, and sometimes the plugins that others have generously donated their time to make for the community don't quite cover all your bases. Generally, the more specific your monitoring requirements get, the less likely it is that there's a plugin available that does exactly what you need.

In this example, we'll deal with a very particular problem that we'll assume can't be dealt with effectively by any known Nagios Core plugins, and we'll write one ourselves using Perl. Here's the example problem:

Our Linux security team wants to be able to automatically check whether any of our servers...