In modern IT environments, monitoring is not an optional discipline — it is an operational necessity. Zabbix is one of the most widely used open-source monitoring platforms in the world, providing organizations of any size with a complete observability solution — from simple ping checks to the monitoring of complex distributed systems with thousands of hosts. And all of this without license fees.
What Is Zabbix and Why Do Enterprises Use It?
Zabbix was developed by Alexei Vladishev in 1998 and has been available as an open-source project since 2001. The platform monitors servers, virtual machines, network devices, applications, and cloud services in real time. It collects metrics, evaluates them against configurable thresholds, and triggers alerts when needed.
Compared to commercial monitoring solutions, Zabbix stands out through:
- No license costs — even for large installations with thousands of hosts
- Full data ownership — all data stays within your own infrastructure
- Flexible architecture — scales from small environments to enterprise deployments
- Broad integration support — SNMP, IPMI, JMX, HTTP, databases, and more
- Active community and professional commercial support through Zabbix LLC
Zabbix Architecture: Server, Proxy, Agent
Zabbix consists of several components that are deployed differently depending on the size of the environment:
Zabbix Server is the central component. It processes incoming data, evaluates triggers, and sends notifications. In small environments, a single server that directly monitors all hosts is sufficient.
Zabbix Agent runs on every monitored system and delivers local metrics to the server. There are two generations: the classic zabbix-agent (version 1) and the more modern zabbix-agent2 (version 2), written in Go, which offers better performance and extended plugin support.
Zabbix Proxy collects data from a group of hosts and forwards it to the Zabbix Server. Proxies are essential in distributed environments — such as remote sites with limited WAN connectivity. The proxy buffers data locally so that no metrics are lost, even if the connection to the server is briefly interrupted.
[Remote Site A] [Remote Site B]
Hosts → Zabbix Proxy A → Hosts → Zabbix Proxy B
↓ ↓
[Zabbix Server (Headquarters)]
↓
[Zabbix Frontend (Web)]
↓
[Database: PostgreSQL / MySQL]
For the database, we recommend PostgreSQL with the TimescaleDB extension — the latter significantly optimizes the storage of time-series data and noticeably improves query performance in large installations.
Installation on Debian/Ubuntu
The official Zabbix repository provides up-to-date packages at all times:
# Add the Zabbix repository (example: Zabbix 7.0 LTS on Ubuntu 24.04)
wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_7.0-2+ubuntu24.04_all.deb
dpkg -i zabbix-release_7.0-2+ubuntu24.04_all.deb
apt update
# Install Zabbix Server, frontend, and agent
apt install -y zabbix-server-pgsql zabbix-frontend-php \
zabbix-apache-conf zabbix-sql-scripts zabbix-agent2
# Create the PostgreSQL database
sudo -u postgres createuser --pwprompt zabbix
sudo -u postgres createdb -O zabbix zabbix
# Import the schema
zcat /usr/share/zabbix-sql-scripts/postgresql/server.sql.gz | \
sudo -u zabbix psql zabbix
Next, configure the database connection in /etc/zabbix/zabbix_server.conf:
DBHost=localhost
DBName=zabbix
DBUser=zabbix
DBPassword=securePassword
Enable and start all services:
systemctl enable --now zabbix-server zabbix-agent2 apache2
The Zabbix frontend is then available at http://<server-ip>/zabbix. The setup wizard walks you through the initial configuration.
Monitoring Hosts with the Zabbix Agent
Install the agent on every Linux host you want to monitor:
# Add the Zabbix repository (same process as above)
apt install -y zabbix-agent2
Configure /etc/zabbix/zabbix_agent2.conf:
Server=192.168.1.10 # IP of the Zabbix Server (passive checks)
ServerActive=192.168.1.10 # IP for active checks
Hostname=webserver-prod-01 # Must match the hostname in Zabbix
systemctl enable --now zabbix-agent2
The host is then added in the Zabbix frontend under Configuration > Hosts > Create host and assigned to the appropriate template.
Key Metrics for Enterprise Monitoring
Zabbix collects an extensive range of system metrics out of the box. The most important ones for day-to-day operations:
| Category | Metrics | Recommended Thresholds |
|---|---|---|
| CPU | Utilization, load average, iowait | Warning >70%, Critical >90% |
| RAM | Available, used, swap usage | Warning <20% free, Critical <10% free |
| Disk | Usage, I/O wait, free inodes | Warning >80%, Critical >90% |
| Network | Throughput, error rate, collisions | Context-dependent |
| Services | Process running, port reachable | Immediate alert on failure |
| Log files | Error patterns in system logs | Configurable via regex |
The Zabbix agent also supports custom metrics. An example UserParameter that monitors the number of active database connections:
# In /etc/zabbix/zabbix_agent2.d/custom.conf
UserParameter=db.connections,psql -U monitor -c "SELECT count(*) FROM pg_stat_activity;" -t | tr -d ' '
Templates and Auto-Discovery
One of Zabbix’s greatest strengths is its template system — pre-configured collections of items, triggers, graphs, and dashboards for specific systems or services. Zabbix ships with hundreds of official templates, including:
- Linux by Zabbix agent (CPU, Memory, Disk, Network)
- Apache by HTTP, Nginx by HTTP
- PostgreSQL by Zabbix agent, MySQL by Zabbix agent
- VMware, Docker, Kubernetes
- Cisco, Juniper, MikroTik (via SNMP)
Templates are assigned to a host or host group and take effect immediately — without manually configuring individual items.
Auto-Discovery goes one step further: Zabbix regularly scans defined IP ranges or polls SNMP devices and automatically creates newly discovered hosts. Through Discovery Actions, templates, host groups, and trigger actions are automatically assigned to these hosts:
Administration > Discovery > Discovery rules > Create discovery rule
→ IP Range: 192.168.1.1-192.168.1.254
→ Checks: Zabbix Agent, ICMP Ping
→ Update interval: 1h
In larger environments, Auto-Discovery is combined with Low-Level Discovery (LLD), which automatically creates individual items for all network interfaces, disks, or database instances on a host, for example.
Alerting and Escalations
Zabbix alerts are based on triggers — logical expressions that operate on collected item values. A simple example:
{webserver-prod-01:system.cpu.util.avg(5m)} > 90
This trigger fires when the average CPU utilization over the past 5 minutes exceeds 90%.
Escalations enable multi-stage notification workflows: first, the responsible administrator is notified by email. If the problem remains open after 30 minutes, Zabbix escalates to the team lead. After another hour without a response, an alert goes to the on-call team. This logic is configured under Configuration > Actions.
Zabbix supports numerous notification channels:
- Email (SMTP)
- Slack, Microsoft Teams, Telegram (via webhooks)
- PagerDuty, OpsGenie
- SMS via external gateways
- Custom scripts for individual integrations
Dashboard and Visualization
The Zabbix frontend offers flexible dashboards that can be configured per user or as a global view. Available widgets include graphs, maps (Network Maps), problem lists, heatmaps, and data tables.
For advanced visualization, Zabbix integrates with Grafana — the Zabbix plugin for Grafana connects directly to the Zabbix API and allows creating professional dashboards using all Zabbix metrics as a data source.
Zabbix Compared
| Criterion | Zabbix | Prometheus + Grafana | Nagios | DATAZONE Control |
|---|---|---|---|---|
| License costs | Free | Free | Nagios XI is paid | Managed service |
| Entry barrier | Medium | High | Medium | Very low |
| Scalability | Very high | Very high | Limited | High |
| Agent required | Optional | Optional | Yes | Yes |
| Alerting | Built-in | Via Alertmanager | Built-in | Built-in |
| Auto-discovery | Yes | Limited | No | Yes |
| Managed/Hosted | Self-hosted | Self-hosted | Self-hosted | Fully managed |
| GDPR compliance | Self-managed | Self-managed | Self-managed | Included |
Integration with DATAZONE Control
Zabbix and DATAZONE Control are not mutually exclusive — they complement each other well. Zabbix provides deep technical metrics at the system and application level, while DATAZONE Control covers higher-level IT management: patch management, compliance checks, inventory, and automated remediation.
In practice, the recommended setup is: Zabbix handles granular metric collection and forwards critical alerts via webhook to DATAZONE Control. DATAZONE Control correlates these alerts with the current patch status, open compliance violations, and known maintenance windows — and can automatically initiate countermeasures for certain problem patterns, such as restarting a service or escalating to the DATAZONE support team.
Best Practices for Large Environments
Anyone running Zabbix for more than 500 hosts should pay attention to the following:
Database optimization is the most critical factor. TimescaleDB as a PostgreSQL extension significantly reduces storage requirements and speeds up queries over long time ranges. Regular housekeeping (History, Trends) must be actively configured:
# Housekeeping parameters in zabbix_server.conf
HousekeepingFrequency=1
MaxHousekeeperDelete=5000
Zabbix Proxies at remote sites or for logical network segments (e.g., DMZ, production network) reduce the load on the central server and increase fault tolerance.
Prefer active checks over passive checks — with active checks, agents connect to the server themselves, which simplifies firewall rules and improves scalability.
Choose housekeeping intervals for History and Trends carefully: 7–30 days of history is sufficient for operational dashboards; trend data (hourly averages) can be retained significantly longer.
Looking to deploy Zabbix professionally in your IT infrastructure, or interested in a fully managed monitoring solution? Our team is happy to help — learn more about our Linux infrastructure services or get in touch with us directly.
More on these topics:
More articles
Backup Strategy for SMBs: Proxmox PBS + TrueNAS as a Reliable Backup Solution
Backup strategy for SMBs with Proxmox PBS and TrueNAS: implement the 3-2-1 rule, PBS as primary backup target, TrueNAS replication as offsite copy, retention policies, and automated restore tests.
Proxmox Notification System: Matchers, Targets, SMTP, Gotify, and Webhooks
Configure the Proxmox notification system from PVE 8.1: matchers and targets, SMTP setup, Gotify integration, webhook targets, notification filters, and sendmail vs. new API.
TrueNAS with MCP: AI-Powered NAS Management via Natural Language
Connect TrueNAS with MCP (Model Context Protocol): AI assistants for NAS management, status queries, snapshot creation via chat, security considerations, and future outlook.