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 drop-down, Custom templates in the Group drop-down, then mark the checkbox next to the only remaining target (C_Template_Linux), and click on Copy. 

The 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 drop-down. 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:

1. Select Custom templates in the Group drop-down
2. Click on the CPU load too high on A test host for last 3 minutes trigger in the Name column
3. Change the Name field to CPU load too high on {HOST.NAME} for last 3 minutes
4. Click on the Update button

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

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 | Problems and expand the filter. Set the Show selection box to History, and in Problem enter CPU in the Filter by name field, then click on the Apply button under 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}.