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 too. 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 works exactly the same as before, except it has a more explanatory name. We replaced the trigger threshold with the macro, parametrizing it instead of having a hard-coded 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.

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 | Problems and expand the filter. Set the Show status box to History and enter CPU in the Filter problem field, then click on Apply.

Create some load on both machines. Remember that we could use something such as cat /dev/urandom | md5sum to generate some CPU load. On our problem page, after some time, we would see problems:

This list confirms that Another host is getting the macro value of 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. 

Remember the {$SNMP_COMMUNITY} macro we saw in the Inherited and host macros section from the macro tab on our host . So far, we have covered two locations where user macros may be defined—the template and host level. There's actually another location available. Click on the menu on Administration | General and select Macros in the drop-down 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, we used 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.

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 by 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? Here are some examples:

• Item key parameters and item name: We 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 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 {$CPU_LOAD_TIME} to change the averaging time for some hosts.
• SNMP community: This is where the {$SNMP_COMMUNITY} default macro 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.

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 configurations for linked hosts.