Now we'd like to link this template to our very first host, "A test host". First, let's compare item lists between the freshly created template and that host. Open Configuration | Hosts in one browser window or tab and Configuration | Templates in another. In the first, choose Linux servers in the Group dropdown, then click on Items next to A test host. In the other one, select Custom templates in the Group dropdown, then click on Items next to C_Template_Linux. Place the windows next to each other and compare the listings:

We can see here that the template has three more items than the host. Looking at the lists, we can see that the items available on the template but not the host, are both SNMP related items that we added later—Experimental SNMP trap and snmptraps, the time item Local time, and also the check for a file, Testfile exists. If the template has four items the host is missing, but in total it only has three items more, that means the host should have one item that the template doesn't—that's right, the Full OS name exists for the host but is missing in the template. Keeping that in mind, and return to Configuration | Hosts.

Make sure the Group dropdown says either all or Linux servers and click on A test host in the NAME column. We finally get to use the Templates tab—switch to it. Start typing C in the Link new templates input field. In the dropdown, our new template, C_Template_Linux, should be the very first one—click on it. Even though it might seem that this template is now added, it actually is not—if we would update the host now, it would not be linked:

Click on the Add control just below the template name. This form can be highly confusing, so try to remember that you have to do that extra click here. With the template added to the list, notice that it's actually a link. Clicking it will open template properties in a new window. When looking at host properties, this offers quick access to template properties. Such convenient links are available in many places in the Zabbix frontend:

In the end, click on the Update button at the bottom. Let's find out what this operation did—click on the Details link in the upper-left corner. In the expanded Details panel, we can see the operations that took place. In this case, some items were created and some were updated:

Scrolling down a bit further, you'll be able to see that, same thing happened with triggers:

Now this all seems like quite a lot of work for nothing, but if we had to add more hosts with the same items and triggers, without templates each host would require tedious manual copying, which is quite error-prone. With templates all we have to do is link the template to the freshly added host and all the entities are there automatically.

Now we could check out how linked items appear in the configuration. Open Configuration | Hosts, click on Items next to A test host:

There are two observations we can make right away. First, almost all items are prefixed with a template name (C_Template_Linux in this case), in grey text. Obviously, this indicates items that are linked from the template. Clicking on the template name would open an item listing for that template.

Second, a single item is not prefixed like that—Full OS name. Remember, that was the only item existing for the host, but not for the template? If entities exist on the host only, linking does not do anything to them—they are left intact and attached to the host directly.

Let's see what a linked item looks like—click on SMTP server status in the NAME column:

Hey, what happened? Why are most fields grayed out and can't be edited? Well, that's what a template is about. Most of the entity (in this case, item) parameters are configured in the template. As we can see, some fields are still editable. This means that we still can disable or enable items per individual host even when they are linked in from a template. The same goes for the update interval, history length, and a few other parameters.

We now want to make this particular item for this host slightly different from all other hosts that the template will be linked to, so let's change these things:

When you are done, click on Update. Now this host will have two parameters for a single item customized, while all other hosts that will get linked against the template will receive values from the template. Let's link one more host to our template now. Navigate to Configuration | Templates. Here we can see a full list of templates along with the hosts linked to them. The linkage area in this screen shows various entries and listed entities there have different color:

Click on C_Template_Linux in the TEMPLATES column. That provides us with a form where multiple hosts can be easily linked against the current template or unlinked from it. In this case we want to link a single host. In the Hosts | Templates section, choose Linux servers in the Other | Group dropdown, mark Another host in that box and click on the

button:

Multi-select in the Hosts | Templates section now has two hosts that will be linked against the current template. Click on Update. You can expand the Details section to see what exactly was done. As we already copied all elements from Another host to the template beforehand, linking this host against the template did not create new items or triggers, it only updated them all. Looking at the template list, we can see two hosts linked against our template.

Move your mouse cursor over the hostnames in the template table—notice how they are actually links. Clicking them would open host properties to verify or change something, such as quickly disabling a host or updating its IP address:

Changing the configuration in a template

