2022 Zabbix中国峰会
2022 Zabbix中国峰会

Event tags


There is an option to define custom event tags in Zabbix. Tags can be defined on template, host and trigger levels.

After the tags are defined, corresponding new events get marked with tag data:

  • with template level tags - host problems that are created by triggers from this template will be marked
  • with host level tags - all problems of the host will be marked
  • with trigger level tags - problem of this trigger will be marked

An event inherits all tags from the whole chain of templates, hosts, triggers. Completely identical tag:value combinations (after resolved macros) are merged into one rather than being duplicated, when marking the event.

Having custom event tags allows for more flexibility. Most importantly, events can be correlated based on event tags. In other uses, actions can be defined based on event tags.

Event tags are realized as a pair of the tag name and value. You can use only the name or pair it with a value:

MySQL, Service:MySQL, Services, Services:Customer, Applications, Application:Java, Priority:High 

Tags are not supported for host prototypes and hosts created from prototypes.

Use cases

Some use cases for this functionality are as follows:

  1. Mark trigger events in the frontend
   * Define tags on trigger level; 
          * See how all trigger problems are marked with these tags in //Monitoring// → //Problems//.
       - Mark all template-inherited problems 
          * Define a tag on template level, for example 'App=MySQL';
          * See how those host problems that are created by triggers from this template are marked with these tags in //Monitoring// → //Problems//.
       - Mark all host problems 
          * Define a tag on host level, for example 'Service=JIRA';
          * See how all problems of the host triggers are marked with these tags in //Monitoring// → //Problems//
       - Identify problems in a log file and close them separately
          * Define tags in the log trigger that will identify events using value extraction by the ''%%{{%%ITEM.VALUE<N>}.regsub()}'' macro; 
          * In trigger configuration, have multiple problem event generation mode;
          * In trigger configuration, use [[:manual/config/event_correlation|event correlation]]: select the option that OK event closes only matching events and choose the tag for matching;
          * See problem events created with a tag and closed individually.
       - Use it to filter notifications
          * Define tags on the trigger level to mark events by different tags; 
          * Use tag filtering in action conditions to receive notifications only on the events that match tag data.
       - Use information extracted from item value as tag value
          * Use an ''%%{{%%ITEM.VALUE<N>}.regsub()}'' macro in the tag value; 
          * See tag values in //Monitoring// → //Problems// as extracted data from item value.
       - Identify problems better in notifications
          * Define tags on the trigger level;
          * Use an {EVENT.TAGS} macro in the problem notification; 
          * Easier identify which application/service the notification belongs to.
       - Simplify configuration tasks by using tags on the template level
          * Define tags on the template trigger level; 
          * See these tags on all triggers created from template triggers.
       - Create triggers with tags from low-level discovery (LLD)
          * Define tags on trigger prototypes; 
          * Use LLD macros in the tag name or value;
          * See these tags on all triggers created from trigger prototypes.


Event tags can be defined in:

  • template configuration - affecting all triggers from the template when linked to hosts
  • host configuration - affecting all triggers of the host
  • individual trigger configuration:

Event tags can be defined for triggers, template triggers and trigger prototypes.

Macro support

The following macros may be used in trigger-level tags:

  • {ITEM.VALUE}, {ITEM.LASTVALUE}, {HOST.HOST}, {HOST.NAME}, {HOST.CONN}, {HOST.DNS}, {HOST.IP}, {HOST.PORT} and {HOST.ID} macros can be used to populate the tag name or tag value.
  • {INVENTORY.*} macros can be used to reference host inventory values from one or several hosts in a trigger expression (supported since 4.0.0).
  • User macros and user macro context is supported for the tag name/value. User macro context may include low-level discovery macros.
  • Low-level discovery macros can be used for the tag name/value in trigger prototypes.

{EVENT.TAGS} and {EVENT.RECOVERY.TAGS} macros can be used in trigger-based notifications and they will resolve to a comma separated list of event tags or recovery event tags.

The following macros may be used in template and host-level tags:

  • {INVENTORY.*} macros
  • User macros
Substring extraction in trigger tags

Substring extraction is supported for populating the tag name or tag value, using a macro function - applying a regular expression to the value obtained by the {ITEM.VALUE}, {ITEM.LASTVALUE} macro or a low-level discovery macro. For example:

{{ITEM.VALUE}.regsub(pattern, output)}
       {{ITEM.VALUE}.iregsub(pattern, output)}
       {{#LLDMACRO}.regsub(pattern, output)}
       {{#LLDMACRO}.iregsub(pattern, output)}

Tag name and value will be cut to 255 characters if their length exceeds 255 characters after macro resolution.

See also: Using macro functions in low-level discovery macros for event tagging.

Viewing event tags

Event tags, if defined, can be seen with new events in:

  • MonitoringProblems
  • MonitoringProblemsEvent details
  • MonitoringDashboardProblems widget (in popup window that opens when rolling the mouse over problem name|

Only the first three tag entries are displayed. If there are more than three tag entries, it is indicated by three dots. If you roll your mouse over these three dots, all tag entries are displayed in a pop-up window.

Note that the order in which tags are displayed is affected by tag filtering and the Tag display priority option in the filter of MonitoringProblems or the Problems dashboard widget.

Performance and storage effects

It is expected that the use of event tags may have the following effects:

  • Event processing will be slower due to the creation of new records in the event tag table.
  • Operations related to manipulations with triggers inherited from templates will be slower since it's necessary to create one record per tag in the trigger tag table. Therefore the creation, update and removal of triggers will be slower.
  • Synchronization of configuration cache will be slower due to trigger tags.
  • Storage of event tags will require additional disk space which may be comparable to the size of existing trigger and event tables. Precise storage requirements depend very much on the number of tags created per trigger and event.