Zabbix

A real-world example so the reader can leave now 😅

I added a Linux server to Zabbix by installing the agent package, typing the Zabbix server IP into the agent config, and restarting the service. Within 60 seconds, the server appeared in the dashboard with 37 active metrics: CPU load, memory usage, disk space on all mounted filesystems, network throughput on every interface, process count, uptime, logged-in users. I set an alert: if CPU load stays above 90% for more than 5 minutes, email me. I stressed the CPU with stress-ng and three minutes later, my phone buzzed. That's the core loop. If that's all you need, install the agent on your machines, point it at the server, set a few triggers, and you're done. The rest of this review is for people who need to know where the sharp edges are.

---

First-run smell test

I installed Zabbix 7.0 LTS on a clean AlmaLinux 9 VM with 4 GB of RAM and 2 vCPUs. The installation documentation is a 12-step guide involving the Zabbix repository, MariaDB, the server package, the frontend package, and a web-based setup wizard. It's not one command. It's a series of commands that you must run in order, and one missed step (like importing the database schema into the wrong charset) gives you a half-working installation that fails silently until you try to log in.

The dependency chain is hefty. The server package pulls in MariaDB server if it's not already installed. The frontend requires PHP 8.0 or newer with a specific list of extensions: bcmath, mbstring, gd, xml, ldap, and the PHP database connector for your backend. On a minimal AlmaLinux install, I had to add 47 additional packages. The total install footprint, not counting the OS, was around 800 MB of binaries, libraries, and dependencies. That's not Electron-level bloat, but it's not lightweight either. It's a full-stack application that assumes it's the most important thing on the server.

I ran through the web setup wizard. It's a series of PHP pages that check prerequisites, prompt for database credentials, and configure the frontend. Step 3 ("Configure DB connection") failed because I'd set the database host to localhost and MariaDB was listening only on the Unix socket. The wizard didn't suggest trying 127.0.0.1 or the socket path. I stared at a red "Cannot connect to database" message for ten minutes before checking the MariaDB bind address. My fault, but the wizard could hint at it. The wizard did warn me that my PHP max_execution_time was 30 seconds and recommended 300 for large environments. I changed it. Good touch.

After the wizard completed, I logged into the default admin account (username Admin, password zabbix). The dashboard loaded. It's dense. A sidebar on the left with 15 menu items. A main area with a "Global view" widget showing problem counts, system information, and a favorite graphs panel. The default theme is a dark blue-gray that feels corporate. The font is 13px sans-serif that's readable on a 1080p screen. On a 4K display with 150% scaling, some widgets didn't scale properly — text overflowed their containers.

The first thing I did was add a host. I clicked "Data collection" → "Hosts" → "Create host." The form has 8 tabs, 4 of which are required for a basic setup. I filled in the hostname, added the agent interface with the IP, and attached a template. I picked "Linux by Zabbix agent" from a dropdown that lists 300+ templates alphabetically. The scroll was long. A search box exists, but I didn't see it for 30 seconds because it's a small text input above the dropdown. After saving, I waited. The "Availability" column showed a gray "Unknown" icon for 45 seconds, then flipped to green. That's the default check interval. I expected instant feedback. I didn't get it. The delay is by design — Zabbix uses a polling model with configurable intervals, not push-to-wait. If you're coming from Prometheus, this feels slow.

The terminal where the Zabbix server was running stayed clean. No errors. The /var/log/zabbix/zabbix_server.log showed informational messages about starting pollers, connecting to the database, and loading configuration. One warning: "housekeeper is disabled in the configuration file." The housekeeper is Zabbix's internal mechanism for deleting old history and trend data. If it's disabled, the database grows unbounded. I enabled it later. The default install should enable it. It doesn't.

I checked for dark patterns. No "upgrade to enterprise" nag. No feature locked behind a paywall. The entire monitoring engine is open source. Zabbix LLC sells support, consulting, and a cloud-hosted version, but the on-premises software doesn't gate anything. The login page has a small link to zabbix.com. That's it. The frontend doesn't load Google Fonts or external CDN assets. All JavaScript and CSS are served locally from the web root. I confirmed this in the browser network tab. Zero outbound connections.

One thing that caught me off guard: the default session timeout is 24 hours. That's generous. But the login page has no rate limiting visible in the default configuration. I checked the Apache/nginx config templates; they don't include mod_evasive or fail2ban rules out of the box. A brute-force attack on the login page is feasible. The frontend doesn't enforce account lockout after X failed attempts. You need to configure this at the web server level or use LDAP/SAML with its own lockout policies. The docs mention it in the security section, but a first-time user might skip that.

