In this recipe, you'll learn how to use inheritance to handle the situation where hosts and services share a lot of values in common, leading to a large amount of undesirable redundancy in configuration.
Some Nagios objects, particularly hosts and services, have a rather long list of possible directives and the default values for these are not always suitable. It's therefore worthwhile to be able to declare the values you want for these directives once and then spend only a few lines on the actual host definition by copying these values from a template, making the configuration shorter and easier to read.
The previous examples in this book demonstrated the use of this in suggesting you inherit from the linux-server host template or the generic-service template for the sake of brevity; in this example, we'll define our own templates and show how these can be used to streamline a configuration.
You will need to have a server running Nagios Core 4.0 or later, have access to the command line to change its configuration, and be familiar with how to define hosts and services. These are covered in the Creating a new host and Creating a new service recipes in Chapter 1, Understanding Hosts, Services, and Contacts.
In this example, we'll define a critical-host template, which we'll use as the basis for any host that needs to be checked and notified around the clock with a very stringent check_command and with all the notification types enabled. We'll also define two hosts named phobos.example.net and deimos.example.net that inherit from this template.
We can define a host template and then define the hosts to inherit from it like so:
- Change to the objects' configuration directory. In the default installation, this is
/usr/local/nagios/etc/objects. If you have already followed the Grouping configuration files in directories recipe in this chapter, your own directory may differ. Run the following line:# cd /usr/local/nagios/etc/objects - In an appropriate file, perhaps
templates.cfg, add the following definition. Note the use of the special directivesnameandregister:define host { name critical-host register 0 check_command check_ping!25,10%!50,20% max_check_attempts 3 check_interval 1 notification_interval 1 notification_period 24x7 notification_options d,u,r,f,s check_period 24x7 contact_groups admins } - In another file, or separate files if you prefer to keep your hosts to one per file, define the hosts to inherit from this template. Add in the remaining required directives for hosts and include a
usedirective referring to the established template, as follows:define host { use critical-host host_name phobos.example.net alias phobos address 192.0.2.151 } define host { use critical-host host_name deimos.example.net alias deimos address 192.0.2.152 } - Validate the configuration and restart the Nagios Core server via the following lines:
# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg # /etc/init.d/nagios restart
You might receive warnings about no services being defined for the hosts, but you can ignore these for now.
With this done, two new hosts should be registered in your configuration: phobos.example.net and deimos.example.net.
No other new hosts should be added as the template itself was not explicitly registered with the register directive.
The configuration added in the preceding section defines a new template with the name directive of critical-host. As the value for the host's register directive is 0 where it normally defaults to 1, the host is not registered as an object with Nagios Core. Instead, it becomes a snippet of configuration that can be referenced by real objects of the same type by referring to its name.
Instead, we used its values as the basis for other hosts, phobos.example.net and deimos.example.net. Both of these hosts inherit from critical-host and fill in the rest of the missing values in their own definitions. This freed us from having to repeat the same directives in two different hosts.
If an object inherits a value for a directive from its parent, it's possible to override this directive by redefining it in the inheriting object definition. For example, if we wanted phobos.example.net to have a different value for max_check_attempts, we would only need to add this to its definition. Take a look at the following code:
define host {
use critical-host
host_name deimos.example.net
alias deimos
address 192.0.2.152
max_check_attempts 5
}The most important thing to note about templates is that they work for a variety of Nagios Core objects, including, most importantly, hosts, services, and contacts. You can, therefore, set up and inherit from a service template in the same way, as follows:
define service {
name critical-service
register 0
...etc...
}
define service {
use critical-service
...etc...
}Alternatively, you can use the following code for a contact object:
define contact {
name critical-contact
register 0
...etc...
}
define contact {
use critical-contact
...etc...
}Also, potentially useful to note is that inheritance can stack. For example, critical-host could itself inherit from a template, perhaps generic-host, by adding its own use directive, as follows:
define host {
use generic-host
name critical-host
register 0
...etc...
}This allows us to set up an inheritance structure of arbitrary complexity, but you should avoid too much depth to prevent confusing yourself or anyone else who tries to read your configuration. Two levels is probably a sensible limit.
The rules around how inheritance is handled are discussed in more depth in the Nagios Core manual, including a treatment of multiple inheritance. It's useful to know about this, but in the interest of keeping the configuration clear, it's best used sparingly. Refer to the following link: https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/objectinheritance.html