Templates in Nagios allow you to create a set of parameters that can then be used in the definitions of multiple hosts, services, and contacts. The main purpose of templates is to keep parameters that are generic to all objects or a group of objects in one place. In this way you can avoid putting the same directives in hundreds of objects and your configuration is more maintainable.
Note
Nagios allows an object to inherit from single or multiple templates. Templates can also inherit from other templates. This allows for the creation of very simple templates, where objects inherit from a single template, as well as a complex templating system, where actual objects (such as services or hosts) inherit from multiple templates. It is recommended to start with a simple template. Multiple templates are more useful when monitoring a larger numbers of hosts and services across multiple sites.
It is also good to try using templates for hosts and services and decide how they should be used. Sometimes, it's better to have one template, inherit another, and create a hierarchical structure. In many cases, it is more reasonable to create hosts so that they use multiple templates. This functionality allows the inheritance of some options from one template and some parameters from another.
The following is an illustration of how the templates can be structured using both techniques:
This example illustrates how the templates can be structured using both hierarchy and multiple templates inheritance. It shows how to use templates for host definitions, but similar rules apply for services as well; the inheritance structure may be a lot different, though.
In both methods shown in the preceding diagram, there's a distinction between critical and non-critical servers. Hosts are also split into ones that are Unix-based and ones that are Windows-based. There is also a distinction between the two branches that are configured— Miami and LA (Los Angeles). Furthermore, there is also a generic-host template that is used by every other template.
Usually, such distinctions make sense, as Windows and Unix hosts might be checked differently as well as have services checked by default. Based on the operating system and the location of the machine, different people should be assigned as contacts in case of problems. There may also be different time periods during which these hosts should be checked.
The example on the left shows the inheritance of one type of parameter at a time. First, a distinction is made between critical and non-critical machines. Usually, both types have different values for the notification and check intervals, as well as the number of checks to perform before generating a notification for a problem. The next step is to differentiate between Windows and Unix-based servers; this might involve the check command to verify that a server is up. The last step is to define templates for each system in both of the branches (Miami and LA). The actual host definition inherits from one template in the final set of templates.
The example on the right uses a slightly different approach. It first defines different templates for Unix and Windows systems. Next, a pair of templates for critical and noncritical machines is also defined. Finally, a set of templates defines the branches Miami and LA. The actual host definition inherits templates for the operating system, for the level of criticality, and for the branch to which it belongs. The actual host definitions then inherit parts of parameters from each of the templates.
In both cases, attributes that are passed at different levels are the same, even though the approach is different. Usually, templates that define the operating system also define how a host check should be done. They might also indicate the time period over which a host should be checked as well as host groups the host should be a member of by default.
Templates for critical and noncritical machines usually specify how notifications should be carried out. If a host is crucial to infrastructure, its owners should be notified in a more aggressive way. Similarly, machines that are not affecting business directly do not need that much attention.
Templates for locations usually define the owners of the machines. The locations are not always branches, as in this example; they can be branches, floors, or even network connection types. Locations can also point machines to their parent hosts; usually, computers located in the same place that are connected to the same router.
Defining the templates in Nagios is very similar to defining actual objects. You simply define the template as the required object type. The only difference is that you need to specify the register directive and specify a value of 0 for it. This will tell Nagios that it should not treat this as an actual object, but as a template. You will also need to use the name directive for defining template names. You do not need to specify other directives for naming objects, such as host_name, contact_name, or service_description.
When defining an object, simply include the use directive and specify all of the templates to be used as its value. If you want to inherit from multiple templates, separate all of them with commas.
The following is an example of defining a template for a Linux server and then using this in an actual host definition:
define host {
register 0
name generic-servers
check_period 24x7
retry_interval 1
check_interval 15
max_check_attempts 5
notification_period 24x7
notification_interval 60
notification_options d,r
}
define host
{
register 0
use generic-servers
name linux-servers
check_command check-host-alive
contact_groups linux-admins
}
define host
{
use linux-servers
host_name ubuntu1
address 192.168.2.1
}
As mentioned earlier, templates use name for defining the template, and the actual host uses the host_name directive.
Nagios allows us to inherit from multiple templates and the templates using other (nested) templates. It's good to know how Nagios determines the order in which every directive is looked for in each of the templates. When inheriting attributes from more than one template, Nagios tries to find the directive in each of the templates, starting from the first one. If it is found in the first template, that value is used; if not, Nagios checks for a value in the second one. This cycle continues until the last template in the list. If any of the templates is also inheriting from another template, then a check for the second level of templates is done recursively. This means that checking for a directive will perform a recursive check of all of the templates that are inherited from the currently checked one.
The following illustration shows an example of this situation. The actual host definition inherits three templates— B, F, and G. Template B inherits A, F inherits D and E, and finally, D inherits attributes from template C :
If Nagios tries to find any directive related to this host, the first thing that will be checked is the actual host definition. If the host does not include the directive, Nagios will first look under B, as this is the first template that should be used. If it is not found in B, Nagios will, recursively, try to find the attribute in A, as it is used by template B. The next step is to look in F along with all of the templates it is using. F inherits D and E. The first one to check is B along with all parent templates; this means that D, C, and the next E should now be checked. If the attribute is still not found, then template G is used. Let's assume that the following directives (among others) are defined for the previous illustration:
define host
{
register 0
name A
check_period workinghours
retry_interval 1
check_interval 15
}
define host
{
register 0
use A
name B
check_period 24x7
}
define host
{
register 0
name D
use C
max_check_attempts 4
}
define host
{
register 0
name E
max_check_attempts 3
}
define host
{
register 0
use D,E
name F
notification_interval 30
}
define host
{
use B,F,G
host_name ubuntu1
address 192.168.2.1
notification_interval 20 }For this particular example, the values for the address and notification_interval directives are taken directly from the host ubuntu1 definition. Even though notification_interval is also defined in F, it is overwritten by the actual host definition.
The value for max_check_attempts is taken from template D, regardless of whether it is also defined in C. Even though template E also defines a value for it, as D is put before E, the values defined in both of them are taken from D.
The value for check_period is taken from B, which overwrites the value defined for template A. Values for retry_interval and check_interval are taken from A.
Even though the preceding examples mention host configurations, templates for other types of objects work in the same way. Templates are often used extensively for service definitions. They usually use a similar approach as the one for hosts. It is a good idea to define templates for branches depending on the priority or type of service, such as a template common for all services in a specific branch. One template could be used for all services for web, mail, and other applications. Another template could be used for critical, non-critical, or backup servers. This increases the maintainability of the configurations, especially for the larger setups. It is much easier to change contact address or notification settings for all the critical applications if that info is defined in the template used by all services. In this case, our configuration may have several templates, and most of the service definitions will just re-use existing templates, perhaps only specifying how checks for those services should be made.
Contacts, on the other hand, usually use only a couple of templates. They depend on the working hours and the notification preferences. The remaining parameters can be kept in an individual contact's definition. Very often, users may have their own preferences on how they should be notified, so it's best not to try and design templates for that.