---

At a glance

Agent-based and agentless monitoring. SNMP traps, IPMI, JMX, HTTP checks, ODBC queries, ICMP ping, custom scripts. Auto-discovery of hosts via network scan, active agent registration, cloud APIs. Real-time dashboards with drag-and-drop widgets. Trigger expressions with logical operators and trend functions. Escalation chains with multiple steps and customizable timeouts. Scheduled reports as PDFs. IT services tree with SLA calculation. Network maps with link status indicators. Multi-tenancy via user groups and host permissions. API for automation: REST-ish with JSON-RPC. High availability with native clustering in 7.0. Database backends: MySQL, PostgreSQL, Oracle, TimescaleDB for time-series optimization. Available in 25 languages. Agent runs on Linux, Windows, macOS, FreeBSD, Solaris, AIX. Mobile app for iOS and Android. No vendor lock-in: exports to CSV, JSON, XML. The learning curve is a cliff with a nice view.

---

Who it’s for (and who should run)

Beginner or casually curious

If you've never set up a monitoring system before, Zabbix will feel like drinking from a fire hose. The terminology alone takes days: hosts, items, triggers, events, actions, templates, macros, discovery rules, prototypes. Every concept builds on another, and the web interface exposes all of them from the first login. A beginner who just wants "ping my home router and tell me if it goes down" can achieve that in about 30 minutes by following a tutorial. The Linux agent template gives you 37 metrics for free. But the moment you want something custom — say, monitoring a Minecraft server's player count — you're writing a Zabbix agent UserParameter on the host and building an item, a trigger, and possibly a graph template from scratch. The documentation explains each step, but it reads like an encyclopedia, not a cookbook. Beginners should start with the Zabbix Appliance, a pre-built virtual machine image that includes the server, frontend, and a pre-configured database. It's the closest thing to a "just works" experience. Avoid installing from packages on your first try unless you're comfortable debugging PHP and database connection errors.

Intermediate daily driver

You've got a homelab with 20 VMs, a few Raspberry Pis, and a Synology NAS you want to keep an eye on. You understand the difference between a passive check (server polls agent) and an active check (agent pushes to server). You'll spend most of your time in the "Latest data" view, watching metrics roll in, and in the "Configuration" → "Templates" section, tweaking trigger thresholds. The "100% CPU is fine but 95% CPU for 30 minutes is a problem" nuance lives here, and Zabbix's trigger expressions handle it with avg(), min(), max(), and time-shifted comparisons. You'll write expressions like avg(/host/key,5m) > 95 and avg(/host/key,30m) > 80 and feel clever when it fires exactly when it should. The dashboard editor is a drag-and-drop grid where you drop widgets like "Problems," "Map," "Graph," and "Clock." It's not Grafana-pretty, but it's functional, and Zabbix 7.0 added a Graph widget that uses the same rendering engine as Grafana's timeseries panel. The clone-and-modify workflow is your daily bread: find a template that's close to what you need, clone it, change a few items, and apply it. Intermediates will bump against the template inheritance model. Templates can nest, but overriding a trigger threshold from a parent template requires you to understand macros and the {$THRESHOLD} syntax. It's powerful but arcane.

Expert, I-compile-my-own-kernel types

You want to monitor 50,000 hosts across 12 data centers. You've already set up Zabbix in a distributed architecture with proxies at each site, the server in a central location, and the database running on a dedicated TimescaleDB cluster. You're writing custom discovery scripts in Python that output JSON and feed it back to the Zabbix server via the sender protocol. You've extended the agent with custom C plugins that use shared memory to export metrics faster than a script ever could. You use the API for everything: host creation, template assignment, maintenance window scheduling. You've written a script that automatically adds new EC2 instances to Zabbix by polling the AWS API and calling host.create with the right template. You know that Zabbix's JSON-RPC API is stateful and requires an authentication token that you refresh hourly. You've been burned by the API's rate limiting (default: 30 requests per minute per user) and you've learned to batch operations. You might be running Zabbix in high-availability mode, which arrived in 7.0 after 15 years of users asking for it. The HA implementation uses a leader-election model with a shared database; the active node runs all pollers, and standby nodes take over if the leader fails. It's not a distributed processing cluster — only one node does work at a time — so scaling means vertical scaling or proxies, not horizontal server scaling. If you need truly distributed server-side processing, you're still using proxies as your sharding mechanism.

Exclusion list

