In order to allow flexible configuration of machines, Nagios offers a powerful inheritance functionality. The main concept is that administrators can set up templates that define common parameters and reuse them in actual host or service definitions. The mechanism even offers the possibility to create templates that inherit parameters from other templates.
Templates are regular Nagios objects that have the register
directive and set it to 0
. This means that they will not be registered as an actual host or service that needs to be monitored. Objects that inherit parameters from a template or another host should have a use
directive pointing to the short name of the template object they are using.
When defining a template, its name is always specified using the name
directive. This is slightly different from how typical hosts and services are registered, as they require the host_name
and/or service_description
parameters.
Inheritance can be used to define a template for basic host checks with basic parameters such as IP address being defined for each particular host. The following code is an example of this:
define host{ name generic-server check_command check-host-alive check_interval 5 retry_interval 1 max_check_attempts 5 check_period 24x7 notification_interval 30 notification_period 24x7 notification_options d,u,r register 0 } define host{ use generic-server host_name linuxbox01 alias Linux Server 01 address 10.0.2.1 contact_groups linux-admins }
It is possible to inherit from multiple templates. To do this, simply put multiple names in the use
directive, separated by a comma. This allows an object to use several templates that define a part or all directives that it will use. If multiple templates specify the same parameters, the value from the first template specifying it will be used. The following is an example code:
define service{ name generic-service check_interval 10 retry_interval 2 max_check_attempts 3 check_period 24x7 register 0 } define service{ host_name workinghours-service check_period workinghours notification_interval 30 notification_period workinghours notification_options w,c,u,r register 0 } define service{ use workinghours-service,generic- service contact_groups linux-admins host_name linuxbox01 service_description SSH check_command check_ssh }
In this case, values from both templates will be used. The value of workinghours
will be used for the check_period
directive as it was first specified in the workinghours-service
template. Changing the order in the use
directive to generic-service,workinghours-service
would cause the value of the check_period
parameter to be 24x7
.
Nagios also accepts creating multiple levels of templates. For example, you can set up a generic service template and inherit it to create templates for various types of checks, such as local services, resource-sensitive checks, and templates for passive-only checks.
Let's consider the following object and template structure:
define host{ host_name linuxserver1 use generic-linux,template-chicago ..... } define host{ register 0 name generic-linux use generic-server ..... } define host{ register 0 name generic-server use generic-host ..... } define host{ register 0 name template-chicago use contacts-chicago,misc-chicago ..... }
The following diagram shows how Nagios will look for values for all directives:
When looking for parameters, Nagios will first look for the value in the linuxserver1
object definition. Next, it will use the following templates, in this order: generic-linux
, generic-server
, generic-host
, template-chicago
, contacts-chicago
, and misc-chicago
in the end.
It is also possible to set up host or service dependencies that will be inherited from a template. In that case, the dependent hosts or services can't be templates themselves and need to be registered as an object that will be monitored by the Nagios daemon.
18.216.233.58