Munin

Last reviewed Sep 13, 2026 · 858 words

Munin has been drawing the same green-and-blue graphs since 2004 and needs about 128 MB and a cron entry to do it. Every 5 minutes the master polls each node, writes the values into RRD files, and renders static PNGs and HTML. There is no database to size, no dashboard to build, no query language to learn, and no way to see what happened 90 seconds ago. That last sentence is the entire buying decision: if you want to know what your disks, load and network did last month, Munin is the least effort per graph of anything in the monitoring category. If you want to see a spike as it happens, it is the wrong tool and the tools below are right.

Fifteen minutes from apt to graphs

On Debian or Ubuntu the master and the node install from the distribution:

apt install munin munin-node apache2 libapache2-mod-fcgid
munin-node-configure --suggest --shell | sh
systemctl restart munin-node

The second command is the magic. Munin ships a few hundred plugins; --suggest runs each one's autoconf check and prints the symlink commands for the ones whose prerequisites exist on this machine, so a box with PostgreSQL and nginx gets their graphs without you asking. Then point the master at the node in /etc/munin/munin.conf:

[web.example.org]
    address 10.0.0.12
    use_node_name yes

Allow the master's IP in the node's /etc/munin/munin-node.conf (allow ^10\.0\.0\.1$), open TCP 4949 between them, and wait 10 minutes. Two cron runs later there are graphs for the last day, week, month and year. Adding the tenth server is the same 4 lines. On the master, RRD files are fixed-size (well under 1 MB per plugin per node), so 20 nodes with 30 plugins each fit in a few hundred MB of disk with no retention policy to think about.

Writing a plugin is a shell script that prints two things

This is the feature that keeps Munin on my boxes. A plugin is any executable that prints field.value 42 when run, and prints graph metadata when run with config:

#!/bin/sh
case $1 in
config)
  echo 'graph_title Backup age (hours)'
  echo 'graph_vlabel hours'
  echo 'age.label hours since last restic snapshot'
  echo 'age.warning 30'
  echo 'age.critical 50'
  exit 0;;
esac
printf 'age.value %s\n' "$(( ($(date +%s) - $(stat -c %Y /backups/latest)) / 3600 ))"

Drop that in /etc/munin/plugins/, make it executable, and the next poll graphs it, thresholds included. Prometheus exporters and Netdata collectors are more capable and take an order of magnitude more code. For "graph this number from this box forever", nothing is shorter.

The five-minute resolution is a hard ceiling

Munin's cron cadence is 5 minutes and while you can lower it, the RRD files, plugin protocol and graph rendering all assume it. Anything shorter and you are fighting the tool. The consequence is that Munin cannot show you a 30-second CPU spike, a burst of 502s, or a container that restarted and recovered inside a polling gap. Alerting exists (warning and critical thresholds feed a contact command) but it fires on the same 5-minute schedule and has no notion of silence windows or escalation. Treat it as trend history with a nudge, not as paging. For uptime and alerting I keep something else beside it; the homelab monitoring and uptime piece covers pairing choices.

Netdata and Prometheus are the bigger siblings, and they are bigger

Netdata collects per-second on the node, auto-discovers far more than Munin's autoconf, and its dashboard is what people expect a monitoring tool to look like in 2026; it also idles at a couple of hundred MB rather than 128, and is a product with a cloud upsell rather than a Perl package. Prometheus with Grafana is the standard for anyone who wants queries, labels, and alerting rules with real logic, at the cost of learning PromQL and designing every dashboard yourself. The Netdata versus Prometheus piece splits those two. Munin loses to both on everything except operational cost and plugin simplicity, and for a homelab of 3 to 20 boxes that only wants history, those two things are most of what matters. The interface does look like 2004; it also renders in a text-mode browser and has never once broken on an upgrade in my experience.

What I'd do

Install Munin on every long-lived server the day it is built and never think about it again; the 15 minutes pays back the first time you wonder whether disk usage grew steadily or jumped. Put Uptime Kuma or Gatus beside it for the "is it down right now" question. Reach for Prometheus and Grafana only when someone needs to query the data or when a service starts emitting metrics of its own. The trap is trying to make Munin do alerting properly. It will not, and the people who try end up resenting a tool whose only promise was cheap graphs, kept.