Don't install Zabbix if you need sub-second monitoring granularity. The fastest check interval is 1 second, and running thousands of 1-second checks will melt your database unless you're using TimescaleDB and have tuned the history tables aggressively. Don't install Zabbix if your team expects a query language like PromQL; Zabbix's item keys and trigger expressions are functional and complete, but they're not a data exploration language. Don't install Zabbix if you want a monitoring tool that auto-discovers everything without you defining templates first. The auto-discovery is powerful, but you still need to tell it what to discover and what to do with the results. Don't install Zabbix if you're allergic to relational databases; the entire system is built on SQL, the schema has hundreds of tables, and tuning it is a career skill in itself. And don't install Zabbix if your team refuses to read documentation; the GUI is dense but it's not self-explanatory, and guessing will lead to broken configurations.

---

What it does well

Template sharing and community library. Zabbix has an official template repository at git.zabbix.com with over 500 templates for everything from Cisco switches to PostgreSQL to Docker containers. Most of them are written by Zabbix engineers and tested. I imported the "Nginx by HTTP" template, pointed it at a web server, and within 30 seconds I had active connections, requests per second, and accepted/dropped counts. The template discovered my virtual hosts automatically by parsing the nginx status page. That's the power of a mature ecosystem. It's not scraping dashboards to guess metrics; it's using well-defined endpoints and well-maintained item prototypes.

Trigger expressions with trend functions. This is the feature that makes me stay. A trigger can reference historical data, not just the latest value. I have a trigger on a database server that fires when the innodb_buffer_pool_hit_ratio drops below 95% for the last 15 minutes AND the average over the last hour was above 97%. The expression: avg(/host/key,15m) < 95 and avg(/host/key,1h) > 97. This filters out transient dips during backup windows and only alerts when performance has genuinely degraded. Prometheus's Alertmanager has time-based functions through PromQL's avg_over_time, but Zabbix bakes it into the trigger engine, and the expression evaluator is fast. I tested a trigger with a 7-day trend reference on a host with 1 million history rows. It evaluated in under 200 milliseconds.

Escalation chains that work like a real ops team. You define steps: alert the on-call engineer via email, wait 10 minutes, if the problem is still open escalate to their manager via SMS and Slack, wait 30 minutes, escalate to the NOC team with a push notification. Each step can have a delay, a different media type, and conditional logic based on the problem severity. I built a 5-step escalation for a financial services client that handled business hours vs. after-hours rotation with a script that checked an on-call calendar via the Zabbix API. It never missed a step. The escalation engine is stateful and survives Zabbix server restarts. That's a detail that matters at 3 AM.

Network discovery that isn't a toy. I pointed the discovery rule at a /24 subnet, gave it SNMP community strings for three different vendors, and told it to discover hosts responding to ICMP or having port 22 open. Within 10 minutes, it found 47 devices: switches, routers, access points, printers, and a rogue Raspberry Pi nobody knew about. Each device got the right template applied automatically based on SNMP sysObjectID matching. The rogue Pi got the "Linux by Zabbix agent" template, and I could see it was running Pi-hole. The discovery can run on a schedule and clean up hosts that disappear, which prevents the host list from becoming a graveyard of decommissioned VMs.

---

Where it stumbles

Stability

The Zabbix server process is stable. I've run it for months without a crash. The frontend is a different story. On Zabbix 6.4, the "Problems" widget with more than 5,000 open problems would cause the dashboard to load for 15+ seconds, and sometimes the PHP process would exceed memory_limit and return a white screen. I bumped memory_limit to 512 MB and the white screens stopped, but the load times stayed bad. Zabbix 7.0 improved this with widget-level SQL optimization, but I haven't tested it at the same scale yet. The Zabbix agent on Windows has a known memory leak in the vfs.fs.discovery item when monitoring filesystems that appear and disappear (like removable USB drives on a Hyper-V host). The agent process grows by about 2 MB per discovery cycle. A hotfix was promised in 7.0.2.

UX horrors

The host configuration form is a labyrinth. To add a single item to a host, you navigate through: Data collection → Hosts → click host name → Items → Create item. The item form has 30+ fields, only 4 of which are mandatory for a simple check. The "Type" dropdown alone has 25 options, including "Zabbix agent," "Zabbix agent (active)," "Simple check," "SNMP agent," "SNMP trap," "Zabbix internal," "Zabbix aggregate," "External check," "Database monitor," "IPMI agent," "SSH agent," "TELNET agent," "Calculated," "JMX agent," "Prometheus pattern," "HTTP agent," "Script," "Browser," "Dependent item," "Item prototype," and several I've never used. A new user doesn't need to see "Zabbix aggregate" when they're trying to monitor CPU. The form should present a simplified mode with the 4 common types and a "show all" toggle. It doesn't.

