How can I extend Nagios to implement custom monitoring?

BKJIA featured Translation: The powerful Nagios network monitoring platform allows you to add a series of available plug-ins for its features. If you cannot find a plug-in that meets your own requirements, you can easily write it on your own. This article describes how to compile the plug-in on your own.

The Nagios plug-in can be written in any programming language as long as it is supported on the platform running Nagios. Bash is a popular language used to compile Nagios plug-ins, because it is powerful and easy to use.

Every valid Nagios check performed by the plug-in) generates a number to indicate the exit status. Possible statuses include:

• 0 -- all items are normal, and the check is successful.
• 1 -- the resource is in the warning status. It's not a good place.
• 2 -- the resource is in critical state. The reason may be that the host is down or the service is not running.
• 3-Unknown Status, which does not necessarily indicate a problem, but indicates that the check does not provide a clear and clear status.

The plug-in can also output text messages. By default, the message is displayed in the Nagios web interface and Nagios email alert information. Although messages are not hard-coded, you can still find them in available plug-ins, because messages tell users what is wrong and do not force users to view the instructions.

A simple Nagios plug-in written in Bash is similar. This example plugin checks a specified file:

#!/bin/bash

# Specify the first real parameter $1) as the file name

filename=$1

# Check whether the file exists first. This is the first check you should start and the most basic check.

if [ ! -e $filename ]; then
echo "CRITICAL status - file $filename doesn't exist"

Exit 2 # Return the critical state because your worst case is that the file does not exist at all.

# If the previous condition exists through the file), check whether the file is readable:

elif [ ! -r $filename ]; then
echo "WARNING status - file $filename is not readable."

Exit 1 # The warning status is returned because the status is better than that of a non-existent file;

# If the previous condition passes, check whether it is a common file instead of a directory or a device file.

elif [ ! -f $filename ]; then
echo "UNKNOWN status - file $filename is not a file."

Exit 3 # unknown status is returned;

# If all the above checks are passed, it indicates that it is normal:

else
echo "OK status - file is OK"
exit 0 #Return OK status
fi

Note # In Bash) Explain the Code; if you need a clearer explanation or want to learn more about the Bash file test operator, refer to the instruction document http://tldp.org/LDP/abs/html/fto.html ).

Although this instance is simple, it clearly shows how to implement the Nagios plug-in logic. Always look for the worst case. The status is normal only when the script exits when all checks are passed. Make sure to specify a clear message before exiting.

Use plug-ins

By default, all Nagios plug-ins are stored in the directory defined by the $ USER1 macro command, which is defined in the file/etc/nagios/private/resource. cfg. $ USER1 is defined as/usr/lib/Nagios/plugins in a typical nagios installation environment from the EPEL repository http://fedoraproject.org/wiki/EPEL. The first thing you should do for the plug-in is to copy it to the directory defined by the $ USER1 macro command. The plug-in is usually owned by the root user, and the permission is set to 755. Nagios works under nagios, a user in the nagios group. Therefore, the script must have the permission to read and execute other groups.

Once you put the script in the/usr/lib/nagios/plugins directory, You need to define it as the nagios Command in the/etc/Nagios/objects/commands. cfg file. Suppose you name the script check_file.sh and add the following command definition:

# Our custom file check command:

define command{
command_name    check_file
command_line    $USER1$/check_file.sh $ARG1$
}

This should be quite clear. The variable $ ARG1 $ indicates the first real parameter passed to the Nagios Command. In this example, the first real parameter is the file name. If you want to pass more real parameters, you can use $ ARG2 $ as the second real parameter, $ ARG3 $ as the third real parameter, and so on.

To start using your plug-in, define it as a service in your nagios configuration file, such as service. cfg:

define service{
use                             local-service
host_name                       localhost
service_description             Check the file /etc/passwd
check_command                   check_file!/etc/passwd
}

The above service is defined for the local host host_name localhost), use the local-service template for the local service), see the object inheritance part of the civilized document http://nagios.sourceforge.net/docs/3_0/objectinheritance.html ), you can understand how templates and templates work. The most important part is the check_command command. It specifies the command check_file, followed by the exclamation point used as the separator, followed by the file name used as the real parameter. If your plug-in has more than one real parameter, you can separate it with another exclamation point.

