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 behaviour, we need a common nomenclature.

If you have comments to this page please post to the munin-users mailinglist.

Terms

Term	Explanation	Also referred to as...
Munin master	The central host/server where Munin gathers all data to. This machine runs munin-cron	Munin master-server
Munin node	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.	In SNMP this might be called an agent
Plugin	Each Munin node handles one or more plugins to monitor stuff on hosts	Service
Host	A machine monitored by Munin, maybe by proxy on a munin node (or via a snmp plugin)	N/A
Field(name)	Each plugin presents data from one or more data sources. Each found/read/calculated value corresponds to a field.attribute tuple.	Data source, {name}
Attribute	Description found in output from plugins, both general (global) to the plugin and also specific to each field	N/A
Directive	Statements used in configuration files like munin.conf, munin-node.conf and plugin configuration directory (/etc/munin/plugin-conf.d/).	N/A
Environment variable	Set up by munin-node, used to control plugin behaviour, found in plugin configuration directory (/etc/munin/plugin-conf.d/)	N/A
Global (plugin) attributes	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.	N/A
Datasource-specific plugin attributes	Used in the datasource-specific context in a plugin's output.	N/A
Node-level directives	Used in munin.conf.
Group-level directives	Used in munin.conf.
Field-level directives	Used in munin.conf.

Plugin example output

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 outout 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

Component relations

• 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

The relation between directives and 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.

The configuration files, however, are the administrator's domain. Here, the administrator may -- through directives -- control the plugins' behaviour 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.