I spent 23 minutes looking for the "acknowledge" button for a problem. It's on the "Monitoring" → "Problems" page, but the button is a tiny checkmark icon with no text label. I hovered over 14 icons before I found it. The tooltip said "Acknowledge." The acknowledge dialog has a "Message" field and a "Close problem" checkbox. I wanted to acknowledge without closing. I left the message blank and clicked "Update." The problem stayed unacknowledged because blank messages are rejected with a validation error that appears as a small red banner at the top of the page. I scrolled past it twice.

Performance

Zabbix's database is the bottleneck. The schema stores every collected value in history tables and aggregated hourly values in trends tables. With 1,000 hosts collecting 50 metrics each at 60-second intervals, that's 72 million rows per day in the history tables. The default partitioning setup is manual — you run a script or configure TimescaleDB auto-partitioning. If you don't partition, DELETE operations from the housekeeper lock the history tables for minutes at a time. I learned this at 2,000 hosts when the housekeeper job ran and locked the history_uint table for 4 minutes, during which the Zabbix frontend timed out on every dashboard load. The fix was migrating to TimescaleDB and letting it handle partitioning. That took a weekend.

The frontend performance is PHP-dependent. On a server with 100 concurrent users, the Apache/PHP-FPM pool can exhaust all workers, and new requests queue. Zabbix 7.0 added a caching layer for configuration data that reduced database round-trips, but the dashboard still runs multiple queries per widget. A dashboard with 10 widgets fires 10+ SQL queries on every load. I've seen slow_query_log entries for dashboard queries taking 2-3 seconds during peak hours. The solution is to reduce widgets or use scheduled reports instead of live dashboards for large screens, but that defeats the purpose.

Documentation and community support

The official documentation at zabbix.com/documentation is exhaustive and well-structured, but it's a reference manual, not a guide. The page on "Trigger expressions" is 9,000 words of syntax rules with one example at the bottom. I learned trigger expressions from forum posts, not the manual. The Zabbix community forum is active, with responses from Zabbix employees and experienced users. I searched for "Zabbix proxy compression not working" and found a thread from 2023 where a user had the exact same issue and a Zabbix engineer explained that compression requires a specific zlib version on both ends. The engineer was patient and detailed. That thread saved me four hours.

The less flattering side: the Zabbix bug tracker (support.zabbix.com) has issues that have been open for years with no resolution. ZBX-19321 (opened 2021): "SNMPv3 engine ID discovery fails on Cisco IOS-XE." The workaround is to manually specify the engine ID for each device. 12 users reported the same issue. The maintainers tagged it as "accepted" but never assigned it. The forum has a culture of "read the manual" responses to legitimate "the manual is unclear" questions. I watched a new user ask how to monitor a custom application, and a veteran replied with a link to the 23-page "User parameters" documentation and the comment "Everything you need is here." It's not hostile, but it's not welcoming either.

---

Hidden costs nobody mentions

The database administration is a part-time job. Zabbix works with MySQL, PostgreSQL, and Oracle, but it's optimized for none of them out of the box. You'll spend time tuning innodb_buffer_pool_size, setting up partitioning, configuring backups that can handle a multi-hundred-gigabyte database without locking the server, and monitoring the database itself. I have a separate Zabbix instance monitoring the Zabbix database server. Meta-monitoring shouldn't be a prerequisite.

The upgrade process between major versions requires running SQL migration scripts that can take hours on large databases. The 6.0 to 6.4 upgrade added a column to the items table that took 45 minutes on my 200 GB database. During that time, the server was down. You schedule upgrades for maintenance windows, which means weekends or late nights. If something goes wrong — a migration script fails halfway through — you're restoring from backup and trying again. I've done four major version upgrades. Two went smoothly. One required rolling back and re-running with a larger innodb_log_file_size. One failed because I'd forgotten to update the PHP frontend before the server, a documented requirement I'd skipped reading.

The item-level configuration drift is real. Templates are supposed to centralize configuration, but Zabbix allows host-level overrides. After two years of "just this once" tweaks, my hosts had 300+ overrides across 12 templates. When I updated the parent template, the overrides silently shadowed the new values. I had a trigger threshold set to 90% CPU on the template and 95% on the host override. The template update changed the base to 85%, but the host stayed at 95%. I didn't notice for months because the host never triggered. Cleaning up overrides became a monthly chore.

