Zabbix server requirements, sized for a machine of its own

The official sizing table

The requirements page for Zabbix 7.4 gives four example configurations, assuming a Linux, BSD or Unix platform. The unit is the monitored metric, which the footnote defines loosely as one item plus one trigger plus one graph, and explicitly calls an estimation rule rather than a formula.

Every row lists the same supported databases: MySQL Server, Percona Server, MariaDB Server and PostgreSQL. Three qualifiers come with the table and belong next to any number you quote from it: the figures are examples to start with, each installation is different and should be benchmarked in staging before production, and the actual configuration depends heavily on the number of active items and their refresh rates. For large installations the page strongly recommends running the database on a separate server.

The server itself runs only on Unix-like systems; Windows is supported for agents, not for the server. Plan on a Linux install.

Disk: retention decides it

Configuration data is small and fixed, normally 10 MB or less. Growth comes from history, trends and events, and the documentation gives a formula for each. Its worked example: 3,000 items polled every 60 seconds is 50 new values per second; kept for 30 days that is about 130 million values, and at roughly 90 bytes per numeric value about 10.9 GB.

• History: days × (items ÷ refresh rate) × 86,400 × bytes per value. Numeric values are normally around 90 bytes; text and log values around 500.
• Trends: one min/max/avg/count row per item per hour. The docs put 3,000 items at about 2.2 GB a year, 11 GB for five years.
• Events: about 250 bytes each, plus 80 for its recovery record and about 100 per tag. The docs' worst case of one event per second kept for three years is roughly 30 GB before tags.

Those byte counts are based on MySQL and may differ on other engines. The database stops growing once the housekeeper starts deleting at the retention you set, so size for the steady state, not for day one. Random writes are the constant cost here, which is why the database belongs on NVMe dedicated servers rather than on spinning disks once you are past the small row.

Which machine for which row

Memory is the figure to fix first. Zabbix's requirements page notes that the more physical memory you have, the faster the database, and therefore Zabbix, works. Each Zabbix daemon process also holds several database connections, and what each costs depends on the database configuration. Matching the table to the lines on the dedicated server range:

These pairings are our reading of the table, not Zabbix's. The machine is whole: every core, all of the memory and the disks serve Zabbix and its database, with root and no other tenant. Racked machines are handed over in about 30 minutes once payment is approved, and built-to-order lines take 4 to 24 hours.

Installing Zabbix 7.4 on PostgreSQL

Use the Zabbix Official Repository, not the distribution's own Zabbix packages, which the docs say are unsupported and may be outdated. The commands below are the ones the Zabbix download page generates for Ubuntu 24.04 with PostgreSQL and Nginx, run as root. PostgreSQL 13 to 18 is supported; apt install postgresql gives you the version Ubuntu ships.

1. Install PostgreSQL and make sure it is running.
2. Add the Zabbix repository and install the server, frontend and agent packages (first block below).
3. Create the zabbix database role and database, then import the schema (second block). createuser prompts for the password you choose.
4. Put that password in DBPassword= in /etc/zabbix/zabbix_server.conf.
5. Set listen and server_name in /etc/zabbix/nginx.conf (third block), then systemctl restart zabbix-server zabbix-agent nginx php8.3-fpm and systemctl enable the same four services.

wget https://repo.zabbix.com/zabbix/7.4/release/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_7.4+ubuntu24.04_all.deb
dpkg -i zabbix-release_latest_7.4+ubuntu24.04_all.deb
apt update
apt install zabbix-server-pgsql zabbix-frontend-php php8.3-pgsql zabbix-nginx-conf zabbix-sql-scripts zabbix-agent

sudo -u postgres createuser --pwprompt zabbix
sudo -u postgres createdb -O zabbix zabbix
zcat /usr/share/zabbix/sql-scripts/postgresql/server.sql.gz | sudo -u zabbix psql zabbix

The download page also lists 7.0 LTS. If you want the long-term support branch, copy the 7.0 commands from that page rather than editing the ones above: the repository path differs as well as the version. The requirements page adds one PostgreSQL note: larger installations may need work_mem raised from its 4 MB default. Our PostgreSQL dedicated server page covers memory and WAL settings for the database side.

Before the web UI is public

Until its setup wizard has been completed, the frontend opens on that wizard, so we assume anyone who can reach the URL could run it. Once it finishes, the documented default login is Admin with the password zabbix, a superuser. Zabbix strongly recommends changing that password right after the first login. Do both from a private connection: bind Nginx to loopback, tunnel to it over SSH, complete the wizard, change the Admin password, and only then open it to the network behind HTTPS.

# /etc/zabbix/nginx.conf - loopback only until Admin's password is changed
listen 127.0.0.1:8080;
server_name zabbix.example.com;

# from your workstation, then browse http://localhost:8080
ssh -L 8080:127.0.0.1:8080 you@your-server   # your own SSH login

# our suggestion for the file holding DBPassword
chown root:zabbix /etc/zabbix/zabbix_server.conf
chmod 640 /etc/zabbix/zabbix_server.conf

With only listen 127.0.0.1:8080; nginx serves Zabbix on no IPv6 address. Do not add a listen [::]: line until Admin's password is changed.

• The database password is in zabbix_server.conf. Our suggestion, in the box above: owner root, group zabbix, mode 640. The server, running as zabbix, still reads the file; other users cannot. It does not keep out an agent that also runs as zabbix, which is why the next point matters.
• The agent shares the zabbix user by default. Zabbix's access-control guide says to run an agent on the server host under its own user so it cannot read the server's database credentials.
• Ports. The server's trapper listens on TCP 10051 for active agents, proxies, zabbix_sender and the frontend: allow it only from those hosts. Each monitored host's agent listens on TCP 10050 for passive checks: allow it only from the Zabbix server or proxy that polls it, and list that address in the agent's Server= parameter. Write every firewall rule for IPv6 as well as IPv4. Zabbix says not to expose these ports directly to the internet.
• Global scripts are off on a new 7.x install (EnableGlobalScripts=0 in zabbix_server.conf). Leave them off unless you need them.
• Clock. Zabbix calls precise system time very important on the server; keep NTP running on it and on every agent.

Keeping it running

• Back up the database and /etc/zabbix. On PostgreSQL that means pg_dump of the zabbix database on a schedule, copied off the machine.
• Watch the watcher. Zabbix cannot alert about its own outage. Put a small external check on the frontend URL from somewhere else, for instance an Uptime Kuma instance on a separate box.
• Place it apart from what it monitors. A Zabbix server in the same rack as its targets goes dark with them. Five cities are on the data center locations page, all on AS19624.
• Upgrades come through the same repository with apt; read the upgrade notes for the target version before you run it.

On a racked single-, dual- or quad-socket server the out-of-band console (HPE iLO, Dell iDRAC or a Supermicro BMC) still answers when a firewall rule locks SSH out, so a bad change to the box that does your alerting is recoverable without a ticket. Of the cartridges, only the m510 and m710x carry a console; the others have power control only.

When a dedicated server is the wrong call

Below the small row, a few dozen hosts with default templates, a whole machine is more than Zabbix needs, and a small virtual machine or one cartridge does the job. At the other end, a million-metric estate is two machines minimum, since Zabbix recommends a separate database server at large sizes, and usually proxies near the monitored sites as well. And if nobody on the team will patch PostgreSQL and read the Zabbix upgrade notes, the server will drift: root on a whole machine means the software is yours to keep current.