So far, we used plugins that are part of the standard Nagios Plugins package. It provides plugins for monitoring typical servers. IT setup often consists of a large variety of hardware and software that have to be monitored. There are many devices and services that should be monitored. In many cases, standard plugins are enough to properly monitor them, such as monitoring using PING, SSH, or HTTP.
There are, however, many applications that require more sophisticated checks, such as applications communicating over a custom protocol that can be checked using check_udp or check_tcp by specifying handshake to perform an expected response. In addition, many services require more sophisticated checks, such as verifying that the OpenVPN server performs a proper handshake, which cannot easily be done using check_udp or check_tcp—a check that it is listening can be done, but it could simply be another service running on the same port.
Monitoring IT resources often requires verifying that network services are working properly. This can be anything—a web, SSH, or FTP server, as well as many other protocols. There are also a large number of custom protocols that also require monitoring. Popular network services have a working plugin already that can simply be used; however, it is often up to us to create a check.
In many cases, it is sufficient to just use check_udp or check_tcp and check for the specific string being present. It is often enough to just check the result message, such as with the VMware server. With other services, it may also require sending a specific command.
For example, the following command definition allows monitoring Redis service (refer to http://redis.io/ for more details), which has a simple line-based protocol:
define command
{
command_name check_redis
command_line $USER1$/check_tcp -H $HOSTADDRESS$ -p 6379
-E -s "PING
" -e "+PONG" -w 1 -c 2
}
Redis is a key-value based store that is often used by server applications to store information and communicate between instances. It is commonly used for large web applications as cache or temporary data storage.
The preceding example connects to the host on port 6379 (which is the port Redis is listening on) and sends a PING command followed by newline characters, expecting a +PONG as response. The response time has to be below 1 second for the OK status, otherwise it is WARNING if it is below 2 seconds, and CRITICAL if it longer than that.
The approach can also be used to also send more complex commands, such as authenticating to Redis using the AUTH command:
define command
{
command_name check_redis_auth
command_line $USER1$/check_tcp -H $HOSTADDRESS$ -p 6379
-E -s "AUTH $ARG1$
SELECT 0
"
-e "+OK" -w 1 -c 2
}
This check will result in failure if the authentication using a specified password does not work, as the SELECT command will not return +OK unless the authentication succeeded.
Similarly, a check can be made for memcached (refer to http://memcached.org/ for more details), which is a cache mechanism often used by web applications as well:
define command {
command_name check_memcached
command_line $USER1$/check_tcp -H $HOSTADDRESS$ -p 11211
-E -s "version
" -e "VERSION" -w 1 -c 2
}
In this case, the only difference is using port 11211 (which is the default port for memcached) and sending a different command.
The standard check commands can be used for almost all protocols; however, it is a practical solution mainly for text-based protocols, since encoding binary data requires more work, and often it is easier to create a custom plugin for this—especially if a library to communicate over the protocol is available. This approach is described in more detail in Chapter 13, Programming Nagios.
There are also many cases where a simple monitoring by sending protocol-specific messages is not enough. For instance, monitoring MySQL replication status requires a dedicated plugin to properly report delays and set a warning or critical status if it exceeds the specified threshold.
In these cases, it is best to use existing plugins if they exist, or write new ones if they don't already. The Nagios Exchange at http://exchange.nagios.org/ is the best place to start looking for plugins as it is historically the first and the largest directory of additions created by the Nagios community.
The website contains a dedicated category for plugins and at the time of writing the directory contains over 3,000 plugins. They are grouped into categories based on the type of performed checks.
The category with the largest number of plugins is Network Protocols (refer to http://exchange.nagios.org/directory/Plugins/Network-Protocols), and it is over 20% of all the plugins available on the website. It contains ready-to-use plugins for various types of check, such as mail system, VoIP, file, and web protocol checks.
Nagios Exchange also has a section for databases with a lot of plugins available. It provides ready-to-use code for monitoring many types of servers, such as MySQL, PostgreSQL, Oracle, DB2, and SQLServer—some of which do not have a dedicated check in the nagios-plugins project. For many databases, there are multiple plugins available ranging from basic service check to more advanced features such as monitoring replication status and disk and memory usage. All the plugins can be found in the Databases section available at http://exchange.nagios.org/directory/Plugins/Databases.
The website provides a large number of plugins for monitoring web servers and web applications. This includes checks for common web servers, such as Apache and IIS, but there are also multiple choices for monitoring other web and application servers, such as Nginx, IIS, Tomcat, and JBoss. There are also many plugins for monitoring specific solutions, such as Fast-CGI processes, PHP-FPM (a Fast-CGI-based solution for running PHP applications with many web servers), and Passenger module (used to serve Ruby on Rails and Python/Django applications on top of Apache and Nginx). There are also different plugins aspects of monitoring web servers—number of processes, memory and CPU usage, and many more. The plugins for monitoring web servers can be found in Nagios Exchange under the Web Servers category, available at http://exchange.nagios.org/directory/Plugins/Web-Servers.
Nagios Exchange also provides a lot of ready-to-use plugins to monitor a wide range of devices and services. There are multiple plugins for monitoring various operating systems (available at http://exchange.nagios.org/directory/Plugins/Operating-Systems), network devices (available at http://exchange.nagios.org/directory/Plugins/Hardware/Network-Gear ), and network connectivity (available at http://exchange.nagios.org/directory/Plugins/Network-Connections%2C-Stats-and-Bandwidth).
Whenever using a third-party plugin—either from Nagios Exchange or downloaded from another website directly—it is important to remember security and licensing issues.
As plugins are run using the same user as Nagios itself, a malicious or erroneous plugin may be able to remove Nagios data files or other important data. It is always best to use a plugin that is in active development and preferably has its source code available. So, in case of problems, it is possible to fix them or get support from the author of the plugin.
Some plugins may have licenses that prevent them from being used in certain environments or require a license in such case. There are also cases where a plugin may depend on libraries of software that require a license for each server it is installed on. For instance, a plugin to monitor a proprietary service may require a client library to connect, which may require additional license.
It is also possible to create your own plugins, and as the plugin interface is very easy it can be done in almost any language—all that is needed is to print the result to standard output and use the appropriate exit code to indicate status. Writing own plugins is described in more details in Chapter 13, Programming Nagios.