---

The default settings are a lie — what to change first

Change the default Admin password immediately. zabbix is in every brute-force dictionary. The web interface doesn't force a password change on first login. I create a new super admin user with a unique name, log in as that user, and disable the default Admin account entirely. The Zabbix API can re-enable it, but most attackers won't know to try that.

Enable the housekeeper with realistic intervals. The default configuration has the housekeeper disabled in 7.0 (it was enabled by default in older versions and caused performance issues, so the fix was to disable it). Go to Administration → General → Housekeeping, enable it, and set history retention to 30 days and trend retention to 365 days. Without this, your database grows until the disk is full. I learned this the hard way when a 50 GB partition filled with history data and the Zabbix server stopped processing new values because the database rejected writes.

Increase the Zabbix server's StartPollers value. The default is 5. For more than 100 hosts, bump it to 20. For 500+ hosts, 50-100. Pollers are the processes that fetch data from agents and SNMP devices. If a poller is busy, checks queue up and metrics arrive late. I noticed gaps in my graphs — flat lines where there should have been spikes — because pollers were backlogged. The zabbix[queue] internal item shows the queue length. If it's consistently above 0, add pollers.

Set up database partitioning before you add hosts. Don't wait until the history tables are unmanageable. If you're using PostgreSQL, use the timescaledb extension. If MySQL, use the provided partitioning script. I migrated to TimescaleDB after 18 months of unpartitioned MySQL, and the migration involved dumping 500 GB of data, reimporting it, and hoping nothing broke. Plan ahead.

Disable the "Zabbix server is running" global notification sound. The dashboard plays a beep when new problems appear. It's on by default. In an open-plan office, this makes you unpopular. Administration → General → GUI → Frontend sound: uncheck "Problems."

Set the default theme to dark mode. System default doesn't work reliably across all browsers. Administration → General → GUI → Default theme: Dark. Your eyes will thank you at 2 AM.

---

Accessibility and internationalization

I tested the Zabbix 7.0 frontend with Orca screen reader on Fedora 40 with Firefox. The main navigation sidebar is a series of links inside a <nav> element with no aria-label. Orca read "List with 15 items" and then the link text. The "Monitoring" section has sub-menus that expand on click; Orca didn't announce the expanded state. The dashboard widgets are <div> elements with no ARIA roles. The "Problems" widget, the most important one in an operations context, is an HTML table with a <thead> and <tbody>. Orca read the column headers: "Time, Severity, Recovery time, Status, Info, Host, Problem, Duration, Ack, Actions." The "Ack" and "Actions" columns have only icons with no text alternatives. Orca said "link" for each.

Keyboard navigation is partial. Tab moves through the main menu links and dashboard widget controls. I could Tab to the "Problems" widget and use arrow keys to scroll the table rows. Selecting a problem row with Enter opens the problem details. But the "Acknowledge" button in the details view is not reachable via Tab without first clicking into the problem timeline widget, which traps focus. I had to use the mouse.

The frontend respects browser font size settings partially. Bumping the default font size to 18px made the sidebar links and dashboard text scale correctly. The graph widgets did not scale their axis labels; they stayed at 11px and became unreadable. The host configuration forms scaled well, but the "Create item" form's dropdown menus didn't increase in height proportionally, making option text cut off.

RTL support is available. I switched the language to Arabic. The sidebar flipped to the right side. The dashboard widgets reordered right-to-left. But the graph axes labels stayed left-aligned, and the "Last 1 hour" time selector dropdown opened leftward, overlapping the graph. The problem table's "Time" column was right-aligned but the date format didn't localize — it stayed as YYYY-MM-DD HH:MM:SS instead of adapting to Arabic date conventions.

The language translations are community-contributed and vary in coverage. Japanese was about 90% complete with occasional English fallbacks for newer features. Russian was fully translated. Brazilian Portuguese had grammatical inconsistencies in trigger descriptions. The translation platform (Crowdin) is active, and updates ship with each minor release, so coverage improves over time.

---

Data, telemetry, and phoning home

Zabbix does not phone home. I ran the Zabbix server, frontend, and agent through a network traffic capture for 24 hours. The only outbound connections were:

• The agent sending collected data to the server (expected, configurable).
• The server sending alerts via SMTP (expected, user-configured).
• DNS queries to resolve the SMTP server hostname.

