While directives for hosts such as host_name, alias, and address may be adequate for many purposes, depending on our monitoring requirements, we may sometimes need Nagios Core to be able to refer to other data that's specific to individual hosts but can't be included in one of these directives.
For example, it's common in networking to have a management interface for a device. This is a network interface that links to a network used only by the administrators of the device for the purposes of monitoring and configuring it and is not accessible to users of the service. While we may want to run, for example, check_ping against the public-facing address of a given host, we may also need to verify that a service at a different address on a completely different network is running.
We might have a host configured in the following way referring to a webserver and including a PING check to make sure its public-facing interface with the 203.0.113.1 address is up and running:
define host {
use webserver
host_name webserver-01.example.net
alias webserver-01
address 203.0.113.1
}
define service {
use generic-service
host_name webserver-01
service_description PING
check_command check_ping_addr!$HOSTADDRESS$
}Suppose this host also had a second network address for management purposes only, 192.0.2.1, and we also wanted to arrange to send PING requests to this address to ensure it responded. We could set up another service PING_MGMT check like so, by hardcoding the address into the value of the check_command directive:
define service {
use generic-service
host_name webserver-01
service_description PING_MGMT
check_command check_ping_addr!192.0.2.1
}However, if we have to check multiple services this way, we may find that we're repeating ourselves in specifying the management address. It would be helpful to add our own property for the management address to the host object so that we could refer to it in services. We'll arrange this in this recipe.
You will need to have a server running Nagios Core 4.0 or later, access to the command line to change its configuration, and a basic understanding of how directives apply to hosts and services and how hosts and services refer to one another. These are discussed in chapters 1 and 2.
We can create a reference to the values of another host's directives like so:
- Change to the objects configuration directory for Nagios Core. The default is
/usr/local/nagios/etc/objects. If you've put the definition for your hosts and services in a different file, move to its directory instead. Run the following line:# cd /usr/local/nagios/etc/objects - Edit the file containing the definition for the host for which you want the custom attribute. In this example, we will add it to our
webserver-01host declaration, as follows:define host { use webserver host_name webserver-01.example.net alias webserver-01 address 203.0.113.1 } - Add the directive with the name needed and its corresponding value along with an underscore prefix (
_), as follows:define host { use webserver host_name webserver-01.example.net alias webserver-01 address 203.0.113.1 _address_mgmt 192.0.2.1 } - If needed, configure an appropriate service that uses this value; capitalize the name of the directive and
prepend _HOSTto get the full name of the necessary macro via the following code:define service { use generic-service host_name webserver-01 service_description PING_MGMT check_command check_ping_addr!$_HOSTADDRESS_MGMT$ } - Validate the configuration and restart the Nagios Core server, as follows:
# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
With this done, we will be able to refer to the custom directive in macros; including specifying new commands or services to use its values.
Nagios Core understands directives prefixed with underscores as custom object variables; it allows any alphanumeric string with underscores to be used in defining the directive. The value is made all uppercase and then becomes available for macro expansion in check_command definitions in the same way as all standard Nagios Core macros.
The custom object variables feature was established in Nagios Core in response to requests from users to allow adding custom information to their objects and get greater flexibility out of the commands that use the information stored in them. This means it works in other object types too, not just hosts; other possibilities for uses of custom declarations might be as follows:
Note
The Nagios Core documentation includes some more detail on the usage of custom macros at https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/customobjectvars.html.
- Customizing an existing command, Chapter 2, Working with Commands and Plugins
- The Using another object's directives in a host or service check recipe in this chapter
- The Using inheritance to simplify configuration recipe in this chapter
- The Dynamically building host definitions recipe in this chapter