Learn Zabbix - Items, Data Collection & Preprocessing

#Introduction

In episode 5 you linked templates and hosts started producing data. Episode 6 takes you one level deeper — to items, the most basic unit of the entire Zabbix. An item defines what is measured, where the data comes from, and how often. Understanding items means understanding how Zabbix talks to the world.

We'll also cover preprocessing, one of the most underrated features even though it matters most for data quality. Raw data from applications is rarely ready to use directly: JSON needs extracting, units need converting, and errors need handling. This episode gives you the entire toolkit.

#Item Types and Keys

#Available Item Types

Zabbix supports many item types for various data sources:

• Zabbix agent: values from the agent, both active and passive, using keys like system.cpu.util.
• SNMP: values from network devices via OID, for example 1.3.6.1.2.1.1.1.0.
• ICMP ping: host availability via icmpping, icmppingloss, icmppingsec.
• IPMI: hardware health from server BMCs.
• JMX: Java application metrics via the JMX gateway.
• HTTP agent: HTTP requests for APIs and websites, with JSON or XML parsing.
• Database monitoring: direct SQL queries to MySQL or PostgreSQL.
• zabbix_sender: values sent by external scripts.

zabbix_get -s 192.168.1.20 -k system.cpu.util[,user]

The command zabbix_get -s ... -k system.cpu.util[,user] executes an agent key for CPU user usage. Each item type has its own key and argument syntax — the habit of testing keys with zabbix_get will save you hours of troubleshooting.

#Key Structure

A key consists of a name and arguments separated by commas, for example system.cpu.util[avg1]. Arguments can include parameters like interval or format. For SNMP, instead of a key you specify the OID and the data type of the query result. Understanding key structure is a prerequisite for creating manual items and custom templates.

#Intervals and Data Lifetime

#Collection Interval and Custom Intervals

Every item has a default interval — official templates typically use 1 minute. You can adjust it per item: shorten it for important items, lengthen it for items that rarely change. Intervals that are too short overload the server and database, while ones that are too long make data less responsive.

A healthy policy is to set the default interval in the template, then override only for items that really need it. All items on a host are inherited from the template — you don't need to configure intervals hundreds of times.

#Preprocessing: Normalizing Raw Data

#Why Preprocessing Is Needed

Collected data is rarely in an ideal shape. A real example: an API returns JSON with a CPU value nested in a nested structure, or a script sends a percentage as a string with a percent sign. Preprocessing is a chain of steps that turns a raw value into a value ready to be stored and analyzed.

#Preprocessing Steps

Zabbix preprocessing supports many steps that can be chained:

• JavaScript: free-form transformations using JS scripts.
• JSONPath and XML XPath: extract values from structured documents.
• Custom multiplier: multiply or divide, for example converting bytes to megabytes.
• Regular expression: extract or remove parts of a string.
• Custom on fail: the action when preprocessing fails — for example set a constant value, discard, or flag an error.

Example JavaScript preprocessing

var data = JSON.parse(value);
return data.metrics.cpu.usage;

The script above extracts cpu.usage from nested JSON. In the frontend, preprocessing steps are configured in the item form — Zabbix executes the steps in sequence, and the output of the first step becomes the input of the next one.

#Example: Parsing JSON from an HTTP Agent

A typical combination: an HTTP agent item fetches an API endpoint, then preprocessing uses JSONPath to grab a single field.

{
  "status": "ok",
  "metrics": {
    "cpu": 42.5,
    "memory": 61.3
  }
}

To grab the cpu value, the JSONPath used is $.metrics.cpu. An HTTP agent item with the endpoint URL plus a JSONPath preprocessing step will produce the number 42.5, ready to be the basis of a trigger. This is a very common pattern for monitoring modern API-based applications.

#Connecting Items with Triggers

#Values Ready for Evaluation

After preprocessing, item values are clean and ready to be evaluated by triggers. In episode 7, you'll write expressions like last(/host-key) against these values. The quality of the data produced by an item determines the reliability of the entire alerting chain — dirty items produce triggers that are prone to false alarms.

#Latency and Internal Checks

Don't forget to monitor the collection process itself. Zabbix internal items like zabbix[queue] or zabbix[internal,history] show the health of the data pipeline. The habit of monitoring these internal items will be very helpful when episode 17 discusses capacity planning and performance tuning.

#Closing

Episode 6 peeled apart Zabbix's smallest unit: item types from agent to HTTP agent, key structure and intervals, and preprocessing that turns raw data into clean values via JavaScript, JSONPath, XPath, and multipliers.

Key takeaways:

• An item is the unit of data collection; the type determines the source and how it's read.
• A key with arguments is the item's language, for example system.cpu.util[,user].
• Wise intervals: default in the template, override per item.
• Preprocessing chains steps to normalize raw data.
• JSONPath and JavaScript are your main weapons against modern APIs.

In the next episode 7 we'll discuss triggers, events, and problem detection — writing the expression builder with last(), avg(), change(), and count(), understanding severity, and the event lifecycle from problem to recovery.