| MUNIN.CONF(5) | Munin Documentation | MUNIN.CONF(5) |
munin.conf - Munin configuration file
Munin is a group of programs to gather data from hosts, graph them, create html-pages, and optionally warn contacts about any off-limit values.
The hosts are divided into three groups: One master (could be more, but Munin is not cluster aware so they'll likely be independent). The master contacts a number of machines running munin-node, these are called nodes. Each node has data from one or more hosts that is monitored by Munin.
munin.conf is the configuration file for the Munin master server. The programs using it are munin-update, munin-graph, munin-limits and munin-html. There is also quite extensive documentation of this file at <http://munin-monitoring.org/wiki/munin.conf>
The format of the file is simple. A minimal configuration looks something like:
[machine1.your.dom]
address localhost
The default location of munin.conf is /etc/munin/munin.conf. If your placement deviates from this norm, use the "--config <file>"-option when running the munin-* programs.
Munin-update will expand all node-entries in this file, and save them to /var/lib/munin/datafile, which is used by all programs in the package together with this file.
Any directives in this file will override directives of the same name in datafile. E.g., if you want to change the title of the "load"-graph in the above minimum configuration, you would modify the two bottom lines to:
[machine1.your.dom]
address localhost
load.graph_title Edited title of the load-graph
This will override the "graph_title" attribute of the "load" field/data series while keeping all the others at their default.
These directives should appear in munin.conf before any host or group definitions.
You should probably not increase this value, unless all nodes are using ssh with munin-async. Otherwise you may expecience gaps in graphs, if "munin-update" takes longer, than the default period (5 minutes).
Munin-async can retrieve historical data, and if there is a big backlog, we could need more time depending on the size of the data generated by the plugin and the size of the backlog. This would also mean that we wouldn't care to skip an update. So munin-async will get more time to retrieve the backlog data. Afterwards new data will incrementally be fetched. Default is 240. Affects: munin-update
If you need per-host ssh configuration, add these to ~/munin/.ssh/config
The current default is "disabled" because "auto" is broken. "Auto" causes bad interaction between munin-update and munin-node if the node is unprepared to go to TLS.
If you see data dropouts (gaps in graphs) please try to disable TLS. Affects: munin-update.
Subject Name: /C=c/ST=st/L=l/O=o/OU=ou/CN=cn/emailAddress=email
Issuer Name: /C=c/ST=st/O=o/OU=ou/CN=cn/emailAddress=email
So, for example, one could match the subject distinguished name by the directive:
tls_match Subject Name: /C=c/ST=st/L=l/O=o/OU=ou/CN=cn/emailAddress=email
Note that the fields are dumped in the order they appear in the certificate. It's best to view the dump of the certificate by running munin-update in debug mode and reviewing the logs.
Unfortunately, due to the limited functionality of the SSL module in use, it is not possible to provide finer-grained filtering. By default this value is not defined. Affects: munin-update.
Host definitions can have several types. In all forms, the definition is used to generate the host name and group for the host, and the following lines define its directives. All following directives apply to that node until another node definition or EOF. Note that when defining a nodename it is vital that you use a standard DNS name, as in, one that uses only a-z, '-', and '.'. While other characters can be used in a DNS name, it is against the RFC, and Munin uses the other characters as delimiters. If they appear in nodenames, unexpected behavior may occur.
The simplest node definition defines the section for a new node by simply wrapping the DNS name of the node in brackets, e.g. "[machine1.your.dom]". This will add the node "machine1.your.dom" to the group "your.dom".
The next form of definition is used to define the node and group independently. It follows the form "[your.dom;machine1.sub.your.dom]". This adds the node "machine1.sub.your.dom" to the group "your.dom". This can be useful if you have machines you want to put together as a group that are under different domains (as in the given example). This can also solve a problem if your machine is "machine1.com", where having a group of "com" makes little sense.
Multiple groups can be specified by adding more "groupname;"s, e.g. "[servers;local;mail;mail.foo.net]", if you need a more hierarchical structure.
These are directives that can follow a node definition and will apply only to that node.
These directives should appear after a node definition and are of the form "plugin.directive <value>". Using these directives you can override various directives for a plugin, such as its contacts, and can also be used to create graphs containing data from other plugins.
These directives should appear after a node definition and are of the form "plugin.field <value>". Using these directives you can override values originally set by plugins on the nodes, such as warning and critical levels or graph names.
On all the examples below, all the 'top-level' parameters (dbdir, logdir, htmldir, tmpldir) are not present. They are only skipped for brevity - they are needed.
An example with three servers on two domains:
[machine1.one.dom]
address machine1.one.dom
[machine2.one.dom]
address 10.33.32.123
[machine3.two.dom]
address localhost
This will appear as two groups (one.dom and two.dom), having respectively two and one node.
Summarize the 'load'-graphs of the two servers in one.dom, in a 'total load'-graph.
[one.dom;Totals]
update no
load.graph_title Total load
load.sum_load.label load
load.sum_load.special_stack machine1=machine1.one.dom:load.load machine2=machine2.one.dom:load.load
Jimmy Olsen, Audun Ytterdal, Brian de Wolf, Nicolai Langfeldt
Copyright (C) 2002-2008 Audun Ytterdal, Jimmy Olsen, Nicolai Langfeldt, Linpro AS and others.
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
This program is released under the GNU General Public License
For more information, see the man pages of the individual munin-* programs or the Munin homepage <http://munin-monitoring.org/>.
| 2023-03-21 | 2.0.73 |