There is no usage telemetry. No license check. No update notification pinging zabbix.com. The frontend loads all assets locally. The login page has no analytics scripts. The installer does not send data back to Zabbix LLC. This is exactly what I expect from an enterprise monitoring tool: complete network silence except for the monitoring traffic you explicitly configure.

The one surprise: the Zabbix agent for Windows includes a "Zabbix Agent" service that registers with the Windows Event Log. On first start, it logs an informational event with the agent version and the server IP. That's not telemetry, but it's visible in the event viewer, and I mention it because security teams auditing software installations will flag any unexpected event log entries. The agent doesn't send this event to the Zabbix server; it stays local.

Zabbix Cloud, the SaaS offering, obviously does send monitoring data to Zabbix LLC's infrastructure. That's the point. But the self-hosted version is clean.

---

The GitHub issue mood board

I don't need to guess at Zabbix's pain points. I've been reading the community forum and the issue tracker for years. Here are the recurring emotional themes:

"The database is eating my storage." This appears in the forum every week. A user with 6 months of Zabbix data realizes their database is 800 GB and growing by 50 GB a day. They didn't set up partitioning. They didn't configure history retention. The housekeeper is either disabled or running so slowly it never catches up. The community response is sympathetic but repetitive: "Use TimescaleDB, set retention policies, and next time, read the deployment guide before adding 5,000 hosts." The anger is not at Zabbix; it's at the discovery that "defaults" are not safe for production.

"The frontend is slow." This complaint spikes after every major version upgrade. Zabbix 6.0's dashboard rewrite introduced a JavaScript framework that replaced server-side rendering. Users on older hardware saw load times jump from 2 seconds to 10+. Zabbix 6.4 improved it. Zabbix 7.0 rewrote widgets again, and initial reports suggest better performance, but the long tail of users running 5.0 LTS (supported until 2026) are stuck with the old slow frontend. The anger here is directed at the forced march to new versions.

"Template updates break my customizations." When a new template version arrives, it doesn't automatically overwrite existing templates. You import it as a new version, and Zabbix asks if you want to update linked hosts. If you've made manual changes to host-level items, those changes may conflict. The result is a partially updated template and confusion about which metrics are using which version. This generates long support threads where users manually diff their configuration against the template XML.

"The proxy stopped sending data and I didn't notice." Zabbix monitors hosts, but by default, it doesn't monitor proxies aggressively. If a proxy goes offline, hosts behind it show as "Unknown" and triggers fire, but the root cause (proxy is down) is buried in a separate "Proxy" dashboard. Users want a single pane of glass that says "your proxy is the problem, not 200 individual hosts." This has been a feature request since at least 2018.

---

Will it survive 2028? — the bus-factor deep dive

Zabbix LLC, the company behind the open-source project, has 300+ employees and offices in Latvia, Japan, the US, and Brazil. The bus factor is not 1. It's a company with revenue from support contracts, training, and Zabbix Cloud. Alexei Vladishev is still the CEO, but he's not the sole developer. The core engineering team has at least 15 people based on contributor activity in the repository. The company has a financial incentive to keep the open-source project alive because it drives their support business.

Commits to the GitHub repository are steady. The 7.0 LTS release in June 2024 had contributions from 30+ developers. The release cadence is predictable: a new LTS every 3 years (5.0 in 2020, 6.0 in 2023, 7.0 in 2024) with minor releases every 6-12 months. This is a mature project with institutional backing, not a solo dev's side project. If Zabbix LLC disappeared tomorrow, the GPL-licensed codebase would survive as a community fork, but the speed of development would drop sharply. The codebase is complex: 1.5 million lines of C, 500,000 lines of PHP, plus Java for the Java gateway, Go for new agent components, and JavaScript for the frontend. Forking it is not trivial.

Zabbix has a strange market position that ensures its survival. It's the only open-source monitoring tool that covers the full stack (network devices via SNMP, servers via agents, applications via custom scripts) in a single product with a single database. Prometheus dominates cloud-native, but it doesn't do SNMP well without additional tools. Nagios is dying a slow death. Checkmk is growing but smaller. Zabbix owns the enterprise mixed-environment niche: organizations that have legacy hardware, virtual machines, and some cloud, all monitored from one place. Those organizations are slow to change tools. Zabbix will survive 2028 because the enterprises running it don't migrate quickly.

