To link a template to a host, you can either select the hosts you want to link from the template's configuration form, as we saw in the Creating templates section, or you can choose the template you need for a host in that host's configuration form by going into the Template tab.
Once linked, a host will inherit all of the template's entities. Previously existing entities with the same name will be overwritten, but entities not included in the template will remain as they are and will not be touched in any way by the linking operation.
All entities will maintain their original template's name when displayed in the configuration section of the web interface even when viewed from a host configuration page. However, this doesn't mean that modifying them from a template's configuration tab is the same as modifying them from a linked host's configuration tab.
If you modify an entity (item, trigger, graph, and so on) from a template's configuration tab, the modifications will apply immediately to all linked hosts. On the other hand, if you modify a template entity from a particular host's configuration tab, the changes will only apply to that host and not on a template level. While this can be useful to address any special circumstances for an otherwise regular host, it can also generate some confusion if you make many local changes that can become hard to keep track of. Moreover, not every aspect of a template entity can be modified at the host level. You can change the frequency of an item, for example, but not its key.
Unlinking a template from a host doesn't eliminate its entities unless you unlink and clear it. Be careful with this operation as all the items' historical data and trends would become unavailable. If you have collected any actual data, it's probably better to just unlink a template from a host and then disable any unused items and triggers, while retaining all of their historical data.
Just as you can link a template to a host, you can also link a template to another template. The operation is identical to linking a template to a host; you navigate to the Linked templates tab in a template's configuration form and choose the templates you want to link.
While this may seem an awkward operation, it can prove quite useful in two cases.
The first application of nested templates is to make user macros even more general. Since a template inherits all of its linked templates' entities and properties, any custom macro will also be inherited and, thus, made available to the actual monitored hosts.
To take a concrete example, let's say you have a Template Macros template containing a {$PFREE} user macro with the value 5, among many others. You could use this macro to represent the amount of free disk space in percentages to check against, free available memory, or any other such threshold. This template could be linked to both the Template OS Linux and Template OS Windows templates, and the {$PFREE} macro used in these templates' triggers. From now on, if you ever need to modify the default value of the free disk space percentage to check against, you'll just need to change the original Template Macros template, and the updated value will propagate through the linked templates down to the monitoring hosts.
A second, somewhat more limited but still useful, way to use nested templates is to extend the inheritance beyond macros to all the other entities. This may become an advantage when you have a common set of features on a given technological layer but different uses on other layers. Let's take, for instance, the case where you have a large number of virtually identical physical servers that host just a couple of versions of operating systems (Linux and Windows, for simplicity's sake) but that in turn perform many different specialized functions: database, file server, web server, and so on.
You can certainly create a few monolithic templates with all the items you need for any given server, including hardware checks, OS checks, and application-specific ones. Alternatively, you can create a sort of hierarchy of templates. A common, hardware-level template that enables IPMI checks will be inherited by a couple of OS-specific templates. These, in turn, will be inherited by application-specific templates that will have names such as Linux Apache Template or Win Exchange Template. These templates will have all the items, triggers, and graphs specific to the applications that they are meant to monitor in addition to all the OS-specific checks they have inherited from the OS-level templates and the hardware-specific ones they have inherited from the HW-level templates. This means that, when creating a host, you will still just need to link it to a single template, but you'll also have a lot of flexibility in creating new templates and nesting them or modifying existing ones in only one place and watching the changes propagate along the template-linking chain. This also means maximum generality, while still maintaining the ability to make host-specific customizations if you need to.
Another way to make templates modular is to create specific templates for any given technological layer and product but not link them in a hierarchy at the template level.
You can instead link them—as many as you want—directly to the host you need to monitor as long as they don't have any conflicting or overlapping item names or keys. As in the preceding scenario, Host A could have an IPMI checks template, an OS Linux one, and an Apache server one linked, while Host B could have an IPMI checks template and an OS Linux one but then also have a PostgreSQL database template.
The end result is practically the same as the nested templates solution described previously, so which one should you choose? This is largely a matter of preference, but a possible criterion could be that if you have a relatively low number of low-level templates and good consistency in your hardware, OS, and technological configuration, the nested solution might be easier to manage. You'll only have to connect the templates once and then use them on a large number of hosts. This approach also works well with the host discovery facility as it keeps things simple when linking templates to hosts. If, on the other hand, you have a great number of low-level templates and great variability in your technological configuration and landscape, you may just as well pick and choose the templates you need when you create your hosts. Any pre-configuration, in fact, would only prove too rigid to be really useful. This approach works well if you want to always ponder how you are creating and configuring your hosts and also need a great deal of local customization that would make any aggressive inheritance feature a moot point.