Skip to content

Monitoring

Zabbix — Server, Agents & SNMP

Zabbix is a full-featured, open-source monitoring platform: one server collects metrics from thousands of hosts, evaluates trigger expressions against them, and alerts you when something crosses a line. This guide explains the moving parts, then walks through the three ways you'll add monitoring in practice — the agent, SNMP, and the other item types.

Applies to

Zabbix 7.0 LTS (recommended in production; full support runs to mid-2027, limited support to 2029). Zabbix 7.4 is the latest standard release, and 8.0 LTS is expected in Q3 2026. Commands target AlmaLinux 9 / RHEL 9 and work the same on Rocky Linux. Re-check zabbix.com/life_cycle_and_release_policy before a new deployment — LTS releases arrive roughly every 1.5 years.

What is the Zabbix server?

The Zabbix server is the central daemon (zabbix_server) that does the real work: it polls hosts, receives pushed data, stores history, evaluates triggers (alert conditions), and fires actions (email, Slack, scripts, auto-remediation). Around it sit a few cooperating components:

Component Role
Zabbix server Collects data, evaluates triggers, sends alerts — the brain
Database PostgreSQL or MySQL/MariaDB; stores configuration and metric history
Web frontend PHP application (nginx/Apache) — dashboards, host config, graphs
Zabbix agent / Agent 2 Small daemon on each monitored host, serves OS-level metrics
Zabbix proxy Optional collector for remote sites/DMZs; gathers locally, forwards in bulk 
 monitored hosts                          your laptop
 ┌────────────┐  10050 (passive)            │
 │  agent2    │◄────────────┐               ▼
 └────────────┘             │          ┌──────────┐
 ┌────────────┐  10051   ┌──┴───────┐  │ frontend │
 │  agent2    │─────────►│  server  │◄─┤  (PHP)   │
 └────────────┘ (active) └──┬───────┘  └──────────┘
 ┌────────────┐   161/udp   │
 │ SNMP device│◄────────────┘     ┌──────────┐
 └────────────┘                   │ database │
                                  └──────────┘

Key vocabulary you'll meet in the frontend:

  • Host — anything monitored (server, switch, VM, website).
  • Item — one metric collected from a host (system.cpu.load[all,avg1]).
  • Trigger — an expression over item values that defines a problem state.
  • Template — a reusable bundle of items, triggers, graphs, and discovery rules. You almost never create items by hand — you link a template.

Agent vs Agent 2 — which to install?

Use Zabbix Agent 2 for new deployments. It's the modern Go-based agent: a single binary with a plugin system, built-in monitoring for Docker, PostgreSQL, MySQL, Redis and more, support for concurrent checks, and it speaks the same protocol on the same port (10050) as the classic C agent. The classic zabbix-agent still works and is fine where you find it already deployed.

Add a Linux host with Agent 2

1. Install the agent on the host

# add the official Zabbix 7.0 repo (AlmaLinux/RHEL/Rocky 9)
sudo rpm -Uvh https://repo.zabbix.com/zabbix/7.0/alma/9/x86_64/zabbix-release-latest-7.0.el9.noarch.rpm
sudo dnf clean all

# install agent 2 (plus optional loadable plugins)
sudo dnf install -y zabbix-agent2

2. Point it at your server

Edit /etc/zabbix/zabbix_agent2.conf — three parameters matter:

# who may poll this agent (passive checks) — the Zabbix server's IP
Server=192.0.2.10

# where to push active-check data — server IP (and port if not 10051)
ServerActive=192.0.2.10

# must match the host name you create in the frontend
Hostname=web01.example.com

3. Start it and open the firewall

sudo systemctl enable --now zabbix-agent2
sudo firewall-cmd --permanent --add-port=10050/tcp && sudo firewall-cmd --reload

# verify it's listening
ss -tlnp | grep 10050

4. Create the host in the frontend

In the web UI: Data collection → Hosts → Create host:

  1. Host name: web01.example.com — must equal Hostname= in the agent config.
  2. Host groups: e.g. Linux servers.
  3. Interfaces: add an Agent interface with the host's IP, port 10050.
  4. Templates: link Linux by Zabbix agent (or Linux by Zabbix agent active if the agent must dial out — see below).

Within a couple of minutes the host's ZBX availability icon turns green and Monitoring → Latest data starts filling.

Test from the server before blaming the frontend

zabbix_get -s 192.0.2.20 -k system.uptime from the Zabbix server tests a passive item without any frontend involvement. If that hangs, it's network or firewall, not Zabbix.

Passive vs active checks

Passive Active
Who connects Server → agent, port 10050 Agent → server, port 10051
Config that matters Server= ServerActive= + Hostname=
Firewall direction Inbound to agent Outbound from agent
Best for Simple LANs NAT'd hosts, DMZs, large fleets (scales better)