Remotely run the Nagios plug-in

One obvious drawback of the example check_file plugin is that it runs locally, which means that the file on the remote server cannot be checked. You have many ways to solve this problem.

The first method is to remotely execute code using ssh commands. This requires you to copy the script to a remote server and use ssh to run the remote command function. You also need to configure password-less key login for the Nagios server and its nagios users. If you are not sure how to perform this operation, refer.

The advantage of this first method is that you have the functionality and flexibility to run commands locally on the monitored server. The disadvantage is that the Nagios server must be able to log on to the remote server without a password using the secret. This is a security issue and is not recommended for sensitive environments.

The second safer method is to use the SNMP Extension function. This requires that you have installed and configured the net-snmp package for CentOS on the remote server ).

To use the SNMP extension command, first copy the check_file.sh script to the remote server. For example, you can put the script in the directory/usr/bin.

Next, add the configuration command extend check_passwd_file/usr/bin/check_file.sh/etc/passwd to the file/etc/snmp/snmpd. conf on the remote server. The syntax is extend some_alias command argument. The following are the main inconveniences of this method: You have to define an alias for each independent check. In this example, this means defining an alias for each independent file we want to test, because real parameters cannot be transmitted through SNMP.

If the file/etc/snmp/snmpd. conf changes, you must use the service snmpd reload command for CentOS) and reload the snmpd service. Then you can test the new check with the snmpget-v2c-c public-OvQ 10.0.0.2 NET-SNMP-EXTEND-MIB: nsExtendOutputFull. \ "check_passwd_file \" command. In this example, the snmpget command uses the SNMP Version 2c to query the server 10.0.0.2 using the "public" shared string. The object identifier OID for the custom SNMP extension command) is the NET-SNMP-EXTEND-MIB: nsExtendOutputFull. \ "some_alias \".

Unfortunately, the above command cannot be directly implemented using Nagios. If snmpget works normally, it can be connected to the remote host. It always returns the status 0, indicating that everything is normal, because the program snmpget itself exits without errors. Therefore, even if a file does not exist, the script will return the status 0, but it will output the correct message that the file does not exist.

You can solve this problem by taking full advantage of the special plug-in called check_snmp_extend.sh for Nagios. After obtaining the first word of the status message, this plug-in sets the status based on the word. As this plug-in is expected, we have set messages in the sample script check_file.sh to start with OK normal), CRITICAL), WARNING), and UNKNOWN.

To start using the check_snmp_extend.sh plug-in, first download the plug-in http://www.logix.cz/michal/devel/nagios/check_snmp_extend.sh), and then put it to the Nagios Server Directory/usr/lib/nagios/plugins $ USER1 macro command ). On CentOS, You have to edit the script check_snmp_extend.sh and set/usr/local/nagios/libexec/utils. change sh to/usr/lib/nagios/plugins/utils. sh, this is utils. the correct path of the sh script.

Then, you can use check_snmp_extend.sh as with any other plug-in. First, define it as a command:

define command{
command_name check_snmp_extend
command_line $USER1$/check_snmp_extend.sh $HOSTADDRESS$ $ARG1$
}

Then, define a service:

define service{
use                 generic-service
host_name         somehost.example.org
service_description Check For /etc/passwd
check_command  check_snmp_extend!check_passwd_file
}

The extension options of SNMP are as secure as your SNMP configuration. This method only requires a few changes on the remote host, and ensures that the standard setting Environment meets the best security practices. You can find other Nagios plug-ins for similar purposes, such as nrpe, but they require remote installation of additional services, which is not always a good idea in terms of security and compatibility.

As you can see, it is easy to use self-compiled plug-ins to expand Nagios. Nagios allows this extension, which is one of the reasons why many administrators prefer it, rather than other monitoring solutions.

Original article:Http://www.openlogic.com/wazi/bid/256126/how-to-extend-nagios-for-custom-monitoring