munin.conf(5)

NAME

munin.conf - Munin configuration file

DESCRIPTION

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.projects.linpro.no/wiki/munin.conf>

The format of the file is simple. A minimal configuration looks something like:: dbdir /var/lib/munin
logdir /var/log/munin
htmldir /var/www/munin
rundir /var/run/munin
tmpldir /etc/munin/templates/; [machine1.your.dom]
address localhost
The default location of munin.conf is @@CONFDIR@@/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 @@DBDIR@@/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.

GLOBAL DIRECTIVES

These directives should appear in munin.conf before any host or group definitions.

dbdir <path>: Directory for generated database files. Required.
logdir <path>: Directory for log files. Required.
htmldir <path>: Directory for HTML pages and graphs. Required.
rundir <path>: Directory for files tracking munin's current running state.
Required.
tmpldir <path>: Directory for templates used to generate HTML pages. Required.
fork <value>: This directive determines whether munin-update fork when gathering information from nodes. Possible values are "yes" and "no".
Default is "yes". If you set it to "no" munin-update will collect data from the nodes in sequence rather than in paralell and this
will take considerably more time. Affects: munin-update.
graph_data_size <value>: This directive sets the resolution of the RRD files that are created. Possible values are "normal" and "huge". Default is "normal". Affects: munin-update.
graph_strategy <value>: This directive can be "cron" or "cgi". This determines whether
graphs will be produced when the cron job is run or whether they
will be generated by the CGI script (Links this CGI script will be added to the HTML pages if "cgi" is selected). This is one of several steps required to enable CGI graphing, see
<http://munin.projects.linpro.no/wiki/CgiHowto> for more details.
Default is "cron". Affects: munin-graph and munin-html.
local_address <value>: The local address to connect any node from. This can be overriden by a group or global directive. Munin will attempt to guess an
appropriate interface.
max_processes <value>: This directive specifies the maximum number of processes to be used for gathering information from nodes. If left blank, munin will
use as many processes as necessary. Affects: munin-update.
tls <value>: Can have four values. "paranoid", "enabled", "auto", and "disabled". Paranoid and enabled require a TLS connection, auto will
attempt a connection but continue on failure, and disabled will not attempt one at all. If the perl module Net::SSLeay is available
the setting is "auto". If the module isn't available it's "off".
If munin is not propperly configured for TLS and Net::SSLeay is
available munin-update has been known to fail mysteriously. If you see data dropouts (gaps in graphs) please try to disable TLS.
Affects: munin-update.
tls_verify_certificate <value>: This directive can be "yes" or "no". It determines if the remote
certificate needs to be signed by a CA that is known locally.
Default is "no". Affects: munin-update.
tls_private_key <value>: This directive sets the location of the private key to be used for TLS. Default is @@CONFDIR@@/munin.pem. The private key and certificate can be stored in the same file. Affects: munin-update.
tls_certificate <value>: This directive sets the location of the TLS certificate to be used for TLS. Default is @@CONFDIR@@/munin.pem. The private key and
certificate can be stored in the same file. Affects: munin-update.
tls_ca_certificate <value>: This directive sets the CA certificate to be used to verify the
node's certificate, if tls_verify_certificate is set to "yes".
Default is @@CONFDIR@@/cacert.pem. Affects: munin-update.
tls-verify_depth <value>: This directive sets how many signings up a chain of signatures TLS is willing to go to reach a known, trusted CA when verifying a certificate. Default is 5. Affects: munin-update.
FIXME: This section MAY be complete, it may be missing a directive or two.

HOST DEFINITIONS

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.

NODE DIRECTIVES

These are directives that can follow a node definition and will apply
only to that node.

address <value>: The IP address of the node. Required.
local_address <value>: The local address to connect to the node from. This overrides a
group or global directive.
FIXME: This section is incomplete.

PLUGIN DIRECTIVES

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.

FIXME: This section is (obviously) incomplete.

FIELD DIRECTIVES

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.

graph_height <value>: The graph height for a specific service. Default is 175. Affects: munin-graph.
graph_width <value>: The graph width for a specific service. Default is 400. Affects: munin-graph.
warning <value>: The value at which munin-limits will mark the service as being in a warning state. Value can be a single number to specify a limit
that must be passed or they can be a comma separated pair of numbers defining a valid range of values. Affects: munin-limits.
critical <value>: The value at which munin-limits will mark the service as being in a critical state. Value can be a single number to specify a limit
that must be passed or they can be a comma separated pair of numbers defining a valid range of values Affects: munin-limits.
FIXME: This section is incomplete.

EXAMPLES

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.

EXAMPLE 1

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.

EXAMPLE 2

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

AUTHORS

Jimmy Olsen, Audun Ytterdal, Brian de Wolf, Nicolai Langfeldt

COPYRIGHT

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

docs.sk

comprehensive documentation repository

Most Viewed