You should have a Nagios Core 4.0 or newer server running with a few hosts and services configured already. You should also already be familiar with the relationship between services, commands, and plugins.

You should have Perl installed, at least version 5.10. This will include the required POSIX module. You should also have the Perl modules Nagios::Plugin (or Monitoring::Plugin) and Readonly installed. On Debian-like systems, you can install this using the following command:

# apt-get install libnagios-plugin-perl libreadonly-perl

On RPM-based systems, such as CentOS or Fedora Core, this should work:

# yum install perl-Nagios-Plugin perl-Readonly

This will be a rather long recipe that ties in a lot of Nagios Core concepts. For this, you should be familiar with all the following concepts:

Some familiarity with Perl would also be helpful, but not required. We'll include comments to explain what each block of code is doing in the plugin.

We can write, test, and implement our example plugin as follows:

We should now be able to use the plugin in a command and hence in a service check, just like any other command.

The code we added in the preceding new plugin file check_vuln_kernel can be understood in five general steps:

It also prints the status as a string, along with the kernel version number, if it was able to retrieve one.

We might set up a command definition for this plugin as follows:

define command {
    command_name  check_vuln_kernel
    command_line  $USER1$/check_vuln_kernel
}

In turn, we might set up a service definition for this command like this:

define service {
    use                  local-service
    host_name            localhost
    service_description  VULN_KERNEL
    check_command        check_vuln_kernel
}

If the kernel was not vulnerable, the service's appearance in the web interface might be something like this:

However, if the monitoring server itself happened to be running a vulnerable kernel, it might look more like this (and send consequent notifications, if configured to do so):

This may be a simple plugin, but its structure can be generalized to all sorts of monitoring tasks. If we can figure out the correct logic to return the status we want in an appropriate programming language, then we can write a plugin to do basically anything.

A plugin like this could just as effectively be written in C for improved performance, but we'll assume, for simplicity's sake, that high performance for the plugin is not required and instead we can use a language that's better suited for quick ad hoc scripts like this one; in this case, Perl. The utils.sh file, also in /usr/local/nagios/libexec, allows us to write in the shell script if we'd prefer that.

If you prefer Python, the nagiosplugin library should meet your needs for both Python 2 and Python 3. Ruby users may like the nagiosplugin gem.

If you write a plugin that you think could be generally useful for the Nagios community at large, please consider putting it under a free software license and submitting it to Nagios Exchange so that others can benefit from your work. Community contribution and support is what has made Nagios Core such a great monitoring platform with such wide use.

Any plugin you publish in this way should conform to the Nagios Plugin Development Guidelines. At the time of writing this, these are available at https://nagios-plugins.org/doc/guidelines.html.

You may find older Nagios Core plugins written in Perl using the utils.pm file instead of Nagios::Plugin or Monitoring::Plugin. This will work fine, but Nagios::Plugin is recommended, as it includes more functionality out of the box and tends to be easier to use.