Zabbix vs Prometheus: Architecture, Pros, and super_exporter Integration

Monitoring Tools Overview

Zabbix, created by Alexei Vladishev and released in 2004, is a mature, enterprise‑grade distributed monitoring system that stores configuration and historical data in a relational database and offers a rich RESTful API. Prometheus, originally developed by SoundCloud and inspired by Google’s BorgMon, is an open‑source monitoring and time‑series database solution that includes a built‑in TSDB and tight integration with cloud‑native ecosystems such as Kubernetes.

Architecture Comparison

Zabbix Architecture

Zabbix Server – core C component that receives data from Agents/Proxies, aggregates, stores, and triggers alerts.

Zabbix Proxy – optional distributed collector that forwards data to the Server, reducing load for large environments.

Zabbix Agentd – runs on monitored hosts, gathers metrics, supports plugins and both push and pull data transfer.

Database – stores configuration and collected metrics; supports MySQL, Oracle, and optionally time‑series back‑ends.

Web Server – PHP‑based GUI for visualising data and configuring alerts.

Prometheus Architecture

Prometheus Server – scrapes metrics from targets, stores them in a high‑performance TSDB.

Jobs/Exporters – lightweight agents that expose metrics in Prometheus format, analogous to Zabbix Agents.

Pushgateway – receives metrics pushed by short‑lived jobs, which Prometheus later pulls.

Alertmanager – handles alert routing, deduplication and notification (e.g., email, SMS).

Web UI / Grafana – visualises metrics; Grafana is the de‑facto UI for Prometheus.

Strengths and Weaknesses

Zabbix Advantages

Product maturity – long history, extensive documentation, many ready‑made plugins.

Rich collection methods – supports Agent, SNMP, JMX, SSH, and both active and passive data transfer.

Scalability via Proxy – distributed monitoring reduces load on the central server.

Easy configuration – most settings can be managed through a web UI.

Prometheus Advantages

High processing capacity – a single instance can handle millions of metrics.

Flexible data model – multi‑dimensional tags enable powerful aggregation.

Powerful query language – PromQL supports arithmetic, joins, and percentile calculations.

Cloud‑native friendliness – native service discovery for containers, tight integration with Kubernetes and etcd.

Zabbix Deployment Status

The company runs multiple Zabbix instances per business line. They are stable but suffer from fragmented data, limited multi‑dimensional visualisation, and short retention periods that hinder capacity planning.

Zabbix Database Schema

Key tables include:

hosts – stores monitored host information (hostid, proxy_hostid, name, status).

items – defines monitoring items (itemid, type, hostid, name, key_, value_type, status).

hosts_groups – maps hosts to host groups.

host_groups – defines host‑group metadata.

problem – records problem events.

Historical data are kept in a family of tables (history, history_log, history_str, history_text, history_uint) each storing a specific data type.

Example query to list the top‑10 unresolved problems with formatted timestamps:

SELECT p.eventid AS 事件id, FROM_UNIXTIME(p.clock,'%Y-%m-%d %H:%i:%s') AS clock, p.name AS 触发事件, p.severity AS 事件等级 FROM problem p WHERE p.source='0' AND p.object='0' AND NOT EXISTS (SELECT NULL FROM event_suppress es WHERE es.eventid=p.eventid) AND p.r_eventid IS NULL ORDER BY p.eventid DESC LIMIT 10;

Example query to fetch float‑type history for a specific item within a time range:

SELECT itemid, FROM_UNIXTIME(clock) AS time, value FROM history WHERE itemid=29175 AND clock >= UNIX_TIMESTAMP('2022/06/07 00:00:00') AND clock <= UNIX_TIMESTAMP('2022/06/08 00:00:00');

super_exporter Integration

To address Zabbix’s limitations, a custom super_exporter was built. For each Zabbix instance, an independent read‑only replica is created; the exporter periodically extracts performance metrics from the Zabbix database and pushes them to Prometheus. The exporter also enriches metrics with business tags (department, product, cluster, etc.) sourced from host‑group tables.

Performance optimisation ensures that even when a single Zabbix instance monitors tens of thousands of items, the total scrape time stays below 30 seconds.

Grafana Visualization

Metrics collected by super_exporter are stored in a time‑series database and queried with PromQL. Grafana dashboards provide multi‑dimensional visualisation, health‑score calculations, risk ranking, and trend comparison across data‑centres.

Future Directions

The combined solution leverages Zabbix’s mature ecosystem and Prometheus’s efficient storage and visualisation. As metric volume grows, Thanos will be introduced for long‑term Prometheus storage. Further integration with CMDB systems will enrich metrics with additional business dimensions, supporting customised dashboards for different teams.