Munin’s Architecture


Munin has a master-nodes architecture.



Here we describe the components of Munin. On page Protocols we talk about the rules for interaction between them.


The master is responsible for all central Munin-related tasks.

It regularly connects to the various nodes, and then synchronously asks for the various metrics configuration and values and stores the data in RRD <> files.

On the fly the values are checked against limits (that you may set) and the Munin-Master will croak, if values go above or below the given thresholds.

Here we also generate the graphs, as this is a heavy task that needs some resources. Recent versions of Munin use cgi-graphing to generate graphs only when the user wants to see them.


The node is a small agent running on each monitored host. We can have agent-less monitoring but this is a special case that will be addressed later. On machines without native support for Perl scripting you can use munin-c, which is a C rewrite of munin node components. (Look for the details in the munin-c chapter.)

Note that an usual setup involves having a node running also on the master host, in order to munin to monitor itself.


  • Each Munin master may monitor one or more Munin nodes (1:n)
  • More than one Munin master may monitor one or more Munin nodes (n:m)
    • Does this confuse lightly stupid plugins?
    • Is “multi-master” configurations tested, known and/or documented?
    • Does the Plugin-writing-howto describe how the plugin should behave if queried more often than in five minutes intervals and/or from different Munin masters?
  • Each Munin node controls one or more plugins (1:n)
  • Each plugin returns, when queried:
    • One or more general directives to control the plugin itself, with corresponding values
    • One or more data sources (fields) described by fieldname (1:n)
    • Each data source has one or more attributes (1:n), with corresponding values