Behind NAT? Go active

If the server can't reach the host (cloud VM behind NAT, customer site), active checks solve it: the agent initiates everything outbound to 10051.

Monitor a device over SNMP

Switches, routers, PDUs, printers, and appliances rarely run an agent — they speak SNMP. Zabbix polls them directly over UDP 161.

1. Enable SNMP on the device

On network gear that's a couple of config lines (define a community string for v2c, or a user for v3). On a Linux box you'd install net-snmp:

sudo dnf install -y net-snmp net-snmp-utils
echo 'rocommunity MySecureString 192.0.2.10' | sudo tee -a /etc/snmp/snmpd.conf
sudo systemctl enable --now snmpd
sudo firewall-cmd --permanent --add-port=161/udp && sudo firewall-cmd --reload

2. Verify with snmpwalk before touching Zabbix

snmpwalk -v2c -c MySecureString 192.0.2.50 system

If snmpwalk returns nothing, Zabbix won't do better — fix community/ACL/firewall first.

3. Create the host with an SNMP interface

Data collection → Hosts → Create host, but this time:

  1. Interfaces: add an SNMP interface (IP, port 161) and pick the version:
  2. SNMPv2c — set the community, conventionally via the {$SNMP_COMMUNITY} macro.
  3. SNMPv3 — username, auth protocol (SHA), privacy protocol (AES) — use this where the device supports it; v2c communities travel in clear text.
  4. Templates: link a matching template — Network Generic Device by SNMP is the safe starting point; vendor templates (Cisco, MikroTik, HPE, APC…) ship with Zabbix.
  5. Macros tab: set {$SNMP_COMMUNITY} to your community string.

The SNMP availability icon turns green once the first poll succeeds. The templates use low-level discovery to find interfaces/disks automatically and create items for each — that's why one template can fit a 4-port and a 48-port switch.

Every other item type, in one table

Agent and SNMP cover most fleets, but Zabbix has a collector for nearly everything. When you create an item, the Type field offers:

Item type What it does Typical use
Zabbix agent / agent (active) OS metrics via agent, passive or active Linux/Windows servers
SNMP agent Polls OIDs over UDP 161 Network gear, appliances
SNMP trap Receives traps the device pushes Link-down alerts from switches
IPMI agent Talks to BMCs (iLO, iDRAC) Hardware health, sensors, power
JMX agent Via the Zabbix Java gateway Tomcat/Kafka/JVM metrics
HTTP agent Server makes HTTP(S) requests itself REST APIs, health endpoints — agentless
Simple check Server-side ping/TCP probes (icmpping, net.tcp.service) "Is it up at all?" — agentless
Zabbix trapper Waits for data pushed by zabbix_sender Cron jobs, backup scripts reporting results
External check Server runs a custom script Anything you can script
Database monitor Direct SQL queries via ODBC DB health without an agent
Calculated / Dependent Derived from other items (no new polling) Ratios, totals, parsing one JSON into many items
Script / Browser Custom JS; Browser drives real web checks (7.0+) Synthetic monitoring of login flows
Zabbix internal The server monitors itself Queue size, cache usage

Don't poll what you can derive

Dependent items are the load-saver: collect one JSON blob with a single HTTP item, then split it into a dozen dependent items with preprocessing. One request instead of twelve.

Verify your work

  • [ ] You can name the five Zabbix components and what each does (server, DB, frontend, agent, proxy).
  • [ ] systemctl status zabbix-agent2 is active (running) on the monitored host and ss -tlnp shows 10050.
  • [ ] zabbix_get -s <host-ip> -k system.uptime returns a number from the Zabbix server.
  • [ ] Your new host shows a green ZBX (or SNMP) availability icon and data in Latest data.
  • [ ] snmpwalk against your SNMP device returns the system subtree before you created the host.
  • [ ] You can explain when to choose active checks over passive (NAT, DMZ, scale).

Summary

  • Zabbix server collects metrics, evaluates triggers, and fires alerts; config and history live in PostgreSQL/MySQL, the PHP frontend is the UI, and proxies cover remote sites. Run 7.0 LTS in production (8.0 LTS lands ~Q3 2026).
  • Agent 2 is the modern Go agent — one binary, plugins, port 10050; configure Server=, ServerActive=, Hostname=, then link the Linux by Zabbix agent template.
  • Passive = server polls agent (10050 in); active = agent pushes (10051 out) — go active behind NAT.
  • SNMP monitors agentless devices over UDP 161 — verify with snmpwalk, prefer v3, link a vendor or generic SNMP template and let discovery create the items.
  • Beyond those: IPMI (hardware), JMX (Java), HTTP agent (APIs), simple checks (ping), trapper (zabbix_sender pushes), calculated/dependent (derive, don't re-poll), browser (synthetic web checks).

Test yourself