Creating a new command_Nagios Core Administrators Cookbook-QQ阅读男生都市网

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

Creating a new command

In this recipe, we'll create a new command for a plugin that was just installed into the /usr/local/nagios/libexec directory on the Nagios Core server. This will define the way in which Nagios Core should use the plugin, and thereby allow it to be used as part of a service definition.

Getting ready

You should have a Nagios Core 3.0 or newer server running with a few hosts and services configured already, and have a plugin installed for which you'd like to define a new command. This will allow you to use it as part of a service definition. In this instance, we'll define a command for an installed check_rsync plugin.

How to do it...

We can define a new command in our configuration 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:
```
# vi commands.cfg
```

At the bottom of the file, add the following command definition:

define command {
    command_name  check_rsync
 command_line $USER1$/check_rsync -H $HOSTADDRESS$
}

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 passes and the server restarts successfully, we should be able to use the check_rsync command in a service definition.

How it works...

The configuration we added to the commands.cfg file defines a new command called check_rsync, which defines a method for using the plugin of the same name to monitor a service. This enables us to use check_rsync as a value for the check_command directive in a service declaration, which might look similar to the following code snippet:

define service {
    use                  generic-service
    host_name            troy.naginet
    service_description  RSYNC
 check_command check_rsync
}

Only two directives are required for command definitions, and we've defined both:

command_name: This defines the unique name with which we can reference the command when we use it in host or service definitions.
command_line: This defines the command line that should be executed by Nagios Core to make the appropriate check.

This particular command line also uses two macros:

$USER1$ : This expands to /usr/local/nagios/libexec, the location of the plugin binaries, including check_rsync. It is defined in the sample configuration in the file /usr/local/nagios/etc/resource.cfg.
$HOSTADDRESS$ : This expands to the address of any host for which this command is used as a host or service definition.

So if we used the command in a service checking the rsync server on troy.naginet, then the completed command might look similar to the following:

$ /usr/local/nagios/libexec/check_rsync -H troy.naginet

We could run this straight from the command line ourselves as the nagios user to see what kind of results it returns:

$ /usr/local/nagios/libexec/check_rsync -H troy.naginetOK: Rsync is up

There's more...

A plugin can be used for more than one command. If we had a particular rsync module to check with the configured name of backup, we could write another command called check_rsync_backup , as follows, to check this module is available:

define command {
    command_name  check_rsync_backup
 command_line $USER1$/check_rsync -H $HOSTADDRESS$ -m backup
}

Or if one or more of our rsync servers was running on an alternate port, say port 5873, then we could define a separate command, check_rsync_altport, for that:

define command {
    command_name  check_rsync_altport
 command_line $USER1$/check_rsync -H $HOSTADDRESS$ -p 5873
}

Commands can thus be defined as precisely as we need them to be. We explore this in more detail in the Customizing an existing command recipe in this chapter.