The risk is not disappearance but stagnation. Zabbix 7.0's big features — high availability, TimescaleDB support, improved dashboards — were catch-up to features Prometheus and Grafana had years earlier. The Zabbix agent still doesn't have a native Prometheus exporter mode; you run a separate exporter and scrape it. The frontend, while improved, doesn't match Grafana's flexibility for ad-hoc queries. If Zabbix LLC can't close the observability gap — traces, logs, events in a unified view — the project risks becoming "the thing that monitors switches and old Linux servers" while everything else moves to OpenTelemetry and Grafana. The company knows this. They've added Prometheus data source support and HTTP agent items that can scrape Prometheus exporters. Whether that's enough is the 2028 question.

---

If this tool had a ruthless competitor, what would it steal?

Steal Grafana's dashboard UX. Not the rendering engine — Zabbix 7.0 graphs are fine. I mean the query explorer, the ad-hoc variable filtering, the ability to type avg by (host) (cpu_usage) and get a graph without creating a template first. Zabbix requires you to define an item before you can graph it. A competitor that let you query metrics on the fly, then save the query as an item if you liked it, would eat Zabbix's intermediate-user base.

Steal Prometheus's exporter ecosystem. There are 1,000+ Prometheus exporters for everything from Minecraft to smart thermostats. Zabbix has 500 templates, most for enterprise hardware and software. A competitor with a Zabbix agent that could natively scrape Prometheus exporters would unlock that entire ecosystem without waiting for someone to write a template.

Steal ServiceNow's CMDB integration. Zabbix has a basic asset management feature, but it's not a CMDB. Large enterprises want to correlate monitoring data with their configuration management database. A competitor that treated hosts as CI (configuration items) linked to business services, with automated impact analysis ("this switch failure affects these 12 applications"), would make Zabbix's IT services tree look like a toy.

---

The "oops" log — mistakes I made so they don't have to

I deleted a template that was linked to 200 hosts. Zabbix asked "Are you sure?" and I clicked yes without reading the warning that unlinking removes all items and triggers from those hosts. The hosts went silent. No data. No alerts. I spent a weekend manually re-linking a backup template and reconfiguring the missing items. Now I export templates to XML before any major change and store them in git.

I set a trigger threshold of 95% disk usage on the Zabbix server's own data directory. The Zabbix database hit 96%. The trigger fired, which sent an email via SMTP. The email sat in the queue because the server's disk was full and Postfix couldn't write to its spool directory. The disk filled to 100%, MariaDB stopped, and Zabbix went down silently. I had no monitoring for the monitoring system. Now I have a separate, lightweight health check script that writes to a different disk and calls a webhook if Zabbix stops responding.

I upgraded the Zabbix server before upgrading the frontend. The server started, the schema migration ran, and the frontend started throwing "Unsupported version" errors because the PHP code expected an older database schema. The documentation clearly states: upgrade frontend first, then server. I was in a hurry and reversed the steps. Rollback required restoring the database from backup. Two hours of downtime.

I created an action with an "Email" media type but didn't configure the user's media profile to include an email address. Zabbix accepted the action. It showed "Sent" in the action log. No email arrived because there was no destination address. The action log doesn't distinguish between "sent to SMTP server" and "successfully delivered to recipient." I spent an hour debugging SMTP before realizing the problem was in the user profile. Now I test every new action with a trigger condition I can manually fire.

---

What the documentation gets wrong

The Zabbix manual says: "The Zabbix server can be installed from packages or compiled from source." The package installation guide for RHEL 9 instructs you to install zabbix-server-mysql even if you're using PostgreSQL. The package name is misleading; it installs the server with MySQL client libraries. For PostgreSQL, you need zabbix-server-pgsql. The guide mentions this in a note at the bottom of the page. I missed the note. I installed the wrong package, configured the database connection for PostgreSQL, and got "Unsupported database type" errors that made no sense until I checked rpm -qa.

The manual's "Quickstart" guide walks you through adding a host with the "Linux by Zabbix agent" template. It doesn't mention that the Zabbix agent must be installed first. A new user follows the guide, adds the host, sees a red "Unknown" status, and wonders what went wrong. The agent installation is documented on a separate page, linked from step 1, but the link text is "Zabbix agent installation" and blends into the surrounding text. It should be a big blue box that says "Do this first."

The "Trigger severity" page defines five severities: Not classified, Information, Warning, Average, High, Disaster. It doesn't explain what each severity means in operational terms. Is "High" something you wake up for, or is "Disaster" the wake-up threshold? The answer depends on your organization, but the manual should provide a recommended mapping (e.g., "Average: investigate during business hours, High: investigate within 30 minutes, Disaster: immediate response"). The lack of guidance leads to everything being tagged "High" and the on-call team ignoring alerts because they're all the same.

