As you might have noticed, the host and the service object definitions have a use directive. Icinga's objects have the ability to inherit other objects. This use directive is nothing but the inheritance specifier. The value of this directive is another object of the same type, whose key-value pairs also are applied to the said object, overriding those which are re-defined. Such inherited objects are called template objects, or simply templates.

In our setup, the localhost host definition inherits the linux-server template object using the use directive. Template objects are usually defined in templates.cfg.

define host{
  name                    linux-server
  use                     generic-host
  check_period            24x7
  check_interval          5
  retry_interval          1
  max_check_attempts      10
  check_command           check-host-alive
  notification_period     workhours
  notification_interval   120
  notification_options    d,u,r
  contact_groups          admins
  register                0
}

The preceding code is just another host object definition of linux-server, which is inherited by the localhost host definition. We indicate that this is not a real host by setting the value of the register directive to 0. This template object defines the most common directives that most of the host definitions are going to need. This reduces a lot of effort as we are no longer required to redefine all of these directives in all of the host definitions, we can just use the template. Note that this template in turn uses a template generic-host which has more general directives defined. It is defined in the same file.

Each host definition also has a check_command directive specified, which is used to monitor the state of the host itself, apart from all the service checks configured for it. It is the same as the check_command directive in service definitions. It refers to a command object which has the defined command_line. The commands.cfg file also has the command definition for check-host-alive, which is used here in the previous template.

Similarly, the service object definitions have a template service local-service that they're inheriting. This template service too is defined in templates.cfg.