Zabbix: monitoring that calls you before your customer does

It is three in the morning. The store is not accepting orders because the disk has run out of space, and you will find out at nine, from an email from a customer who could not pay. Every company that maintains websites goes through this ritual exactly once. Then it sets up monitoring. In this article we introduce Zabbix, the tool we use ourselves to monitor our infrastructure and our clients’ websites: what it is for, how it works and how to set up your first instance before the next “three in the morning” happens.

Why monitoring at all?

Monitoring answers three questions that, without it, only an outage answers:

• Is everything working right now? The website responds, the certificate is valid, payments go through, the email queue is not growing,
• is something about to stop working? The disk will fill up in 4 days, the certificate expires in a week, the database has been bloating for a month,
• what was happening when things went wrong? Load graphs from the last 24 hours are half the diagnosis of any outage.

The business difference is simple: without monitoring, your customers tell you about problems; with monitoring, the system does, usually long before a customer notices anything.

What is Zabbix?

Zabbix is an open source monitoring platform that has been developed continuously for more than two decades. Unlike simple “pingers”, it can monitor practically everything: servers, containers, databases, network devices, applications and websites, and it is completely free, including for commercial use, with LTS versions supported for years. The price is not a licence but a bit of learning: Zabbix has its own concepts and logic, which are worth understanding from the start.

How it works: the architecture in a nutshell

A typical installation has four components:

• the Zabbix server: the heart of the system; it collects data, evaluates conditions and sends alerts,
• the database (MySQL/PostgreSQL): stores the configuration and the history of measurements,
• the web frontend: a panel with graphs, dashboards and configuration,
• agents: lightweight processes on the monitored machines that report system metrics.

The agent is not mandatory: Zabbix can also monitor without it, via ICMP (ping), HTTP, SNMP (network devices) or custom scripts. In larger networks there is also a proxy, which collects data locally and passes it to the central server; this is useful when monitoring client servers behind NAT.

The glossary you cannot do without

Four terms are enough to understand 90% of the configuration: a host is a monitored object (a server, a website), an item is a single measurement (disk usage, response time), a trigger is an alarm condition (“disk more than 90% full for 5 minutes”), and a template is a ready-made package of items and triggers that you attach to a host with one click. Zabbix has built-in templates for Linux, MySQL, nginx, PHP-FPM, Docker and hundreds of other things, so at the start you hardly need to write anything yourself.

Installation: the fastest way is Docker

For testing and smaller deployments, the official image is the most convenient: a complete environment takes a few commands:

docker network create zabbix-net

docker run -d --name zabbix-db --network zabbix-net   -e POSTGRES_USER=zabbix -e POSTGRES_PASSWORD=strongpassword   -v zabbix-db:/var/lib/postgresql/data postgres:16

docker run -d --name zabbix-server --network zabbix-net   -e DB_SERVER_HOST=zabbix-db -e POSTGRES_USER=zabbix   -e POSTGRES_PASSWORD=strongpassword -p 10051:10051   zabbix/zabbix-server-pgsql:7.0-alpine-latest

docker run -d --name zabbix-web --network zabbix-net   -e ZBX_SERVER_HOST=zabbix-server -e DB_SERVER_HOST=zabbix-db   -e POSTGRES_USER=zabbix -e POSTGRES_PASSWORD=strongpassword   -p 8080:8080 zabbix/zabbix-web-nginx-pgsql:7.0-alpine-latest

After a moment the panel is available on port 8080 (default login: Admin / zabbix; of course you change the password straight away). In production environments, installing from the official package repositories for Debian, Ubuntu or RHEL works just as well.

Connecting the first server

On the monitored machine, we install the agent and point it at the Zabbix server address:

apt install zabbix-agent2

# /etc/zabbix/zabbix_agent2.conf
Server=10.0.0.5          # Zabbix server address (passive polling)
ServerActive=10.0.0.5    # active mode: the agent sends data itself
Hostname=web-prod   # name matching the host in the panel

systemctl enable --now zabbix-agent2

In the panel, we add a host with the same name and attach the “Linux by Zabbix agent” template, and within a few minutes dozens of metrics start flowing in: CPU, RAM, disks, network, processes, along with ready-made triggers and graphs.

Monitoring websites and certificates

For an agency like ours, the most important module is web monitoring: Zabbix periodically visits the given URLs and checks the response code, the loading time and, very practically, whether a given text is present on the page. A trigger such as “the footer is missing on the home page” will catch a blank PHP page faster than any customer. A separate built-in template watches SSL certificates and raises the alarm well before they expire, a problem that can still destroy trust in an online store in a single evening.

Alerts: let Zabbix make the call

Data without notifications is just pretty graphs. Zabbix sends alerts via email, Slack, Telegram, SMS and dozens of other channels (media types), and it also supports escalations: first a Slack message to the team, after 15 minutes without a response an SMS to the administrator, after an hour a phone call to the boss. It is worth separating severity levels from the start: “the disk is running out” (tomorrow morning) is different from “the store is not responding” (immediately).

What to avoid

• alert fatigue: if 50 alerts arrive every day, after a week nobody reads any of them; alarms should be rare and important,
• monitoring everything “because you can”: start with website availability, disks, backups and certificates, and add the rest when you need it,
• no testing: once a quarter, deliberately trigger an alarm and check that notifications really arrive; monitoring that nobody trusts does not exist.

Or maybe something simpler?

To be fair: not everyone needs Zabbix. If all you want to know is “is the website alive”, UptimeRobot or Healthchecks.io is enough. Teams deeply rooted in Kubernetes will usually choose Prometheus with Grafana. Zabbix shines in the middle of that range: classic servers, dozens to hundreds of hosts, a variety of services and the need for one place where you can see everything, from ping to SQL queries.

Summary

Monitoring is the cheapest insurance policy in IT: setting up Zabbix takes an afternoon, and the first outage it catches pays that time back many times over. At Okinet, Zabbix watches over our clients’ websites and online stores as part of our ongoing technical support; thanks to it, we are the ones who know about problems, not their customers. Want your website to be looked after like this too? Write to us.