Zabbix Infrastructure Monitoring Setup
We often encounter situations where a company already uses Prometheus but cannot cover network equipment, old Windows servers, or SNMP devices. We use Zabbix—an open-source system that natively supports agent push, active checks, SNMP, IPMI, and JMX. It's an ideal choice for on-premise infrastructure with heterogeneous equipment.
On one project, we found Zabbix agents at version 3.0 and the server at 6.0. Upgrading all agents via Ansible took two days, but after migrating to Zabbix 7.0, the database load dropped by 40% and incident response time decreased by 30%. Our experience confirms: proper Zabbix configuration delivers measurable results.
Why Zabbix, Not Prometheus?
Prometheus is great for cloud-native microservices but falls short in scenarios with SNMP, Windows, and legacy applications. Zabbix handles three times more metrics on a single server with the same resources and is easier to set up for hybrid infrastructure. According to our data, Zabbix reduces network monitoring deployment time by 2 days.
Architecture: Server, Proxy, Agents
A typical production setup consists of three layers. Zabbix Server—central component, stores configs and data. Zabbix Proxy—offloads the server and monitors remote network segments. Zabbix Agent 2 (Go, starting from 5.0)—on each host.
Zabbix Server is demanding on the database—PostgreSQL is preferable to MySQL for large installations (10k+ items). Critical is the configuration of the TimescaleDB extension for PostgreSQL: it reduces I/O load significantly when working with metric history.
Config /etc/zabbix/zabbix_server.conf—key parameters:
DBHost=localhost
DBName=zabbix
DBUser=zabbix
DBPassword=secret
StartPollers=80
StartPollersUnreachable=20
StartPingers=20
StartTrappers=10
CacheSize=512M
HistoryCacheSize=256M
TrendCacheSize=128M
ValueCacheSize=512MCacheSize and ValueCacheSize are the first things to increase as infrastructure grows. If Zabbix Server logs cache is full, data starts to get lost.
Component comparison:
| Component | Role | Recommendations |
|---|---|---|
| Zabbix Server | Central collection and storage | PostgreSQL + TimescaleDB, minimum 4 vCPU, 8GB RAM per 1000 hosts |
| Zabbix Proxy | Collection in remote segments | SQLite for < 1000 hosts, otherwise PostgreSQL |
| Zabbix Agent 2 | Collect metrics from hosts | Version 6.0+, supports active and passive modes |
How to Set Up Low-Level Discovery?
LLD automatically creates items and triggers for dynamic entities: file systems, network interfaces, Kafka partitions, PostgreSQL instances. The built-in discovery vfs.fs.discovery returns JSON with a list of mounted file systems, and for each one automatically creates an item vfs.fs.size[{#FSNAME},pfree] and a trigger when usage exceeds 80%.
A common problem: discovery creates items for temporary file systems (tmpfs, devtmpfs), causing noise. It is solved through Filter in the discovery rule with a regex exclusion on {#FSTYPE}. We configure such filters for each client to avoid false positives.
Templates: The Heart of Zabbix Configuration
All the power of Zabbix lies in the template system. A template contains items (metrics), triggers (threshold conditions), graphs, discovery rules. One template attached to a thousand hosts—changing the template applies to all at once.
Out-of-the-box templates cover 90% of tasks: Linux by Zabbix agent, Nginx by Zabbix agent, PostgreSQL by Zabbix agent, Docker by Zabbix agent. Additional ones are available on Zabbix Share.
Custom item for monitoring RabbitMQ queue size via UserParameter in /etc/zabbix/zabbix_agent2.conf:
UserParameter=rabbitmq.queue.messages[*],rabbitmqadmin --host=127.0.0.1 --user=guest --password=guest list queues name messages 2>/dev/null | awk -v q="$1" '$2==q{print $4}' Then this key rabbitmq.queue.messages[critical_queue] is added as an item in a template with type Zabbix agent and a trigger for value > 10000.
Triggers and Notifications
Trigger expression in Zabbix—a custom DSL. Example for high iowait alert:
avg(/Linux-server/system.cpu.util[,iowait],5m)>30 Since version 6.0, expression macros and functions like changecount(), timeleft() have appeared. According to Zabbix Documentation 7.0, this allows writing predictive alerts: a trigger fires not when the disk is full, but when, at the current fill rate, less than 4 hours remain until the critical value.
Media types for notifications—Slack, Telegram, PagerDuty, email, SMS. Configured via Administration → Media Types with message templates in Zabbix-specific JavaScript.
Key Zabbix metrics:
| Metric | Value | Effect |
|---|---|---|
| Incident response time | 30% reduction | Less downtime |
| Metrics per server | Up to 1 million | High density |
| CPU load at 10k items | 20% | Low overhead |
How We Implement Zabbix: Work Process
- Audit of current infrastructure: host inventory, agent version check, analysis of templates and triggers.
- Schema design: host groups, template hierarchy, history retention policy.
- Installation and configuration of server, proxies, agents (via Ansible role).
- Template import, LLD setup, triggers and actions setup.
- Testing and debugging alerts.
- We train your team on Zabbix operations.
- Documentation on architecture and processes.
Example Ansible role for Zabbix Agent 2 installation
- name: Install Zabbix Agent 2
hosts: all
tasks:
- name: Add Zabbix repository
apt_repository:
repo: 'deb http://repo.zabbix.com/zabbix/7.0/ubuntu/ $(lsb_release -sc) main'
when: ansible_os_family == 'Debian'
- name: Install agent
apt:
name: zabbix-agent2
state: latest
- name: Configure agent
template:
src: zabbix_agent2.conf.j2
dest: /etc/zabbix/zabbix_agent2.conf
notify: restart agentWhat Is Included in Our Zabbix Setup Work
- Audit of current infrastructure (identifying outdated agents, unused templates).
- Monitoring scheme design (host groups, template hierarchy).
- Installation and configuration of Zabbix Server, Proxy, Agent 2.
- Setting up LLD for automatic resource discovery.
- Creation of custom templates and triggers for your tasks.
- Integration with notification systems (Telegram, Slack, email).
- Handover of documentation and training for your team.
- One month of post-implementation support.
We work with infrastructure from 50 to 5000 hosts. Our engineers hold Zabbix Certified Specialist certifications and have 10+ years of DevOps experience. We guarantee stable monitoring system operation and a 30% reduction in incident response time.
Timelines and Cost
- Greenfield installation for infrastructure up to 50 hosts: 2 to 3 days.
- Migration from previous Zabbix version with history preservation: 3 to 5 days.
- Adding network and equipment monitoring (SNMP): adds 1-2 days.
Cost is calculated individually after an audit. Budget savings on incidents after Zabbix implementation reach up to 40% due to rapid problem detection.
Want a consultation? Write to us and we will assess your project turnkey.