What Zabbix covers
Zabbix monitors servers, network devices, virtual platforms, databases and applications. It collects data through its own agents and without agents through SNMP, IPMI, HTTP checks, JMX, ICMP and scripts. Triggers evaluate the collected values, problems open and close automatically, and actions send notifications, run escalations or execute remote commands.
Templates and low-level discovery do much of the work in a large estate. A template bundles items, triggers, graphs and discovery rules for a device type or service, and discovery creates per-interface, per-filesystem or per-database items as they appear. The quality of a Zabbix deployment depends largely on which templates are linked, how their thresholds are tuned and who owns each host group.
It suits estates with substantial on-premises infrastructure, network equipment and segmented networks, where one tool covers availability and capacity monitoring. Cloud-native services and short-lived containers can be monitored too; check that discovery and housekeeping settings suit hosts that come and go.
Components and what each one needs
A production deployment is a small distributed system. Each component has its own sizing, availability and upgrade concerns.
Server
Collects data, evaluates triggers and runs actions. It can run as a native HA cluster with one active node and standby nodes.
Database
Holds configuration, history and trends on MySQL, MariaDB or PostgreSQL, optionally with TimescaleDB. History volume is the main sizing concern.
Web frontend
A PHP application for configuration, dashboards and problem views, plus the API used by automation. It needs TLS and authentication settings.
Proxies
Collect data for the server in remote sites or segmented networks and buffer it during outages. Since 7.0, proxy groups redistribute hosts when a proxy goes offline.
Agents
Zabbix agent and agent 2 run on monitored hosts. Agent 2 is written in Go and adds plugins for databases, containers and other services.
Size from what you collect
The Zabbix requirements page starts at 2 vCPU and 8 GiB of memory for about 1,000 monitored metrics and reaches 32 vCPU and 96 GiB for about 1,000,000. Refine those examples with these drivers.
| Driver | Effect | What to measure |
|---|---|---|
| New values per second | Sets server, proxy and database write load. | Items per host multiplied by host count and divided by update interval, from a pilot. |
| History and trends | Drive database size and housekeeping load. | Retention per item type, and whether trends can replace raw history for older data. |
| Preprocessing and discovery | Add CPU load on server and proxies. | Number of discovered entities and preprocessing steps on high-frequency items. |
| Remote sites | Determine proxy count and buffering needs. | Hosts per site, link reliability and how long a site may be disconnected. |
High availability and topology
In native HA mode several Zabbix servers share one database, one node is active and standby nodes run only the HA manager. The failover delay is configurable from 10 seconds to 15 minutes, with one minute as the default. The frontend finds the active node from the database.
Server HA does not replicate the database. Give PostgreSQL or MySQL its own replication and failover, and test that the server reconnects after a switchover.
Place proxies in each remote site or network zone so agents and devices talk to a local collector. Group proxies where a site needs redundancy. List every HA server node in each proxy's Server setting so proxies follow a failover.
Point agents at all HA nodes or at their local proxy. Prefer active checks where firewalls block inbound connections, and manage agent configuration through automation.
Access, SSO and hardening
The frontend supports internal, HTTP, LDAP and SAML authentication, and multi-factor authentication with TOTP or Duo Universal Prompt. Just-in-time provisioning creates accounts on first login for LDAP and SAML users, mapping directory groups to Zabbix user groups and roles. Use host group permissions so each team sees and changes only its own systems, and give automation API tokens with an expiry date.
Encrypt connections between server, proxies and agents with pre-shared keys or certificates. Restrict remote commands on agents with AllowKey and DenyKey rules, and review which actions can run scripts on monitored hosts. Keep the frontend behind TLS and limit access to the Super admin role.
In networks without outbound internet access, set AllowSoftwareUpdateCheck to 0, since from 7.0 Zabbix checks a public endpoint for updates by default, and mirror packages into internal repositories.
Release policy, license and compatibility
Dates are from the Zabbix life cycle page at the time of writing. Check it before planning an upgrade.
| Topic | Detail | Planning note |
|---|---|---|
| LTS releases | About every 18 months, supported for five years: three years of full support, then two years of critical fixes only. | Suits production estates that prefer fewer, planned upgrades. |
| Standard releases | About every six months, with six months of full support followed by limited support. | Suitable when a new feature is needed and the team can upgrade often. |
| Current LTS lines | 7.0 LTS has full support until June 30, 2027 and limited support until June 30, 2029. 6.0 LTS limited support ends February 28, 2027. | Estates on 6.0 should schedule their upgrade now. 8.0 LTS is planned for Q4 2026. |
| License | Zabbix 7.0 and later use AGPL-3.0; versions up to 6.4 were GPLv2. | Review AGPL obligations if you modify Zabbix and offer it to others over a network. |
| Compatibility | Proxies must match the server major version for full support. Outdated proxies can still send data but receive no configuration updates. | Upgrade the server first, then proxies promptly. Agent upgrades are recommended and can follow later. |
Backups, upgrades and migration
Back up the database, server, proxy and frontend configuration files, custom alert and external scripts, and certificates or keys. Export templates and media types to version control. A restore test should bring up the frontend, show recent history and send a test notification.
The server upgrades the database schema when the new version starts, and large databases can take a long time. Rehearse the upgrade on a copy of the production database to measure it, back up first, then upgrade the server, then the proxies. SQLite-based proxies can discard their local database when they find an older version, so plan for buffered data on those proxies. The current documentation lists direct upgrades to 7.4 from earlier releases, including 6.0 LTS.
Migrations from Nagios, Icinga or commercial monitoring tools start with an inventory of checks, thresholds and notification routes. Map them to official templates where possible, keep custom checks only where they add value, and tune triggers during a parallel run. Moving every legacy check across tends to import its alert noise too.
Zabbix operating ownership
Zabbix becomes useful when every alert has an owner who can act on it and every host group has someone who keeps its templates current.
Monitoring platform
- Runs server nodes, proxies, frontend and database.
- Watches internal metrics such as queue and cache usage.
- Plans LTS upgrades and tests restores.
Service and network teams
- Own templates, thresholds and maintenance windows.
- Remove triggers nobody acts on.
- Keep host inventory and tags accurate.
Security
- Reviews roles, API tokens and remote command rights.
- Confirms encryption between components.
- Monitors authentication and audit log entries.
Change record
- Keep exported templates in version control.
- Record version and schema upgrade time per upgrade.
- Note notification route changes with an owner.
Zabbix deployment questions
PostgreSQL with TimescaleDB or MySQL?
Both are supported. Choose the database your team can operate, replicate and restore with confidence. TimescaleDB adds compression and partition-based housekeeping for history, which helps at larger scale.
Can we get vendor support?
Zabbix sells technical support subscriptions and works with a partner network. That contract is separate from deployment work and can sit alongside an internal or external operator.
Scope and handover
Effort depends on host and device count, new values per second, the number of sites and network zones, HA and database requirements, the existing monitoring tool and the amount of template tuning. Trigger tuning and notification routing usually take more time than installing Zabbix.
DeployOpen sizes and deploys the server cluster, database, frontend and proxies in your environment, configures SSO and encryption, rolls out agents through automation, migrates checks from the previous tool, sets up backups and a restore test, and documents the path to the next LTS. Handover includes the architecture diagram, template ownership map, notification routes, backup record and upgrade runbook.