Now we could try changing an item that is attached to the template. Open Configuration | Templates, select Custom templates from the Group dropdown and click on Items next to C_Template_Linux, then click on SMTP server status in the NAME column. As we can see, all fields are editable when we edit a directly attached instance of an item. Change the History storage period field to read 14, then click on Update. Expand the Details area at the top of the page to see what got changed:

This reinforces the principle one more time—when an item is updated in a template, the change is propagated to all linked hosts. This means that with a single action both linked hosts have their history keeping period set to 14 days now. But we changed two item properties for one downstream host before, and we just changed one of those for the upstream template. What about down-streaming the host's other item? Let's find out. Go to Configuration | Hosts, choose Linux servers in the Group dropdown and click on Items next to A test host. In the NAME column, click on SMTP server status:

We can see that our downstream change for Update interval has been preserved, but the History storage period value has been overwritten with the one set for the template. That's because only changed properties are set to downstream when editing template attached items. Now click on Cancel.

Macro usage

We previously added triggers from Another host to our template, but we didn't do that for A test host. Let's find out whether it has some triggers we could use in the template. Click on Triggers in the Navigation bar above the Items list. From the directly attached triggers in the list (the ones not prefixed with a template name), one is a trigger that takes into account items from two different hosts and we avoided copying it over before. The other directly attached triggers are the ones that we are interested in. Mark the checkboxes next to the CPU load too high on A test host for last 3 minutes and Critical error from SNMP trap triggers in the NAME column, then click on the Copy button at the bottom. In the next window, choose Templates in the Target type dropdown, Custom templates in the Group dropdown, then mark the checkbox next to the only remaining target (C_Template_Linux) and click on Copy. This time our copying had a bit more interesting effect, so let's expand the Details box again:

Two triggers we copied are added to the template. This causes the following:

• As A test host is linked to the modified template and it already has such triggers, these two triggers for that host are updated to reflect the linkage
• Another host does not have such triggers, so the triggers are created and linked to the template

While we are still in the trigger list, select Another host in the Host dropdown. Look carefully at the CPU load trigger that was added to this host in the previous operation:

Wait, that's definitely incorrect. The trigger refers to A test host, while this is Another host. The trigger name was correct when we first added it, but now the same trigger is applied to multiple hosts. In turn, the reference is incorrect for all the hosts except one. Let's try to fix this. Select Custom templates in the Group dropdown, then click on the CPU load too high on A test host for last 3 minutes trigger in the NAME column. Change the Name field to CPU load too high on {HOST.NAME} for last 3 minutes.

Yes, that's right, macros to the rescue again.

Tip

The use of the word macros can be confusing here—Zabbix calls them macros, although they might be more correctly considered to be variables. In this book, we will follow Zabbix terminology, but feel free to read macro as variable.

Now click on Update. In the trigger list for the template, the trigger name has now changed to CPU load too high on {HOST.NAME} for last 3 minutes. That's not very descriptive, but you can expect to see such a situation in the configuration section fairly often—Zabbix does not expand most macros in configuration. To verify that it is resolving as expected, navigate to Monitoring | Triggers and expand the filter. Set the Triggers status dropdown to Any and enter CPU in the Filter by name field, then click on the Filter button below the filter:

Notice how the trigger name includes the correct hostname now. In most cases, it is suggested to include a macro such as this in trigger names to easily identify the affected host.

The macro we used here, {HOST.NAME}, resolves to the host's visible name. We had no visible name specified and the hostname was used. If a host had the visible name defined, we could also choose to use the hostname with a macro {HOST.HOST}.

User macros

The macros we used before are built-in. Zabbix also allows users to define macros and use them later. In this case it might be even more important to call them variables instead, so consider using that term in parallel. Let's start with a practical application of a user macro and discuss the details a bit later.

Go to Configuration | Templates and click on C_Template_Linux in the TEMPLATES column. Switch to the Macros tab and add one new macro:

• MACRO: {$CPU_LOAD_THRESHOLD}
• VALUE: 1

When done, click on Update. We have defined one macro on the template, but it is not used at this time. Click on Triggers next to C_Template_Linux, then click on CPU load too high on {HOST.NAME} for last 3 minutes in the NAME column. Change the trigger properties:

