Customizing an existing command_Nagios Core Administrators Cookbook-QQ阅读男生武侠网

上QQ阅读APP看书，第一时间看更新

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, 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.

Getting ready

You should have a Nagios Core 3.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 objects configuration for Nagios Core. The default location is /usr/local/nagios/etc/objects:
```
# cd /usr/local/nagios/etc/objects
```
Edit the commands.cfg file, or any file which is at an appropriate location for the check_http command:
```
# vi commands.cfg
```

Find the definition for the check_http command. In a default Nagios Core configuration, it should look similar to the following:

# 'check_http' command_definition
define command {
 command_name check_http
 command_line $USER1$/check_http -H $HOSTADDRESS$ $ARG1$
}

Copy this definition into a new definition directly below it and alter it to look similar to the following code snippet, 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 -H $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 restart

If the validation passed and the server restarted 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 commands.cfg file reproduces the command definition for check_http, but changes it in two ways:

It renames the command from check_http to check_http_alt, which is necessary to distinguish the commands from one another. Command names in Nagios Core, just like host names, must be unique.
It adds the option -p 8080 to the command-line call, specifying the time when the call to check_http is made. The check will be made using TCP port 8080, rather than the default value for TCP port 80.

The check_http_alt command can now be used as a check command in the same way as a check_http command. For example, a service definition that checks whether the sparta.naginet host is running an HTTP daemon on port 8080 might look similar to the following code snippet:

define service {
    use                  generic-service
    host_name            sparta.naginet
 service_description HTTP_8080
 check_command check_http_alt
}

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 do want to do things this way. Instead of copying the command definition, we could just add the -p 8080 or another 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 non-standard port for HTTP—then it's wise to create a whole new command based on the existing one with the customizations we need.

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
# servers that have panels running on alternative ports.
#
define command {
 command_name check_http_altport
 command_line $USER1$/check_http -H $HOSTADDRESS$ -p 8080 $ARG1$
}