// Engineering Log

Monitoring: Part 2 — Munin

Published on 2026-09-22

// Fast route

This article belongs to the topic Deploy and reliability.

Munin is one of the oldest open-source monitoring systems (GPLv2). It collects system metrics from servers and builds ready-made graphs from them: no query language, no separate database, and almost no configuration. The project continues to release fixes for the 2.0 branch — versions 2.0.77 and 2.0.78 were released in September 2026 — but it gains almost no new features.

How Munin works

Munin consists of two parts.

  • munin-node — an agent on each monitored server. It listens on TCP port 4949 and runs plugins on request, which return metric values.
  • munin (master) — the collection server. Every five minutes it polls all agents, stores data in RRDtool files and builds HTML pages with graphs for day, week, month and year.

A plugin is a normal executable script in any language. In config mode it describes the graph; in normal mode it outputs values. So you can add your own metric, for example the number of orders in a database, in about half an hour.

RRDtool stores data in fixed-size files: the older the data, the more it is averaged. A yearly graph therefore shows the overall trend, not the exact values of each five-minute interval.

Installation on Debian and Ubuntu

Packages are available in the standard repositories.

On the master server:

bash
sudo apt install munin munin-node

On each monitored server:

bash
sudo apt install munin-node

By default the agent accepts connections only from the local address. To have it polled by the master, add the master’s address to /etc/munin/munin-node.conf as a regular expression:

allow ^127\.0\.0\.1$
allow ^192\.0\.2\.10$

Then select suitable plugins and restart the agent:

bash
sudo munin-node-configure --suggest          # which plugins are suitable for this server
sudo munin-node-configure --shell | sudo sh  # enable the suggested ones
sudo systemctl restart munin-node

On the master each server is described in /etc/munin/munin.conf:

[web01.example.ru]
    address 192.0.2.21
    use_node_name yes

After a few polling cycles the graphs will appear in the directory served by the web server (in Debian packages — /var/cache/munin/www). It’s better to protect the pages with a password or restrict access to the internal network: they reveal the internal setup of servers.

Advantages

  • Quick start. Basic monitoring of several servers can be set up within an hour.
  • Many existing plugins. CPU, memory, disks, network, Nginx, Apache, MySQL, PostgreSQL, mail queues — most of these are enabled automatically.
  • Lightweight agent. munin-node uses almost no resources and is suitable even for low-end machines.
  • Simple custom metrics. A plugin is written in Bash, Python or Perl without learning an API.
  • Everything on one page. Graphs for all servers are visible at once, without configuring dashboards.

Drawbacks

  • Limited scalability. With hundreds of servers the five-minute polling and graph-building cycle fails to complete on time.
  • Weak alerting. Munin can compare values with warning and critical thresholds and call an external command, but it lacks grouping, suppression and routing of alerts.
  • Static graphs. Images cannot be zoomed, arbitrary metrics compared, or ad-hoc queries built.
  • Coarse granularity. The five-minute interval and averaging of old data do not allow analysing short spikes.

When Munin is appropriate today

  • A few servers at a small company or managed by a single administrator.
  • You need to quickly get historical load to understand whether resources are sufficient.
  • Old servers where Munin already runs and there is no reason to replace it.

If you have more than two or three dozen servers, need flexible alerting or application metrics, it’s better to choose Prometheus or Zabbix from the start. When migrating, it’s useful to remember that many Munin plugins have equivalents among Prometheus exporters and Zabbix templates.

Common mistakes

  • Agent exposed to the outside. Port 4949 is available from the Internet without restrictions. You should add an allow rule only for the master and keep the port closed by a firewall.
  • Graphs unprotected. The directory with HTML pages is published without a password.
  • Plugin doesn’t appear. After adding a plugin you forgot to restart munin-node; you can check the output with munin-run <plugin_name>.
  • Monitoring without alerts. Graphs are built but nobody looks at them. At minimum, set thresholds and notification sending for disk usage and server availability.

// Similar task

If you are dealing with something similar

This article belongs to one of the main working topics. You can keep reading on the topic, go to the homepage to understand what I do, or open the service pages directly.

Article topic

Deploy and reliability

Docker, CI/CD, releases, monitoring, observability, and incident handling.

Typical tasks behind this topic

  • Set up deployment without manual chaos
  • Add monitoring, alerts, and baseline observability
  • Investigate incidents and stabilize production

// Next step

If you need help with this topic, not just another article, it is better to go straight to the service page. The homepage and topic collection stay available as secondary routes.

Open services

// Contact

Need help?

Get in touch with me and I'll help solve the problem

I reply within one business day (03:00-13:00 GMT)

Или оставьте заявку здесь:

Confirm that you are not a bot.

Write and get a quick reply