For greater flexibility, Zabbix supports user macros, which can be defined on global, template and host level. These macros have a special syntax: {$MACRO}. An optional context can be used in user macros, allowing to override default value with context specific one. User macros with context have a similar syntax: {$MACRO:context}.
The macros can be used in:
The following characters are allowed in the macro names: A-Z , 0-9 , _ , .
Zabbix resolves macros according to the following precedence:
In other words, if a macro does not exist for a host, Zabbix will try to find it in the host templates of increasing depth. If still not found, a global macro will be used, if exists.
If Zabbix is unable to find a macro, the macro will not be resolved.
Macros (including user macros) are left unresolved in the Configuration section (for example, in the trigger list) by design to make complex configuration more transparent.
To define user macros, go to the corresponding locations in the frontend:
If a user macro is used in items or triggers in a template, it is suggested to add that macro to the template even if it is defined on a global level. That way, exporting the template to XML and importing it in another system will still allow it to work as expected.
Most common use cases of global and host macros:
Macro context is a simple text value. The common use case for macro contexts would be using an LLD macro value as a user macro context. For example, a trigger prototype could be defined for mounted file system discovery to use a different low space limit depending on the mount points or file system types.
Only low-level discovery macros are supported in macro contexts. Any other macros are ignored and treated as plain text.
Technically, macro context is specified using rules similar to item key parameters, except macro context is not parsed as several parameters if there is a ,
character:
"
if the context contains a }
character or starts with a "
character. Quotes inside quoted context must be escaped with the \
character. The \
character itself is not escaped, which means it's impossible to have a quoted context ending with the \
character - the macro {$MACRO:"a:\b\c\"}
is invalid.{$MACRO:A}
is the same as {$MACRO: A}
, but not {$MACRO:A }
.{$MACRO:"A"}
, {$MACRO: "A"}
, {$MACRO:"A" }
and {$MACRO: "A" }
are the same, but macros {$MACRO:"A"}
and {$MACRO:" A "}
are not.The following macros are all equivalent, because they have the same context: {$MACRO:A}
, {$MACRO: A}
and {$MACRO:"A"}
. This is in contrast with item keys, where key[a]
, key[ a]
and key["a"]
are the same semantically, but different for uniqueness purposes.
When context macros are processed, Zabbix looks up the macro with its context. If a macro with this context is not defined by host or linked templates, and it is not a defined as a global macro with context, then the macro without context is searched for.
Use of host-level macro in the "Status of SSH daemon" item key:
net.tcp.service[ssh,,{$SSH_PORT}]
This item can be assigned to multiple hosts, providing that the value of {$SSH_PORT} is defined on those hosts.
Use of host-level macro in the "CPU load is too high" trigger:
{ca_001:system.cpu.load[,avg1].last()}>{$MAX_CPULOAD}
Such a trigger would be created on the template, not edited in individual hosts.
If you want to use amount of values as the function parameter (for example, max(#3)), include hash mark in the macro definition like this: SOME_PERIOD => #3
Use of two macros in the "CPU load is too high" trigger:
{ca_001:system.cpu.load[,avg1].min({$CPULOAD_PERIOD})}>{$MAX_CPULOAD}
Note that a macro can be used as a parameter of trigger function, in this example function min().
In trigger expressions user macros will resolve if referencing a parameter or constant. They will NOT resolve if referencing the host, item key, function, operator or another trigger expression.
See usage example for disk space trigger prototype and take limitation clause into consideration.