Munin—the Raven Reports

Long-term monitoring with Munin is not restricted to system parameters. Why not monitor data of personal interest or data of interest to your colleagues?
First Contact via Telnet

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
Connected to localhost.localdomain.
Escape character is '^]'.
$ munin node at
$ Unknown command. Try list, nodes, config, fetch, version or quit
  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.

Wild-Card and autoconf Plugins

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.

Fly Away

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:



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


Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

Upcoming Webinar
8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th
Moderated by Linux Journal Contributor Mike Diehl

Sign up now

Sponsored by Skybot