LibreNMS vs Zabbix: which fits a network-first shop

If most of what you monitor is switches, routers, firewalls and access points, start with LibreNMS. Give it an address and SNMP credentials, and after the next discovery run every port, sensor and neighbor is graphed without a single check written by hand. If servers, databases and applications matter as much as the network, if you want escalation chains, or if you have branch sites behind thin links, Zabbix fits better, at the price of more setup per device type. That is the short answer to LibreNMS vs Zabbix, and plenty of networks end up running both: LibreNMS for the wire, Zabbix for what plugs into it.

The longer answer comes from how each tool thinks, which shows in the first week more than in feature lists. What follows is drawn from both projects' documentation. The wider comparison of Nagios, Zabbix, LibreNMS and Prometheus covers the whole field; this piece stays on these two. Version details are true at the time of writing, for Zabbix 7.0 LTS and later and for current LibreNMS releases.

LibreNMS vs Zabbix side by side

One 48-port switch in each tool

LibreNMS first. As the librenms user in the install directory, with SNMPv3 rather than a v2c community that anyone on the segment could sniff:

./lnms device:add --v3 -u monitor -a SHA -A 'auth-passphrase' \
  -x AES -X 'priv-passphrase' 192.0.2.30

# Affiliate links: we may earn a commission. We also earn from qualifying purchases on eBay.

Giving both passphrases makes it an authPriv user. If the command fails, test the same credentials with net-snmp first; the snmpwalk examples for v3 show the matching flags. Within minutes LibreNMS runs discovery: it identifies the OS, finds the 48 access ports and the uplinks, VLANs, power supplies, temperature sensors, the forwarding table and the LLDP neighbors, then polls all of it every five minutes. There is nothing to choose and nothing to template. The work moves later, to deciding which ports deserve an alert.

Zabbix does the same job in deliberate steps:

1. Create a host in a host group with an SNMP interface: address, SNMP version, and the v3 user and passphrases (user macros keep secrets out of every host form).
2. Link a template. Zabbix ships SNMP templates for many switch families plus generic ones for anything that speaks the standard MIBs.
3. Let low-level discovery run. The template's rule walks the interface table and creates items from prototypes for each port: status, traffic, errors, discards, speed, with trigger and graph prototypes alongside.
4. Tune the filters. User macros decide which interfaces get items at all. Out of the box they skip noise such as loopbacks; on an access switch you may want uplinks only.

A 48-port switch easily ends up with several hundred items, each with its own interval and storage period. That is the price of flexibility, and the point of it: uplink traffic every 30 seconds, the serial number once a day. LibreNMS polls everything on one schedule.

Discovery means two different jobs

Finding devices. LibreNMS follows the network. Once one device is in, CDP, LLDP and the routing tables point it at neighbors, which it tries with your configured SNMP credentials, but only inside subnets you list with lnms config:set nets.+ '10.20.0.0/16'; snmp-scan.py sweeps those subnets on demand. One trap for new installs: by default LibreNMS adds discovered devices by reverse DNS name, not IP, so a management network without PTR records yields nothing until you fix DNS or change that setting. Zabbix scans instead. A network discovery rule names an IP range, the checks to try (ICMP, SNMP OIDs, agent keys, TCP ports) and an interval, and actions decide what happens to each result: add the host, group it, link a template. Servers running the agent in active mode can register themselves.

Finding things on a device. LibreNMS discovery modules run every six hours by default, and within minutes for new devices; they define what the poller collects. Zabbix low-level discovery runs per rule on the interval set in the template and adds or removes items as ports and file systems come and go.

The practical difference: LibreNMS draws you a picture of a network you never fully documented. Zabbix builds exactly what you told it to build, and nothing else.

Data model and storage

LibreNMS keeps inventory and current state (devices, ports, sensors, neighbors) in MySQL or MariaDB, and time series in RRD files. The default archives hold five-minute samples for a week, 30-minute averages for a month, two-hour averages for about four months and daily values for close to four years, with minimum and maximum alongside. An RRD file never grows after it is created, so disk use tracks the number of ports and sensors, not time. The catch is that the step is fixed inside each file. Moving to one-minute polling means changing the step and heartbeat settings, then converting existing files with lnms maintenance:rrd-step after a backup. Read choosing a polling interval before the first device goes in.

Zabbix stores everything in SQL: MySQL, MariaDB or PostgreSQL, with TimescaleDB as an option on PostgreSQL. Raw values land in history tables and hourly minimum, average and maximum in trends. Each item carries its own history and trend periods, and the housekeeper deletes what has expired. Disk use is items times samples times retention, so it grows with every template you link. On bigger installs, TimescaleDB partitioning and compression keep housekeeping from becoming a project of its own.

