The one host still serving e-mails—Another host—now has two templates assigned. But what if we separated out in individual templates all services, applications, and other data that can be logically grouped? That would result in a bunch of templates that we would need to link to a single host. This is not tragic, but what if we had two servers like that? Or three? Or 20? At some point, even a configuration with templates can become hard to manage—each host can easily have a template count of a dozen in large and complicated environments.

This is where the simplicity is coupled with powerful functionality. Behind the scenes, templates aren't that different from hosts. Actually, they are hosts, just somewhat special ones. This means that a template can be linked to another template, thus creating a nested configuration.

How does that apply to our situation? Let's create a simple configuration that would allow the easy addition of more hosts of the same setup. In Configuration | Templates, click on the Create template button. In the Template name field enter C_Template_Email_Server, mark Custom templates in the Other groups box, and click the

button.

Switch to the Linked templates tab. Here, we can link other templates to this one. Click on the Select button and in the pop-up window mark the checkboxes next to C_Template_Email and C_Template_Linux:

Click on Select. Click on the small Add link in the Link new templates section—not on the button yet. Both templates are added to the linkage section:

When you are done, click on the Add button at the bottom. We now have a template that encompasses a basic Linux system configuration with an e-mail server installed and running, so we still have to properly link it to a host that will serve this role.

Open Configuration | Hosts, click on Another host in the NAME column and switch to the Templates tab. In the Linked templates section, click on both Unlink links. In the Link new templates input field, type email and click on C_Template_Email_Server. Click on the small Add control, then click on Update at the bottom of the form. The action successfully completes, so expand the Details link. As we can see here, all elements were unlinked first and updated later. Essentially, the previous templates were unlinked, but the items and triggers were left in place and then they got relinked to the new template. The biggest benefit from such a sequence was keeping all item historical data.

But the biggest thing we did here was create a nested template. Such a template is linked against other templates, thus it inherits all the items, triggers, and other characteristics, while usually making some modifications to the original template conditions. In this case, our nested template contains entities from two other templates like this:

While that seems to be only a little gain from the previous situation, two templates linked to a single host, it is a very valid approach when your monitored environment is slightly larger. If there's a single host requiring a specific combination of multiple templates, it is fine to link those templates directly to the host. As soon as the count increases, it is more convenient to set up template nesting, creating a single template to link for these hosts. When you have done that, adding a new host of the same class requires linking against a single template only, which greatly simplifies configuration and minimizes the chance of mistakes.

Looking at the host list, we can see all templates that affect this host in the TEMPLATES column:

Notice how the new C_Template_Email_Server template is listed first, and the two other templates are listed in parentheses. Templates that are linked directly to the host are listed first, and second level templates that are pulled in by the first level are listed in parentheses. Only the first two levels are shown here—if we had more levels of nesting, we would not see them in the host list.

Let's review a templated item now. From the host list, click on Items next to Another host. Click on SMTP server status in the NAME column. This time we are interested in the very first row here, Parent items:

This is something that shows up in templated items. Higher level items can be seen and accessed here, and for this item there are two levels displayed. Templates that are closer to the host are listed last and the very first template is the one the item originates from. If we had more than two levels, they would be shown as well. This line works as a quick information on where a particular item originates from and what could modify it, as well as a convenience access upstream. If we spot a simple mistake in some templated item, we can go to higher level items with one click, instead of going to Configuration | Templates, finding the correct page and/or template, then repeating that for the item. The same parent entity convenience access line is available for triggers and other entities, too.

When using a nested template setup, the inherited macro resolution helper is even more helpful. If we had a single host and a single template, without the helper, we would first check the macro on the host, if not defined there—on the template, and if not defined there either, on the global level. With nested templates we would have to check all the templates individually. With the helper, we can see the outcome and which exact template is providing the value from that same macro tab in the host properties.

Template nesting is a convenient way to group templates and apply a single template to the target hosts while still having different functionality properly split up and reused in multiple lower level templates. Nevertheless, care should be taken not to create excessive nesting. Two levels of nesting are quite common, but one advanced Zabbix user admitted that designing a templating system with five levels of nesting was a bit excessive and they would restrict themselves to a maximum of four levels next time.