Documentation

Template configuration

Name

All parts are separated by spaces, but underscores can also be used.

All names (group, template, item, trigger, graph, tag, dashboard, discovery) use normal case inside the specific part – for example, "Zabbix server".

To distinguish templates, the most popular data collection method can be stated as an extra suffix at the end of the name, for example: “by SNMPv1”, “by SNMPv2”, “by SNMPv3”, “by Zabbix agent”, “by Zabbix agent active”, “by IPMI”, “by JMX”, “by ODBC” and so on.

Since Zabbix 5.2, standard template names no longer include the word "Template" and the <Category short name> prefix. A name should start with the <Template name> itself (the specific part) and may optionally be followed by the data collection method.
Prior to 5.2: Template App Nginx by HTTP, Template DB MySQL
Since 5.2: Nginx by HTTP, MySQL

Good Bad
Nginx by HTTP
MySQL
Brocade switch by SNMPv2
Brocade switch SNMPv2
Brocade switch_by SNMPv2
Agent 2 template NGINX
Template DB MySQL
SNMP Brocade switch
Brocade switch Template
Template Brocade Switch
Visible name

Currently, we suggest leaving the template visible name empty.

Description

Use this field to provide a short overview of the template, including:

  • Short description
  • Template homepage URL (at share.zabbix.com or github.com or else)
  • Template author
  • If documentation is quite short – documentation can be provided inline
  • Current template version
  • The simple changelog can be provided as well
Choosing a template group

All templates must be added into a template subgroup called Templates/<Category Full Name>.

Good Bad
“Cisco by SNMP” added into “Templates/Network Devices” “Cisco by SNMP” added into “Datacenter/Network” group
Tags

Use tags to logically group templates using the recommended tagging model.

Please note that this model might become enforced in the future Zabbix releases. Templates that do not follow specified rules will need to be updated.

Template tags

Tag Value Description
class application - user-facing software, e.g. MS Exchange, Jenkins, GitLab
business - reserved for user-defined templates
database - database management systems, e.g. MongoDB
device - embedded hardware and devices, such as phones, smart bulbs, video cameras, etc.
hardware - computer hardware, such as servers, workstations, etc.
network - network hardware routers, switches, WLAN, etc.
os - operating system, e.g. FreeBSD, Windows, Linux
power - power supply sources, e.g. APC UPS
service - external services and APIs, e.g. Bank's PSD2 API
software - system software and application platforms, e.g. VMWare, Bind, K8s
storage - network and attached storage, such as SANs, disk enclosures, etc.
voip - VOIP hardware or software including video conferencing, e.g. Asterisk, Cisco PBX
Specifies the class of the monitoring target (such as an area, type, etc.)

At least one tag is mandatory; multiple tags are allowed but not recommended.
target Product name, brand name, a combination of the name and model number, or any other convenient reference. Specific monitoring target within the class.

At least one tag is mandatory; multiple tags are allowed.

For example, the template Mikrotik hAP ac2 might contain the following tags:

class: network; target: mikrotik; target: mikrotik-hap-ac2
Tag name and value format
  • Must be written in lowercase
  • The following character sets are allowed: a-z, 0-9, -, _, . (alphanumeric, minus, underscore, dot)
  • For word separation, a hyphen (minus) is preferred over an underscore ("cloud-region", not "cloud_region")
  • ASCII encoding is preferred, but UTF-8 is also supported
  • When using common nouns as tag values, use them in the singular form, unless the term is only used in the plural form ("pipeline", not "pipelines")
  • Length limit for each tag name or value is 255 characters
User macros

User macros and low-level macros accept only uppercase characters, that is [A-Z0-9._].

Consider using template specific prefix (namespace) to avoid potential conflicts with other templates.

Good Ok Bad
{$MYSQL.HOST}
{$MYSQL.PORT}
{$MYSQL.PARAM1}
{$MYSQL_HOST}
{$MYSQL_PORT}
{$MYSQL_PARAM1}
{$HOST}
{$PORT}
{$PARAM1}

Use macro context in objects from LLD. This way you can change and tune macros not only on the host level but on the LLD entity level.

Good Bad
{$IF.ERRORS.WARN:”{#IFNAME}”}
{$TEMP.MAX.WARN:”{#SENSORNAME }”}
{$IF.ERRORS.WARN}
{$TEMP.MAX.WARN}

Use only widely accepted word shortenings in macro names, such as:

WARNING – WARN
CRITICAL – CRIT
PERCENTAGE – PCT
TEMPERATURE – TEMP
ERRORS – ERR
DISCARDS – DISC
HOSTNAME - HOST
DATABASE – DB
PASSWORD – PASS
USERNAME - USER
THRESHOLD – THRESH
CONNECTIONS - CONN
MAXIMUM – MAX
MINIMUM – MIN
AVERAGE – AVG
SECOND – SEC

If there is no good short-form - prefer to set macro name long but clearly understandable.