Munin—the Raven Reports

Installing the Munin node from a distribution package usually will activate a range of plugins that can be configured automatically. In this case, Telnetting to port 4949 of the node machine will give you an overview:

$ telnet localhost 4949
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
$ munin node at extrablatt.trish.de
help
$ Unknown command. Try list, nodes, config, fetch, version or quit
list
  open_inodes         if_err_eth0  irqstats
  entropy             processes    postfix_mailqueue
  if_eth0 df          netstat      interrupts
  swap                load         cpu
  df_inode            if_eth1      if_err_eth1
  postfix_mailvolume  forks        iostat
  open_files          memory       vmstat

fetch open_inodes
used.value 67839
max.value 68094
.
Connection closed by foreign host.

The list command returns the names of all activated plugins on this particular node. The fetch command, with the name of the plugin you want to run as an argument, returns the values of the parameters (in this case, used and max) the plugin monitors. As long as you don't change the timeout directive in munin-node.conf (for example, to 20 seconds: timeout 20), you have to be fast to type in your commands, as the dæmon will close the connection after a default of ten seconds.

If the list command does not list any plugins (which might be the case after a source code installation), you need to activate them first. To do this, symlink them into the plugins directory (/etc/munin/plugins on Debian/Ubuntu) on the node machine and restart the dæmon using its init script. The command munin-node-configure --shell will show you link commands for some of the plugins provided with the distribution.

There are two types of plugins. For plugins that are independent of additional parameters, the link name equals the plugin name. Sometimes, however, a plugin can monitor several items of the same type, for example, several network interfaces, such as eth0 and eth1.

In this case, it would be stupid to hard-code the interface name into the plugin. Instead, you provide this information in the name of the symlink. Plugins capable of this are called wild-card plugins, and their names end with an underscore. If you, for example, want to monitor the eth0 interface with the wild-card plugin if_, the link pointing to the if_ plugin would be if_eth0:

$ ls -al /etc/munin/plugins/if_eth*
lrwxrwxrwx 1 root root 28 2008-06-27 23:53
 ↪/etc/munin/plugins/if_eth0 -> /usr/share/munin/plugins/if_

lrwxrwxrwx 1 root root 28 2008-06-27 23:53
 ↪/etc/munin/plugins/if_eth1 -> /usr/share/munin/plugins/if_

Almost all plugins provided with the Munin distribution belong to the plugin family auto and can be run with the autoconf argument. In this case, they check whether they are able to provide meaningful results. For example, running a monitoring plugin for the Exim MTA makes sense only if you're running the Exim mail server. If your system does not fulfill the prerequisites to run a specific autoconf-enabled plugin, it will provide you with meaningful hints:

$ /usr/share/munin/plugins/exim_mailqueue autoconf
no (exim not found)

To get an overview of all preinstalled plugins that implement the autoconf method, simply run:

# munin-node-configure --suggest
Plugin                     | Used | Suggestions
------                     | ---- | -----------
[...]
exim_mailqueue             | no   | [exim not found]
[...]
if_                        | yes  |
[...]

If you want to share your own plugins with others, for example, at the Munin Exchange platform, we recommend you have a look at the officially provided plugins to see how the autoconf method is implemented. But, to get started with your own plugins, don't complicate your life unnecessarily.

As an example, let's monitor the departures at Munich Airport in five-minute intervals, as that is the default for the Munin cron job. The departure timetable is available from a Web page, and we can use a shell script and the Links text browser to dump it into a temporary file:

#!/bin/sh

SITE=http://www.munich-airport.de
DEP_URL=$SITE/en/consumer/fluginfo/abflug/index.jsp?viewType=t
TMP_FILE=/tmp/.muc_flights

links -dump $DEP_URL > $TMP_FILE

This file now contains lines like these:

[...]
 [ LH 3464 ] [ Budapest ]   [ 21:30 ] [  ]   [ T2 ]   [ departed ]
 [ LH  726 ] [ Shanghai ]   [ 21:30 ] [  ]   [ T2 ]   [ boarding ]
[...]

The Web page lists five flight states: calling, boarding, departed, planned (which means delayed) and cancelled. We will count them for the current time interval and return them on the standard output, like this:

calling.value 0
boarding.value 1
departed.value 1
planned.value 0
cancelled.value 0

To determine the current time, we could use the following date command:

$ date +%H:%M
21:30