Pick a monitoring tool for a handful of Linux boxes and the first bill you pay is not a licence. It is the RAM and CPU the monitoring server eats, plus the agent you just put on every machine you care about. Most lists of Linux monitoring tools skip that part, so I installed ten of them on identical Ubuntu VMs and measured what each one costs to run.
The ten are Zabbix, Prometheus with Grafana, Checkmk, Netdata, Beszel, LibreNMS, Icinga 2, Nagios Core, Cacti and Glances. Every server stack got the same 2 vCPU, 3 GB VM and watched the same two Linux servers, one on Ubuntu 26.04 and one on 24.04, with every agent running side by side. You get the server’s memory and CPU at idle, the agent’s footprint on the monitored host, the install size, how fast the data grows, and the errors I hit getting each one to show real data.
Ran the whole lab in October 2026 on Ubuntu 26.04.1 servers, with Zabbix 7.0 LTS, Checkmk 2.5, Prometheus 3.15, Grafana 13.2 and the current release of everything else; exact builds are in the table below.
1. Linux monitoring tools compared: the numbers
This first table is the monitoring server. “RAM used” is the whole VM’s MemTotal minus MemAvailable after the stack had been collecting from both hosts for 15 minutes and again at 75 minutes. The Proxmox host crashed and rebooted before the second Icinga and Cacti samples, so theirs were taken 15 minutes after the VMs came back. Their second CPU reading is marked skipped because the host was still busy recovering (Icinga showed 2.95% I/O wait), and the first Icinga sample is a little high on RAM because I had just been browsing its web UI. A bare copy of the same Ubuntu VM sits at 426 to 452 MB, so subtract about 440 MB to get what the tool itself costs. CPU is the system-wide average over 5 minutes on 2 vCPUs.
| Server stack (version tested) | RAM used, two samples | Idle CPU, two samples | Installed size | Data stored after ~1 hour, 2 hosts |
|---|---|---|---|---|
| Beszel hub 0.21.0 | 529 / 545 MB | 0.10% / 0.16% | 37 MB including data | under 4 MB |
| Nagios Core 4.5.14 (source build) | 587 / 623 MB | 0.19% / 0.25% | 9 MB, plus 452 MB of apt packages (compiler, Apache, plugins) | status files only |
| Cacti 1.2.30 (Ubuntu archive build) | 706 / 643 MB | 0.36% / skipped | 297 MB of packages | 4 MB of RRD files |
| Icinga 2.16.5 + Icinga DB + Icinga Web | 836 / 636 MB | 2.42% / skipped | 459 MB of packages | 172 MB MariaDB, mostly the empty InnoDB baseline (Cacti’s idle MariaDB is 176 MB) |
| Netdata 2.12.0 (parent) | 695 / 787 MB | 3.59% / 3.98% | 653 MB of packages | 46 MB (per-second, 3 nodes) |
| LibreNMS 26.9.1.1 | 833 / 786 MB | 1.75% / 1.66% | 521 MB of packages + 1,586 MB in /opt/librenms | 81 MB of RRD files |
| Zabbix 7.0.31 LTS + PostgreSQL | 864 / 872 MB | 0.80% / 1.61% | 205 MB of packages | 221 MB database (mostly the empty schema) |
| Prometheus 3.15.0 + Grafana 13.2.3 | 1,149 / 1,137 MB | 0.74% / 0.91% | 252 MB Prometheus + 1,351 MB Grafana + 508 MB Grafana plugins | 5 MB TSDB |
| Checkmk Community 2.5.0p15 | 2,063 / 2,076 MB | 3.18% / 3.44% | 1,619 MB in /omd/versions | 112 MB site data |
Glances is not in that table because it has no server. It runs on the host it watches, so it sits in the agent table instead.
The second table is what the agent costs on each machine you monitor. Memory is PSS (proportional set size, so shared libraries are not double counted), summed over every process the agent runs. CPU is a percentage of one core, averaged over 5 minutes with pidstat while its server was actively polling it. Ranges cover both hosts and both sampling rounds; the Icinga agent, Glances, NRPE and snmpd were added later and come from a third round taken after their servers were up.
| Agent on the monitored host | Used by | Memory (PSS) | CPU, % of one core | On disk |
|---|---|---|---|---|
| NRPE 4.1.3 | Nagios Core | 1.4 to 1.9 MB | under 0.01% | 70 MB with monitoring-plugins |
| snmpd 5.9.4 | LibreNMS, Cacti | 6.7 to 7.0 MB | 0.04% | 4.6 MB |
| Checkmk agent 2.5.0p15 | Checkmk | 8.6 to 14.3 MB | 0.03 to 0.04% | 6 MB |
| Beszel agent 0.21.0 | Beszel | 14.1 to 17.0 MB | 0.01 to 0.03% | 10.2 MB |
| Zabbix agent 2 7.0.31 | Zabbix | 21.9 to 22.3 MB | 0.13 to 0.14% | 19.8 MB |
| node_exporter 1.12.1 | Prometheus | 21.7 to 23.9 MB | 0.23 to 0.27% | 22.8 MB |
| Icinga 2 agent 2.16.5 | Icinga | 25.0 to 26.4 MB | 0.08% | 47 MB |
| Glances 4.5.7, web mode | itself | 61 to 71 MB | 0.15% | 65 MB virtualenv |
| Netdata 2.12.0 (child, streaming) | Netdata | 270 to 299 MB | 6.3 to 7.2% | 589 MB of packages |
Three things stood out. Netdata’s agent costs more than every other agent in the test combined, roughly 290 MB and 7% of a core on each host, which is the price of collecting thousands of metrics per host every second (16,763 across the three nodes). Checkmk has the heaviest server by a wide margin at about 1.6 GB above the bare OS. And Zabbix, with a full PostgreSQL database behind it, idles at 870 MB total and runs a mid-weight 21 MB agent.
Agent CPU also depends on someone asking for data. Once the Netdata parent was gone, the same child dropped to 3.8 to 4.0% of a core, node_exporter fell to 0.12% and Zabbix agent 2 to 0.04%. So the numbers above are the realistic ones, taken while each server collected on its default schedule.
2. How I tested
Everything ran on one Proxmox node (Intel Core i7-6700) so CPU numbers are comparable. Each server stack got its own VM: q35, OVMF, 2 vCPU with cpu=host, 3,072 MB with the balloon pinned at the same size, a 20 GB virtio disk, and the Ubuntu 26.04 cloud image fully updated. The two monitored hosts had 2 vCPU and 2 GB each. homelab-node1 ran Ubuntu 26.04 and homelab-node2 ran 24.04, and both carried every agent at once.
Every stack was installed from its official package source or release (vendor repo, vendor .deb, GitHub release or the project’s install script), except Cacti from the Ubuntu archive and Glances from PyPI. Defaults were left alone apart from pointing each tool at the two hosts and setting Prometheus retention to 30 days. Versions were read live from each project’s release page on the test day. Then each one collected for 15 minutes before the first sample and 75 minutes before the second (except Icinga and Cacti, see the note above the first table). Server memory came from /proc/meminfo, CPU from sar -u 10 30, agent memory from /proc/<pid>/smaps_rollup and agent CPU from pidstat -u 10 30.
One scope note before the picks. The server stacks were only installed on Ubuntu 26.04. Every agent was installed and measured on both 26.04 and 24.04, and the vendor repositories used here (Zabbix, Icinga, Netdata, Grafana, Checkmk) publish packages for both releases.
This is homelab-node1 with all nine agents running at once, seen through Glances. Netdata and its go.d plugin sit at the top of the memory column, while Zabbix, node_exporter, Icinga and Beszel each stay around 1% of RAM:
3. Zabbix: best all-round Linux server monitoring
Zabbix is the one I’d put in front of most teams with a few dozen to a few thousand Linux servers. One server process, one database, one agent per host, and the stock “Linux by Zabbix agent” template gives you 75 items, 16 graphs and working triggers per host the moment you link it. On my lab it idled at 872 MB with PostgreSQL included, and the agent stayed around 21 MB and 0.14% of a core.
Version choice matters here. 7.0 is the current LTS line (full support into 2027, security fixes into 2029), 7.4 is the newest standard release, and the 8.0 LTS was still at release candidate stage when I tested. The 7.0 repo already has native packages for Ubuntu 26.04, so the install is the usual repo-package dance:
. /etc/os-release
curl -sLO "https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_7.0+ubuntu${VERSION_ID}_all.deb"
sudo dpkg -i "zabbix-release_latest_7.0+ubuntu${VERSION_ID}_all.deb"
sudo apt-get update
sudo apt-get install -y postgresql zabbix-server-pgsql zabbix-frontend-php php-pgsql zabbix-nginx-conf zabbix-sql-scripts zabbix-agent2Watch the schema path when you import it. On 7.0 LTS the file lives under /usr/share/zabbix-sql-scripts/, and copying the import line from newer Zabbix docs, which use /usr/share/zabbix/sql-scripts/, fails like this:
gzip: /usr/share/zabbix/sql-scripts/postgresql/server.sql.gz: No such file or directoryCreate the database role and database first (pick your own password) and put the same password in zabbix_server.conf:
sudo -u postgres psql -c "CREATE USER zabbix WITH PASSWORD 'ChangeMe2026';"
sudo -u postgres createdb -O zabbix zabbix
sudo sed -i "s/^# DBPassword=.*/DBPassword=ChangeMe2026/" /etc/zabbix/zabbix_server.confThen the schema:
zcat /usr/share/zabbix-sql-scripts/postgresql/server.sql.gz | sudo -u zabbix psql -q zabbixWithin ten minutes the default template had already raised two problems per host: “/etc/passwd has been changed” and “Number of installed packages has been changed”. That’s because the other agents’ installers had just created system users and packages. Expect the same noise on any fresh rollout, and acknowledge it rather than disabling the triggers, because they are useful later.
The full walkthrough, with the frontend wizard and agent setup, is in the Zabbix on Ubuntu 26.04 guide. The Hosts view below shows both lab machines reporting through agent 2, each with 75 items and 16 graphs from the stock template:
4. Prometheus and Grafana: best for metrics and Kubernetes shops
If your team already lives in PromQL, or you’ll monitor Kubernetes next to plain servers, this is the stack. Prometheus scrapes node_exporter every 15 seconds, Grafana draws it, and every exporter you add later speaks the same format. Together they idled at about 1.14 GB. Grafana was the biggest piece at 318 MB plus roughly 200 MB more in its bundled plugin backend processes, while Prometheus itself sat at 123 MB.
Disk is where Grafana surprised me. The package is 1.35 GB installed, and first start unpacks another 508 MB of bundled plugins into /var/lib/grafana. Prometheus is a 252 MB pair of static binaries. Ubuntu 26.04’s own prometheus package is still on the old 2.x line, so I used the release tarball:
PROM_VER=$(curl -s https://api.github.com/repos/prometheus/prometheus/releases/latest | grep '"tag_name"' | cut -d '"' -f4 | sed 's/^v//')
echo "PROM_VER=$PROM_VER"
cd /tmp && curl -sLO "https://github.com/prometheus/prometheus/releases/download/v${PROM_VER}/prometheus-${PROM_VER}.linux-amd64.tar.gz"
tar xzf "prometheus-${PROM_VER}.linux-amd64.tar.gz"
sudo install -m 0755 prometheus-${PROM_VER}.linux-amd64/{prometheus,promtool} /usr/local/bin/The detected version on test day:
PROM_VER=3.15.0Prometheus also has a long-term support line now (the current LTS is supported until mid 2027), which is worth pinning if you’d rather not chase monthly releases. The unit file, scrape config and Grafana setup are in the Prometheus install guide and the Grafana walkthrough. Alerts need Alertmanager on top, which is the part people forget. The community “Node Exporter Full” dashboard (ID 1860) on homelab-node1 looks like this:
5. Checkmk Community: the most checks for the least setup
Checkmk found 22 services per host on its own, including NTP offset, mount options, systemd failures and per-filesystem trends, and it was the only tool that flagged something real on the lab without me configuring anything: memory commit at 116.84% on the 2 GB, swapless hosts. That auto-discovery is why people put up with its weight. It was the heaviest server here, at 2.07 GB used and 3.4% CPU at idle, with Apache, a UI job scheduler and several automation helpers resident.
Mind the rename if you’re following older guides. Raw Edition is now called Community, and in the 2.5 line the package names changed too, so the file is check-mk-community-* and the old check-mk-raw-* download URLs return 404. Checkmk publishes a JSON index of current builds, which makes the install scriptable:
sudo apt-get install -y jq
. /etc/os-release
J=$(curl -s https://download.checkmk.com/stable_downloads.json)
CMK_BRANCH=$(echo "$J" | jq -r '.checkmk | keys | sort_by(split(".")|map(tonumber)) | last')
CMK_VER=$(echo "$J" | jq -r ".checkmk[\"$CMK_BRANCH\"].version")
CMK_DEB=$(echo "$J" | jq -r ".checkmk[\"$CMK_BRANCH\"].editions.community.${VERSION_CODENAME}[0]")
CMK_SHA=$(echo "$J" | jq -r ".checkmk[\"$CMK_BRANCH\"].editions.community.${VERSION_CODENAME}[1]")
echo "CMK_VER=$CMK_VER CMK_DEB=$CMK_DEB"
cd /tmp && curl -sLO "https://download.checkmk.com/checkmk/${CMK_VER}/${CMK_DEB}"
echo "${CMK_SHA} ${CMK_DEB}" | sha256sum -c
sudo apt-get install -y "./${CMK_DEB}"
sudo omd create monitoring
sudo omd start monitoringIt resolved to the current Community build for Ubuntu 26.04 (resolute):
CMK_VER=2.5.0p15 CMK_DEB=check-mk-community-2.5.0p15_0.resolute_amd64.debOn the hosts, the agent comes from the site itself, and cmk-agent-ctl register switches it to TLS. Skip registration and the agent warns that “The agent controller is operating in an insecure mode!”, which is fine in a lab and nowhere else. Run service discovery after the agent’s first data has arrived, not right after adding the host. My first discovery pass ran too early and found only the three Checkmk housekeeping services. The second found all 22:
For container hosts, the Checkmk Docker monitoring guide covers the extra agent plugin.
6. Netdata: per-second detail, and the heaviest agent
Netdata collected 16,763 metrics across three nodes at one-second resolution with zero configuration. Nothing else comes close for troubleshooting a box that’s misbehaving right now. The cost is on every monitored host: the child agent and its plugins used 270 to 299 MB and 6.3 to 7.2% of a core while streaming to a parent, and its packages take 589 MB of disk. On a 1 GB VPS that’s a real chunk of the machine.
Two other things to know before you commit. The agent is GPL-3.0, but the dashboard UI it serves is under the Netdata Cloud UI licence (NCUL1), which is not open source. And the local dashboard greets you with “Please sign-in to continue”. There’s a “Skip and use the dashboard anonymously” link under the button, and it works fine, but it’s easy to miss:
That first screen is useful in its own right. With the default 1 GB per tier, the parent estimated 4 days 10 hours of per-second history for three nodes. The install is the kickstart script, which adds Netdata’s own repository (it has native 26.04 packages):
curl -fsSL https://get.netdata.cloud/kickstart.sh -o /tmp/netdata-kickstart.sh
sh /tmp/netdata-kickstart.sh --stable-channel --disable-telemetry --non-interactiveEvery run ended with “File not found when checking for remote file at https://repository.netdata.cloud/repos/repoconfig” under non-fatal warnings. It is harmless; the agent installed from the right repo each time. Streaming children to a parent takes an [stream] block in /etc/netdata/stream.conf on each child and a matching API key section on the parent. The parent dashboard with all three nodes:
The single-host setup is covered in the Netdata on Ubuntu 26.04 guide.
7. Beszel: the lightest option for a homelab
Beszel is the one I’d put on a Raspberry Pi or a cheap VPS. The hub idled at 545 MB total, about 100 MB above a bare Ubuntu VM, with 0.16% CPU and 37 MB on disk including its data. The agent used 14 to 17 MB and barely registered on CPU. You get CPU, memory, disk, network, Docker containers, systemd services, S.M.A.R.T. and simple alerts, and that’s close to the whole feature list. There are no custom checks and no SNMP. It’s also still a 0.x project, so expect changes between releases.
The hub is one static binary that the official script drops into /opt/beszel with a systemd unit on port 8090:
curl -sL https://get.beszel.dev/hub -o /tmp/install-hub.sh && chmod +x /tmp/install-hub.sh
sudo /tmp/install-hub.shAdding hosts is the neat part. Turn on a universal token under Settings, Tokens & Fingerprints (/settings/tokens), then pass it to the agent installer with the hub’s public key, and each agent registers itself over a WebSocket with no “Add System” clicking. Both of mine showed up within seconds:
The full setup, including Docker mode and alerts, is in the Beszel install guide. Each system also gets a detail page with an hour of history and no extra setup:
8. LibreNMS: best when switches and routers are in the mix
LibreNMS speaks SNMP first, so it’s the pick when your Linux servers share a rack with switches, firewalls and UPSes. On Linux hosts it needs nothing but snmpd, which used 7 MB and 0.04% of a core here. The server idled at 786 to 833 MB and under 1.8% CPU, with MariaDB as the biggest process at 165 MB. It auto-discovered the OS, kernel, CPU model and interfaces as soon as each host was added.
There is no package; you clone the repo and run Composer, which is why /opt/librenms is 1.6 GB. The docs ship a web installer, but you can do the same from the CLI. If you write the database settings into .env and run the migrations yourself, remember the app key, because validate.php stops with a stack trace ending in this:
In EncryptionServiceProvider.php line 83:
No application encryption key has been specified.Generate the key and drop the installer flag, then validation passes:
sudo su - librenms -c 'php artisan key:generate --force -n'
sudo su - librenms -c "sed -i '/^INSTALL=true/d' .env"
sudo su - librenms -c './validate.php'Adding devices from the CLI is one line each (lnms device:add --v2c -c <community> <ip>). The device page fills in from SNMP alone:
The LibreNMS guide for Rocky and AlmaLinux covers the RHEL side, including the SELinux policy it needs.
9. Icinga 2: Nagios-style checks on a modern stack
Icinga 2 keeps the Nagios plugin ecosystem and replaces everything around it: a real configuration language, a TLS cluster protocol for agents and satellites, an API, and Icinga DB with Redis feeding a modern web UI. The full stack (Icinga 2, Icinga DB, Redis, MariaDB, Apache and Icinga Web) idled at 636 to 836 MB. The agent is Icinga 2 itself in agent mode, at 25 MB and 0.08% of a core, enrolled with a one-time ticket from the master.
The repo at packages.icinga.com already has 26.04 builds of everything. My one stall was Icinga DB. The package starts the daemon on install, before you’ve written the database password into /etc/icingadb/config.yml, and systemctl enable --now on an already-running unit doesn’t restart it. The daemon kept retrying with the old credentials and then exited:
icingadb[4331]: Can't connect to database error="can't connect to database: retry deadline exceeded: Error 1045 (28000): Access denied for user 'icingadb'@'localhost' (using password: YES)"Icinga Web just shows “No items found” while that is happening. Restart the daemon after editing the config:
sudo systemctl restart icingadbA few seconds later the log reports the initial sync and the services appear:
icingadb[21775]: config-sync: Finished initial state sync in 215.643224msThe Icinga DB Web services list right after the sync, sorted by severity:
Those three CRITICAL rows are real, and you’ll see the same thing in Nagios. More on that in the errors section. The older Icinga 2 on Ubuntu and Debian guide walks through the master setup step by step, and Icinga Director takes over once hand-written config gets old.
10. Nagios Core: still small, still manual
Nagios Core was the lightest full server in the test apart from Beszel: 587 MB total and 0.19% CPU, and the compiled install is only 9 MB. The NRPE agent is under 2 MB. What you pay instead is time. Every host and service is a hand-written object file, the CGI web UI hasn’t changed in a decade, and there are no graphs without add-ons.
Build it from source rather than using Ubuntu’s nagios4 package. The archive still ships the old 4.4 line, which predates the security fixes in the 4.5 releases. The latest release tag can be detected from GitHub:
NAGIOS_TAG=$(curl -s https://api.github.com/repos/NagiosEnterprises/nagioscore/releases/latest | grep '"tag_name"' | cut -d '"' -f4)
echo "NAGIOS_TAG=$NAGIOS_TAG"
cd /tmp && curl -sL "https://github.com/NagiosEnterprises/nagioscore/releases/download/${NAGIOS_TAG}/${NAGIOS_TAG}.tar.gz" | tar xzOn test day that was:
NAGIOS_TAG=nagios-4.5.14One syntax trap cost me a failed config check. A semicolon starts a comment in Nagios object files, so a compact one-line define service { use generic-service; host_name ... } loses everything after the first ; and the definition breaks. Put one directive per line and verify with sudo /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg before reloading. The full build, Apache auth and plugin setup are in the Nagios on Ubuntu 26.04 guide. With NRPE on both hosts, the status page looked like this:
11. Cacti: RRD graphs for SNMP devices
Cacti is a graphing tool more than a monitoring tool. It polls SNMP, writes RRD files and draws them, and the alerting needs plugins. It is still handy for long-lived bandwidth and load graphs on network gear, and it’s the easiest install here: with debconf preseeded, the Ubuntu package sets up the database and skips the web wizard entirely. The catch is the version. Ubuntu 26.04 ships 1.2.30, and upstream’s 1.2.31 fixed more than 30 CVEs, including an authenticated remote code execution bug (CVE-2026-39949). Treat the archive build as a lab install, and use the upstream release for anything reachable from an untrusted network. The server idled at 643 to 706 MB.
The Debian packaging sets the admin web password to the database password you give debconf, which is not obvious from the login screen. The CLI tools in /usr/share/cacti/cli add devices without clicking. The “Net-SNMP Device” template created 11 graphs per host on its own. The solid block on the CPU graph before about 17:00 is the time before the device existed, which this template draws as 100% I/O wait:
For RHEL-family hosts, see the Cacti install on Rocky and AlmaLinux.
12. Glances: one host, right now
Glances is the odd one out: no server, no history, just a very good top replacement with a web mode. In web mode on port 61208 it used 61 to 71 MB and 0.15% of a core. That’s why it’s the screenshot near the top of this article: one page showing every process on the box. Ubuntu 26.04 packages an older 4.3 build, so I installed the current release from PyPI into a virtualenv:
sudo apt-get install -y python3-venv
sudo python3 -m venv /opt/glances
sudo /opt/glances/bin/pip install -q 'glances[web]'
sudo ln -sf /opt/glances/bin/glances /usr/local/bin/glances
glances --versionThe version line confirms the PyPI build:
Glances version: 4.5.7Plain glances -w starts the web server on port 61208 with no login, so keep it on a trusted network or put it behind a reverse proxy. It can also export to InfluxDB or Prometheus if you want history; the terminal monitoring tools roundup compares it with htop, btop and friends.
13. Also considered
These came up while picking the ten. Each one sat out this round for a reason:
- Sensu Go has packages for 26.04, but no release since June 2026 and a commercial licence for several features.
- OpenObserve and SigNoz are observability platforms (logs, traces, metrics) more than server monitoring, and both are better tested as their own comparison.
- VictoriaMetrics is a Prometheus-compatible store. It is a drop-in swap for the Prometheus server above, not a separate kind of tool.
- Uptime Kuma checks whether endpoints answer, not how a host is doing. See the Uptime Kuma guide if that’s what you need.
- Monit watches and restarts local services. It is great on a single box, but it is not a fleet monitor; the Monit guide covers it.
14. Errors and false alarms I hit
The tool-specific install errors are in each section above. These ones aren’t bugs in any tool, but every new install will trip over them.
“SWAP CRITICAL – 0% free (0MB out of 0MB) – Swap is either disabled, not present, or of zero size.”
Ubuntu cloud images have no swap, and the stock check_swap from monitoring-plugins treats that as critical. Nagios and Icinga both lit up red for it on every host, including the Icinga server itself. Either add swap, or add -n ok (--no-swap=ok) to the existing check, for example check_swap -w 50% -c 25% -n ok, which returns SWAP OK on the same box. Keep the thresholds: the older monitoring-plugins on Ubuntu 24.04 refuses to run check_swap without -w and -c. On the Nagios side the swap check was a command I added to NRPE; the CRITICAL default for no swap comes from the plugin itself.
“LOAD WARNING – scaled load average: 0.04, 0.12, 0.10”
Ubuntu’s default nrpe.cfg runs check_load -r -w .15,.10,.05 -c .30,.25,.20. The -r flag divides load by the CPU count, so a per-core 5-minute load of 0.12 (0.24 total on two cores) trips the warning on an idle box, and so does a 15-minute 0.10. Raise the thresholds in /etc/nagios/nrpe.cfg before you roll NRPE out.
Checkmk “Memory WARN, Committed: 116.84%”
This one is a real warning, not noise. With no swap, committed memory above 100% means the kernel is relying on overcommit, and a burst can end in the OOM killer. Checkmk was the only tool that raised it by default.
15. Which monitoring tool I’d run for 5, 50 and 500 servers
5 machines at home or a couple of VPSes: Beszel. About 100 MB of server overhead, a 15 MB agent and setup in ten minutes. Add Glances on the box you’re poking at that day.
50 servers at a small company: Zabbix on the LTS line. The server and database fit in under 900 MB, the agent stays around 21 MB, and the stock templates come with triggers that work. Pick Checkmk instead if nobody has time to tune templates and the monitoring box can spare 2 GB, because its auto-discovery found more on its own than anything else here.
500 servers, or anything with Kubernetes: Prometheus with Grafana and Alertmanager, with LibreNMS next to it if the network gear matters. node_exporter’s 22 MB and 0.25% of a core scale fine, and the exporter ecosystem covers what’s left.
Netdata fits in at any of those sizes as the troubleshooting layer, provided the hosts can spare about 300 MB and 7% of a core for it. Nagios Core and Cacti still do their jobs at very low cost, but I’d only pick them today to extend an install that already exists.