How alerts are written

A LibreNMS rule is a set of conditions over database fields, built in the web interface. This one fires only for uplinks that are administratively up but operationally down, on a device that still answers:

macros.device_up = 1 AND ports.ifAdminStatus = "up" AND ports.ifOperStatus != "up" AND ports.ifAlias LIKE "UPLINK%"

The last clause relies on a good habit: port descriptions that say what the port is for. Each rule has a severity, a delay, a repeat interval and a maximum count, and can be limited to devices, groups or locations. Parent devices stop a whole building from paging when its one uplink router dies. Notifications leave through transports such as email, Slack, Microsoft Teams, Telegram, PagerDuty and Alertmanager. Anything the builder cannot express goes into an SQL override.

A Zabbix trigger is an expression over item history. A link-down trigger for one port, written by hand:

last(/core-sw1/net.if.status[ifOperStatus.10101])=2

In practice the template's trigger prototype does this for every discovered port, with a user macro to switch it off per interface. Triggers have six severities from Not classified to Disaster, can depend on other triggers (no storm of port alerts when the whole switch is unreachable), and open problems that people acknowledge and comment on. Functions such as avg(), nodata() and change() make time-window logic easy: "average above 80 percent for 15 minutes" or "no data for 10 minutes". Actions then route by host group, tag or severity, with escalation steps such as "message the on-call channel now, email the network lead if nobody has acknowledged after 30 minutes".

Either tool will page you about the wrong things if you let it. Read alerts people still read before switching notifications on.

Traps and syslog

Both use net-snmp's snmptrapd on UDP 162. LibreNMS points it at its own handler (traphandle default /opt/librenms/snmptrap.php), matches each trap to a device and records it as an event. Zabbix has snmptrapd write traps to a file through a receiver script or SNMPTT; the SNMP trapper process reads that file into snmptrap[] items, and you write triggers on them like any other value. LibreNMS can also receive syslog and show it per device, while Zabbix reads log files through its agent. The field manual's SNMP traps guide covers the receiving side for any tool.

Scaling and branch offices

LibreNMS polls from the center. Its documentation puts one poller at roughly a thousand devices or more, depending on latency. Past that, distributed polling adds poller nodes coordinated by the dispatcher service and Redis, all sharing one database and one RRDCached instance. The documentation says plainly that this is not meant for remote polling, so a branch behind a slow VPN is still polled across the VPN.

Zabbix was built for that case. A proxy at the branch collects locally, buffers if the link to the server drops, and forwards when it returns. Since 7.0, proxies can be grouped for load balancing and failover, and the server has had a high-availability cluster mode since 6.0. Version 7.0 also added asynchronous pollers, which keep many SNMP and agent requests in flight from one process. On a large install the database is usually the first thing to tune, not the pollers.

Living with it: upgrades and configuration

LibreNMS updates itself. By default daily.sh runs from cron every night, pulls the latest code from the master branch and migrates the database. Many admins switch to the monthly release channel with lnms config:set update_channel release, or limit updates to set weekdays, so changes land when someone is around. Settings live in the database and are changed in the web interface or with lnms config:set; ./validate.php checks the install after any change.

Zabbix upgrades come from its package repositories, and the server upgrades the database schema on first start of a new major version, so a backup first is not optional. LTS releases get five years of support, three full and two limited. Templates export and import as YAML, and the API covers nearly everything the front end does, which is how larger teams keep configuration under review. Both projects keep their documentation on librenms.org and zabbix.com.

Who each one suits

LibreNMS suits:

• networks that are mostly switches, routers, firewalls, wireless controllers and UPS cards
• small teams who want graphs and neighbor maps this week
• ISPs and campuses that bill on ports (it has a 95th percentile and quota billing module)
• home labs with a managed switch and a spare Raspberry Pi

Zabbix suits:

• mixed estates where servers, databases and applications count as much as the network
• teams that need escalations, acknowledgments and permissions by host group
• organizations with branch sites behind thin links
• anyone who needs per-metric intervals or triggers over time windows

Running LibreNMS for the network and Zabbix for servers is a sound design, not a failure to choose.

Five questions that settle it

1. Does most of what pages you come from network gear? LibreNMS.
2. Do you have sites behind slow or unreliable links? Zabbix, with a proxy per site.
3. Do some metrics need 30-second polling while others need hourly? Zabbix.
4. Does one person need graphs for 200 switches by next Friday? LibreNMS.
5. Who will maintain it two years from now, and do they prefer a tool that discovers or one they define? Ask them, and let that answer outweigh this table.