Choose a simple, descriptive name for each item.
Prefix item names (metric) with object name (metric location):
<metric location>: <metric name>, for example:
You may use “#” if the metric location is just a number or index:
Consider adding suffixes like “per second”, “per hour” etc to describe the metric better.
No user macros or $1 macros must be used in item names, they are deprecated and will be removed at some point.
Consider prefixing your item with “Get” if this a master item to highlight this item is the collector item, not the final metric.
Keys should use the hierarchical dotted format.
Required to split metrics of one template from another. In the simplest case, this may be a short product name.
e.g: nginx, pgsql, pgbouncer, docker
Component or sub-resource of the monitored object. It could be hierarchical as well.
e.g: upstream, pool, db, db.table, db.client
For example: max_reached.
If possible, prefer to name metrics just as they are named in the monitored object itself with an exception if metric format there is completely different or metric name there is totally confusing and not human-friendly.
Every key must start with a letter and must use only Latin letters in the lower case in the base part.
If you need a space, you could simply replace it with underscore “_”., e.g: response_time.
Remember that the max key length is 255 chars (including users params).
e.g: request_time. request_count
Consider appending .get for collectors, items that are responsible for retrieving data to be used in dependent items. (master items)
e.g: pgsql.db.get_connection [...], nginx.get_stub, nginx.get_logs
Consider using .rate for per second metrics.
Consider using .total for accumulators.
In params, first comes mandatory params the optional should follow.
Use this field to describe:
Don't forget to provide units wherever possible.
Add your units to the blacklist to stop automatic conversion where conversion is silly.
Use “!requests/s” to prevent “Krequests/s” to appear.
Use preprocessing to transform GB, MB, KB to B (Bytes).
Use preprocessing to transform ms, minutes, hours to seconds.
Always use value mappings where applicable, for example, when collecting discrete states.
Type of information determines the type of data as stored in the database after performing conversions. Available types: - Numeric (unsigned) - 64-bit unsigned integer - Numeric (float) - floating-point number, negative values can be stored. Allowed range: -999999999999.9999 to 999999999999.9999. Starting with Zabbix 2.2, receiving values in scientific notation (1e+7, 1e-4, etc.) is also supported. - Character – short text data - Log – long text data with optional log related properties (timestamp, source, severity, logeventid) - Text – long text data.
See Item configuration for more info.
If your item is a rate (i.e., “Change per second” preprocessing is applied) – use Numeric(float).
Additionally, don’t forget to use Numeric(float) if you need to store negative integers.
By default, use:
Update interval: 1m History: 7d Trends: 365d
Also, consider using preprocessing steps 'Discard unchanged (with heartbeat)' when collecting items that change rarely such as statuses or configuration data (e.g. serial numbers or hostname):
If the item is a health check:
1m with the heartbeat of 1h
If the item is an inventory item:
15m with the heartbeat of 24h
If the item has a tag “data: raw” (master items or items only needed for other calculated items, see below) - set history to 0 and trends to 0, as you don't need to keep such intermediate values.
Please note: never set update interval to more than 1d, as you will not see such data in the "Latest data" since Zabbix frontend considers values received more than 24h ago as not latest.
Always use time (1m, 5m, 1d…) suffixes in update intervals, history storage period, trends storage period, calculated item formulas to improve readability. Remember that you can use them in user macros too.
Use tags to logically group items using the recommended tagging model.
Please note that this model might become enforced in the future Zabbix releases. In this case, templates that do not follow specified rules will need to be updated.
system - low-level and system metrics not related to OS, unless a more specific component is defined
raw - denotes technical metric (e.g. master item)
business - internal information, e.g. number of company branches
kpi - internal information, e.g. monthly returned customers
sensor - internal information, e.g. pressure in a column still
|Specifies the metric type.
Custom values can be used, if the topic cannot be covered by pre-defined values.
At least one tag per item is mandatory; multiple tags are allowed.
If an item can be related to multiple components, set a separate tag for each one (see an example below).
For example, the item Total swap space should contain the following tags:
Use newlines and spaces to make long formulas human-readable.
SNMP OID field should not use any MIB objects, so templates would be working without MIBs imported. At the same time, provide metric name from MIB as an item key parameter and in the item description.
Leading '.' in OID should not be used.
|22.214.171.124.4.1.19126.96.36.199.1.52.0||FOUNDRY-SN-AGENT-MIB::snAgGblCpuUtil1MinAvg.0 or .188.8.131.52.4.1.19184.108.40.206.1.52.0|
Leave item field ‘Port’ empty for SNMP items. If left empty, then the port will be used from the SNMP host interface.
If you need to resort to external scripts – think about making them portable and easy to install as well.
Prefer to use Zabbix preprocessing in favor of complex data parsing with some scripts on the agent side:
Prefer to use Zabbix master item + dependent items in favor of multiple separate calls:
Reuse master item contents to create Low-level discovery rules. Then reuse master item values again to be used in future items from prototypes.
Master item history storage period
Master items values may be of a very large size (ZBXNEXT-223), while these values are only needed for preprocessing in dependent items. So, shrink its history storage period to a minimum, non-zero value which is 1h.
But what if we set history = 0? This setting will give you some additional issues:
So we suggest 1h as a safer choice at this point.