Nomenclature

To be able to use Munin, to understand the documentation, and - not to be neglected - to be able to write documentation that is consistent with Munin behavior, we need a common nomenclature.

Common terms

Term:Munin Master
Explanation:The central host/server where Munin gathers all data to. This machine runs munin-cron
Synonyms:master
Term:Munin Node
Explanation:The daemon/network service running on each host to be contacted by the munin master to gather data. Each node may monitor several hosts. The Munin master will likely run a munin-node itself.
Synonyms:In SNMP this might be called an agent.
Term:Plugin
Explanation:Each Munin node handles one or more plugins to monitor stuff on hosts
Synonym:service
Term:Host
Explanation:A machine monitored by Munin, maybe by proxy on a munin node or via a snmp plugin
Synonym:N/A
Term:Field
Explanation:Each plugin presents data from one or more data sources. Each found, read, calculated value corresponds to a field.attribute tuple
Synonym:Data source
Term:FQN
Explanation:A Fully Qualified Name used to address a specific group, node, service or data source.
Synonym:Fully Qualified Name
Term:Attribute
Explanation:Description found in output from plugins, both general (global) to the plugin and also specific to each field
Synonym:N/A
Term:Directive
Explanation:Statements used in configuration files like munin.conf, munin-node.conf and plugin configuration directory (/etc/munin/plugin-conf.d/).
Synonym:N/A
Term:Environment variable
Explanation:Set up by munin-node, used to control plugin behaviour, found in plugin configuration directory (/etc/munin/plugin-conf.d/)
Synonym:N/A
Term:Global (plugin) attributes
Explanation:Used in the global context in a plugin’s configuration output. NB: The attribute is considered “global” only to the plugin (and the node) and only when executed.
Synonym:
Term:Datasource-specific plugin attributes
Explanation:Used in the datasource-specific context in a plugin’s output.
Synonym:N/A
Term:Node-level directives
Explanation:Used in munin.conf.
Synonym:
Term:Group-level directives
Explanation:Used in munin.conf.
Synonym:
Term:Field-level directives
Explanation:Used in munin.conf.
Synonym:

Examples

To shed some light on the nomenclature, consider the examples below:

Global plugin attribute

Global plugin attributes are in the plugins output when run with the config argument. The full list of these attributes is found on the protocol config page. This output does not configure the plugin, it configures the plugins graph.

graph_title Load average
----------- ------------
     |           `------ value
     `------------------ attribute

Datasource specific plugin attribute

These are found both in the config output of a plugin and in the normal readings of a plugin. A plugin may provide data from one or more data sources. Each data source needs its own set of field.attribute tuples to define how the data source should be presented.

load.warning 100
---- ------- ---
  |     |     `- value
  |     `------- one of several attributes used in config output
  `------------- field

load.value 54
---- ----- --
  |    |    `- value
  |    `------ only attribute when getting values from a plugin
  `----------- field

Configuration files

This one is from the global section of munin.conf:

dbdir       /var/lib/munin/
-----       ---------------
  |                `--------- value
  `-------------------------- global directive

And then one from the node level section:

[foo.example.org]
  address localhost
  ------- ---------
     |        `----- value
     `-------------- node level directive

The relation between directives and attributes

Attributes
A plugin has a given set of data sources, and the data sources present themselves through a defined set of field.attributes with corresponding values. From a Munin administrator’s point of view, these (the names of the fields and attributes) should not be changed as they are part of how the plugins work.
Directives
The configuration files, however, are the administrator’s domain. Here, the administrator may – through directives – control the plugins’ behavior and even override the plugin’s attributes if so desired. As such, directives (in configuration files) may override attributes (in plugins).

The distinction between attributes and directives defines an easily understandable separation between how the (for many people) shrink-wrapped plugins and the editable configuration files.