Customizing an existing command
In this recipe, we'll customize an existing command definition. There are a number of reasons why you might want to do this. A common one is if a check is overzealous, sending notifications for the WARNING
or CRITICAL
states which aren't actually terribly worrisome; or, on the other hand, if a check is too forgiving and doesn't flag hosts or services as it has problems in recognizing when it would actually be appropriate to do so.
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.
Getting ready
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.
How to do it...
We can customize an existing command definition as follows:
- Change to the directory containing the command configuration files for Nagios Core. The default file is
commands.cfg
, located in/usr/local/nagios/etc/objects
:# cd /usr/local/nagios/etc/objects
- Edit the
commands.cfg
file or whichever file is an appropriate location for thecheck_http
command:# vi commands.cfg
- Find the definition for the
check_http
command. In a default Nagios Core configuration, it should look something like this:# 'check_http' command_definition define command { command_name check_http command_line $USER1$/check_http -I $HOSTADDRESS$ $ARG1$ }
- Copy this definition into a new definition directly below it and alter it to look like the following, renaming the command and adding a new option to its command line:
# 'check_http_altport' command_definition define command { command_name check_http_altport command_line $USER1$/check_http -I $HOSTADDRESS$ -p 8080 $ARG1$ }
- Validate the configuration and restart the Nagios Core server:
# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg # /etc/init.d/nagios reload
If the validation passes and the server restarts successfully, we should now be able to use the check_http_altport
command, which is based on the original check_http
command, in a service definition.
How it works...
The configuration we added to the preceding commands.cfg
file reproduces the command definition for check_http
but changes it in the following two ways:
- It renames the command from
check_http
tocheck_http_altport
, which is necessary to distinguish the commands from one another. The command names in Nagios Core, such as hostnames, must be unique. - It adds the
-p 8080
option to the command line call, specifying that when the call tocheck_http
is made, the check will be made using the TCP port8080
, rather than the default value for TCP port80
.
The check_http_altport
command can now be used as a check command in the same way a check_http
command could be used. For example, a service definition that checks whether the sparta.example.net
host is running an HTTP daemon on port 8080
might look something like this:
define service { use generic-service host_name sparta.example.net service_description HTTP_8080 check_command check_http_altport }
There's more...
This recipe's title implies that we should customize the existing commands by editing them in place and, indeed, this works fine if we really want to do things this way. Instead of copying the command definition, we could just add -p 8080
or other customization to the command line and change the original command.
However, this is bad practice in most cases, mostly because it could break the existing monitoring and be potentially confusing to other administrators of the Nagios Core server. If we have a special case for monitoring (in this case, checking a nonstandard port for HTTP), then it's wise to create a whole new command based on the existing one with the customizations we need.
Particularly, if you share monitoring configuration duties with someone else on your team, changing the command could break the monitoring for anyone who had set up services using the check_http
command before you changed it, meaning that their checks would all start failing because port 8080
would be checked instead.
There is no limit to the number of commands you can define, so you can be very liberal in defining as many alternative commands as you need. It's a good idea to give them instructive names that say something about what they do as well as to add explanatory comments to the configuration file. You can add a comment to the file by prefixing it with a #
character:
# # 'check_http_altport' command_definition. This is to keep track of the # servers that have administrative panels running on an alternative port # to confer special privileges to a separate instance of Apache HTTPD # that we don't want to confer to the one for running public-facing # websites. # define command { command_name check_http_altport command_line $USER1$/check_http -H $HOSTADDRESS$ -p 8080 $ARG1$ }
See also
- The Creating a new command section in this chapter
- Creating a new service, Chapter 1, Understanding Hosts, Services, and Contacts