Zabbix
Official site · Latest version: 7.4.11
Zabbix: What It Is, How It Works, and When to Use It
Zabbix is a self-hosted, open-source monitoring platform that covers network devices, servers, cloud instances, applications, and services from a single installation. It has been in active development since 2001, carries no per-host licensing cost, and ships everything — collection, storage, alerting, and visualisation — in one package. That breadth is its main selling point; it is also the source of most of its configuration complexity.
Current GA release: 7.4.11 (released June 2026 — release notes), current as of July 2026. Teams wanting long-term support run the 7.0 LTS line (latest 7.0.28) instead of the newer feature branch.
What Zabbix actually monitors
Zabbix collects data through several distinct mechanisms, and understanding which one applies to a given target matters before you deploy:
| Collection method | Typical target | Notes |
|---|---|---|
| Zabbix agent 2 (active/passive) | Linux, Windows, macOS hosts | Go-based; replaces the older C agent for most new deployments |
| SNMP v1/v2c/v3 | Network switches, routers, UPS | Supports bulk walks; MIB browser built in |
| IPMI | Physical servers | Requires IPMI access on the BMC |
| JMX | Java applications | Via zabbix-java-gateway |
| HTTP agent | REST APIs, web checks | Full request/response scripting |
| ODBC | Databases | Queries any ODBC-compatible source |
| Zabbix proxy | Remote or isolated sites | Collects locally, ships to server; reduces WAN polling load |
The agent 2 plugin architecture (introduced in 6.0) lets you add collection plugins without recompiling — useful for monitoring MongoDB, Redis, or Docker without waiting on a vendor release cycle.
The core data model: items, triggers, and templates
Every metric in Zabbix is an item — a discrete polling definition that specifies what to collect, from where, how often, and how to store it. Items are the smallest unit of configuration, and everything else hangs off them.
Items
An item definition includes:
- Key — a string that identifies the metric (e.g.,
net.if.in[eth0],system.cpu.load[all,avg5]) - Type — the collection method above
- Update interval — can be a fixed period or a flexible schedule using the cron-like syntax added in 6.4
- Value type — numeric (float or unsigned), character, log, or text
- Preprocessing — a pipeline of transformations applied before storage (JSONPath extraction, regular expressions, multipliers, throttling)
The preprocessing pipeline is where a lot of real-world work happens. An HTTP agent item that returns a JSON blob will usually have a JSONPath step to extract the field you actually want, followed by a multiplier to convert bytes to megabits.
Triggers
A trigger is a boolean expression evaluated against item history. When it evaluates to PROBLEM, Zabbix fires the alert pipeline. The expression language uses functions over time windows:
last(/host/net.if.utilization[eth0])>80
and avg(/host/net.if.utilization[eth0],5m)>75
This two-condition pattern — last value plus rolling average — is the standard way to avoid alerting on a single spike. Trigger severity levels run from Not classified through Disaster, and each level can route to different notification media.
Triggers reference items by host/key path, which means the same trigger expression works across a host group without modification once it is inside a template.
Templates
A template bundles items, triggers, graphs, dashboards, and discovery rules into a reusable unit that you link to hosts or host groups. Zabbix ships with around 400 out-of-the-box templates covering Cisco IOS, Juniper, Linux by Zabbix agent, AWS, Azure, PostgreSQL, and many others. The Zabbix integrations catalogue lists community and vendor-contributed additions.
Templates support inheritance: a child template can override individual items or triggers from a parent without forking the entire thing. In practice, building a site-specific layer on top of an upstream vendor template is the cleanest way to add local customisation while still pulling upstream updates.
Low-level discovery (LLD)
Discovery rules automate item and trigger creation for dynamic targets — network interfaces, mounted filesystems, running services, Kubernetes pods. A discovery rule runs a query that returns a JSON array of found objects; Zabbix then instantiates item and trigger prototypes for each. This is what makes Zabbix practical at scale: you do not manually create 48 interface items per switch.
Alerting and notification
Zabbix routes alerts through media types: email, SMS, Slack, PagerDuty, Opsgenie, webhook (generic HTTP), and others. Notification is driven by actions, which match on event conditions (trigger severity, host group, tag values) and define the operation — send a message, run a remote command, or acknowledge the problem.
Tag-based correlation (added in 5.2 and extended in 6.x) lets you suppress or group events by arbitrary key/value pairs on hosts and triggers. This is worth knowing because it significantly changes how you structure alert routing versus the older host-group-only model.
Event correlation rules can close problems automatically when a paired “resolution” event arrives — useful for flap prevention on noisy link-state traps.
Storage and retention
Zabbix stores history in a relational database: PostgreSQL (recommended for new deployments), MySQL/MariaDB, or Oracle. TimescaleDB is supported as a PostgreSQL extension and is the right choice for any deployment storing more than a few weeks of high-frequency data — the automatic chunking and compression materially reduce table bloat.
Trend tables store hourly min/max/avg aggregates independently of raw history, so you can set a short raw-history window (7–14 days) while keeping a year of trend data without the storage growing linearly with polling frequency.
Housekeeper runs automated cleanup on configurable schedules. At scale (50 000+ items), tune PostgreSQL autovacuum aggressively alongside Zabbix’s own housekeeping settings, or history growth will outpace cleanup.
Zabbix vs SolarWinds NPM vs Prometheus
These three tools overlap on network and infrastructure monitoring, but they come from different design philosophies. Here is an honest comparison.
Zabbix vs SolarWinds NPM
SolarWinds NPM is a commercial, Windows-hosted platform aimed at network operations teams that want point-and-click device discovery, built-in topology maps, and vendor-supported integrations. It earns its licence cost with:
- Automatic network topology discovery and L2/L3 maps
- Tight Cisco/Juniper/HP integration with interface-level SLA tracking
- A polished, role-based web UI that non-engineers can operate
Zabbix wins on:
- Cost — no per-node or per-module fees. A 10 000-node Zabbix deployment costs the same licence as a 10-node one (i.e., nothing).
- Flexibility — you can monitor anything that exposes data in any way. SolarWinds NPM is primarily SNMP + WMI.
- Deployment control — air-gapped, on-premises, multi-datacenter with proxies. SolarWinds requires Windows infrastructure.
Choose SolarWinds NPM when: your team is network-ops-first rather than DevOps-oriented, you need polished out-of-the-box reporting for management, and budget is less constrained than time.
Choose Zabbix when: you need a single platform for network + server + application + cloud; you are not paying per node; or you have the engineering capacity to configure it properly.
Zabbix vs Prometheus
Prometheus is a pull-based metrics system built for dynamic, containerised environments. It uses a scrape model (HTTP /metrics endpoints), stores data in a local TSDB, and integrates natively with Kubernetes and the wider Cloud Native ecosystem.
The key structural differences:
| Dimension | Zabbix | Prometheus |
|---|---|---|
| Collection model | Push (agent active mode) and pull (passive, SNMP, HTTP) | Pull (scrape) |
| Target discovery | LLD, host groups, Zabbix API | Service discovery (Kubernetes, Consul, EC2, etc.) |
| Data model | Items with preprocessing pipelines | Labels on time series |
| SNMP / IPMI / JMX | Native | Via exporters (snmp_exporter, ipmi_exporter) |
| Long-term storage | Built-in (Postgres/TimescaleDB) | External (Thanos, Cortex, Mimir) |
| UI | Built-in dashboards | Grafana (near-universal) |
| Config style | Web UI + API | YAML files + GitOps |
Prometheus wins for Kubernetes-native environments, teams already running Grafana, and anything where service discovery against a dynamic inventory matters more than SNMP polling. Its label model and PromQL are more expressive for high-cardinality metric slicing.
Zabbix wins for mixed environments — where you have legacy switches on SNMP, bare-metal servers, a VMware cluster, and some cloud VMs all in the same monitoring domain. Running one Zabbix server is simpler than running Prometheus plus snmp_exporter plus node_exporter plus an external storage backend plus Grafana for that scenario. Zabbix’s agent also handles log file monitoring and active checks natively, which Prometheus does not.
Note: Neither tool is universally better. Large organisations often run both: Prometheus + Alertmanager for containerised workloads, Zabbix for network infrastructure and legacy hosts.
Where Zabbix fits well
- Mid-to-large networks with heterogeneous targets — routers, switches, servers, and applications in one pane.
- Organisations with budget constraints — open-source licensing removes per-node costs at scale.
- Teams comfortable with configuration — the complexity pays off if you invest in templates and LLD properly.
- Sites needing SNMP trap ingestion + polling — Zabbix handles both without a separate trap daemon.
- Multi-site deployments — proxy architecture distributes collection while keeping centralised visibility.
Where it is harder work
- Kubernetes-first environments — the Zabbix operator for Kubernetes exists but is less mature than the Prometheus/Grafana stack. Use Prometheus there.
- Sub-10-second polling at very high cardinality — TimescaleDB helps, but Prometheus’s write path is faster for extremely high-frequency scrapes.
- Teams that want a SaaS option — there is no hosted Zabbix Cloud; everything is self-managed. (Zabbix offers commercial support contracts, not a managed service.)
- Minimal-ops environments — the initial configuration overhead is real. Budget time for template design and LLD rules.
Deployment quick-start outline
Full installation docs live in the official Zabbix manual. The typical path for a new self-hosted deployment:
- Install Zabbix server + frontend from the official packages for your OS.
- Configure the database — PostgreSQL with TimescaleDB is the recommended stack for production.
- Deploy Zabbix agent 2 on Linux/Windows hosts; configure active checks pointing to your server.
- Import vendor templates for your network devices from the integrations catalogue.
- Define host groups and hosts, link templates, verify item data is arriving.
- Configure media types and actions for alerting before you put it in front of production traffic.
Sources & further reading
- Zabbix 7.4.11 release notes — version and changelog source
- Zabbix documentation 7.4 — items, triggers, templates, LLD
- Zabbix integrations catalogue — official and community templates
- TimescaleDB + Zabbix setup — official guide
- Zabbix agent 2 plugins — extension list
- Prometheus vs Zabbix — community thread, zabbix-discuss — practitioner perspectives (search “prometheus comparison”)