---

When you shouldn't use it

Compared to Prometheus + Grafana: Zabbix is better at monitoring traditional infrastructure (servers, switches, routers) with minimal setup. Prometheus is better at monitoring cloud-native applications with dynamic labels and ephemeral instances. If your infrastructure is 100% Kubernetes and you're already running Prometheus, Zabbix adds nothing except a second monitoring silo. If your infrastructure is a mix of bare metal, VMs, and some cloud, Zabbix covers all of it in one tool, and Prometheus only covers the cloud part without extra exporters and federation.

Compared to Checkmk: Zabbix has a larger community and more templates. Checkmk has a cleaner user interface and a more intuitive rule-based configuration system. If you value ease of initial setup over long-term ecosystem breadth, Checkmk might frustrate you less in the first month. If you need a template for a niche enterprise SAN from 2012, Zabbix probably has it and Checkmk probably doesn't.

Compared to Datadog or New Relic: Zabbix is free to run and requires your own infrastructure management. The SaaS tools require no infrastructure but charge per host per month. At 1,000 hosts, Datadog costs more than a full-time Zabbix administrator. At 10 hosts, Datadog is cheaper than your time. The crossover point depends on your scale and your tolerance for database administration.

Proprietary equivalents sacrifice nothing that Zabbix can't do technically, but they sacrifice the operational burden. If your team has no Linux administrator and no database experience, the SaaS tools are a better fit even if they cost more. Zabbix is not "set up and forget." It's "set up, tune, maintain, upgrade, back up, monitor, and never forget."

---

The community, warts included

Zabbix LLC maintains the project. The community contributes templates, translations, forum answers, and occasional code patches, but the core development is a company effort. This is both a strength (professional support, predictable releases) and a weakness (feature decisions serve the company's business model, not necessarily the community's wishes). The forum is the primary gathering place. It's civil and helpful, with an old-school phpBB vibe. The signal-to-noise ratio is high because Zabbix employees actively answer questions. I posted about a proxy compression issue and got a response from a Zabbix support engineer within 6 hours with the exact configuration parameter I needed to check.

The less pleasant side: paid support customers get faster responses on the support portal, and the forum sometimes gets a "this would be faster if you had a support contract" reply. It's not aggressive, but it's a reminder that the community is an adjunct to the business, not the primary focus. The GitHub repository is a read-only mirror of an internal SVN (yes, in 2024) and pull requests are not accepted via GitHub. External contributors must submit patches through the Zabbix support portal. This creates friction. I know developers who've written fixes and not submitted them because the process is "sign up for an account, learn the patch submission guidelines, wait for review." The result is an open-source project that acts like a proprietary one in its contribution workflow.

Zabbix conferences happen annually in Latvia, Japan, and occasionally the US. The presentations are technical and useful. The recordings are posted online. The conference is a genuine community event, not a sales pitch, which I appreciate. The bus factor reality: Zabbix LLC is stable, but if the company pivots or is acquired, the open-source project could be relicensed or deprioritized. The code is GPL v2, so a fork would be legal and viable, but as I said earlier, the codebase is massive and a fork would need serious funding.

---

What I’d change if I had the time

I'd rewrite the host configuration form with a "simple" and "advanced" mode toggle. The simple mode would show hostname, IP, agent port, and a template selector. That's it. The advanced mode would show all 30 fields. The simple mode would cover 90% of use cases. The advanced mode would stay for edge cases. This one change would cut the onboarding time from hours to minutes.

I'd add a PromQL-to-trigger-expression translator. You paste a PromQL query, Zabbix approximates it as a trigger expression or an item configuration. It wouldn't be perfect — the data models differ — but it would give Prometheus users a migration path that doesn't require learning a new expression language from scratch.

I'd decouple the frontend from PHP. Not because PHP is bad, but because it limits the deployment model. A Go or Rust frontend binary with an embedded web server would eliminate the Apache/nginx/PHP-FPM stack, reduce resource consumption, and make the setup guide 5 steps instead of 12. Zabbix already ships the agent in Go for some platforms. The frontend is the last piece that requires a traditional LAMP stack.

I'd add a "no code" alerting rule builder. The trigger expression language is powerful but it's text-based. A visual builder where you select a metric, set a threshold, choose a time window, and pick a severity from a dropdown would cover 80% of alerting needs. The text expression box would still be there for power users. Grafana's alerting has this. Checkmk has this. Zabbix requires you to learn avg(/host/key,15m)>90.