• Name: CPU load too high on {HOST.NAME} for last 3 minutes (over {$CPU_LOAD_THRESHOLD})
• Expression: {C_Template_Linux:system.cpu.load.avg(180)}>{$CPU_LOAD_THRESHOLD}

Notice how we used the same user macro name both in the trigger name and expression as in the template properties. When done, click on Update. The changes we just did had no functional impact—this trigger still works exactly the same as before, except having a bit more of an explanatory name. What we did was to replace the trigger threshold with the macro, parametrizing it instead of having a hardcoded value. Now we can try overriding this value for a single host—navigate to Configuration | Hosts and click on A test host in the NAME column. Switch to the Macros tab and switch to the Inherited and host macros mode:

Notice how in this form we can see the macro we just created on the template. There's also a {$SNMP_COMMUNITY} macro—we will discuss where that one comes from a bit later. We can also see which exact template is providing the macro that we created. Although we remember that in this case, in real-world setups it is an extremely helpful feature when many templates are linked to a host. To customize this value on this host, click on the Change control next to {$CPU_LOAD_THRESHOLD}. The EFFECTIVE VALUE column input field becomes editable—change it to 0.9.

Tip

Zabbix 3.0 is the first version that allows resolving macros like this. In previous versions, we would have to know the exact macro name to be able to override it. There was also no reasonable way to identify the template supplying the macro.

When done, click on Update. Now we finally have some use for the macro—by using the same name on the host level we were able to override the macro value for this single host. To double check this change, go to Monitoring | Triggers and expand the filter. Set the Triggers status dropdown to Any and enter CPU in the Filter by name field, then click on Filter:

This list confirms that Another host is getting the macro value 1 from the template, but A test host has it changed to 0.9. We are still using the same template and the same trigger, but we changed the trigger threshold for this single host. Feel free to test trigger firing, too. On A test host, this trigger should now fire at the new threshold, 0.9.

Remember the {$SNMP_COMMUNITY} macro we saw in the Inherited and host macros section? So far we have covered two locations where user macros may be defined—the template and host level. There's actually another location available. Go to Administration | General and select Macros in the dropdown in the upper right corner. This form looks the same as the template and host macro properties, and there's one macro already defined here.

We'll talk more about this macro in a moment, but first let's figure out how these three levels interact. As an example, we can look at a hypothetical use of the macro we just defined:

In addition to our template and host level definitions, we could define this macro on the global level with yet another value, in this example—2. Now all other templates and hosts that would not have this macro defined would use the global value of 2. This change would not affect our template and host, as they have a macro with the same name already defined. In general, the macro definition that's closest to the host "wins". Zabbix first looks for a macro on the host, then the template, then the global level.

Tip

The macro's name is up to us as long as we are using the allowed symbols—uppercase letters, numbers, underscores and, a dot.

But what happens if two templates define the same macro and are linked directly to a host? One of the macro values will be used, and the choice will depend on Zabbix's internal IDs—do not rely on such a configuration. One way to explicitly override the macro value would be introducing yet another template that would be linked directly to the host and would pull in the two original templates.

We used a user macro in the trigger name and expression as a threshold. Where else can they be used?

• Item key parameters and item name: One might run SSH on the default port 22, but override it for some hosts. Note that user macros cannot be used in the key itself, only in the parameters that are enclosed by square brackets.
• Trigger function parameters: We might change the trigger to {C_Template_Linux:system.cpu.load.avg({$CPU_LOAD_TIME})}>{$CPU_LOAD_THRESHOLD} and then use the {$CPU_LOAD_TIME} to change the averaging time for some hosts.
• SNMP community: That is where the default macro {$SNMP_COMMUNITY} we saw in the global configuration is used. If that macro had been used in SNMP item properties, we could use the same template on various SNMP devices and change the SNMP community as needed.

Tip

If you are designing templates that use user macros, it is suggested to define such macros on the template level in addition to or instead of the global macro. Exporting such a template will not include global macros, only the macros that are defined on the template level.

Entities such as items and triggers are configured once in the template. When the template is applied to many hosts, macros provide a way to create personalized configuration for linked hosts.