Enabling munin node plug-ins on Debian

Munin uses plug-ins to determine what data is gathered and reported. It includes several plug-ins for the types of data most people would be interested in, but not all of those plug-ins are enabled on a fresh installation.
What are plug-ins?

When a munin node gathers data about a slice so it can be graphed, the node reads instructions from files called "plug-ins" to determine what information to collect. Several plug-ins are installed with munin but not all of them are used by default. Fortunately a munin node installation includes a command that lets you see what plug-ins are active and can help you decide which others to enable.

The munin-node-configure command

The "munin-node-configure" command can list the status of installed munin plug-ins, suggest which to enable, and provide a shell script that will automate enabling the appropriate plug-ins. Using this command isn't the only way to perform these tasks, but it's convenient and easy to use. Easy is good.

Listing installed plug-ins

To see which plug-ins are installed on a munin node, log into it and run the "munin-node-configure" command by itself:

$ sudo /usr/sbin/munin-node-configure
Plugin | Used | Extra information
—— | —- | —————–
acpi | no |
apache_accesses | no |
apache_processes | no |
apache_volume | no |
apt | no |
apt_all | no |
courier_mta_mailqueue | no |
courier_mta_mailstats | no |
courier_mta_mailvolume | no |
cps_ | no |
cpu | yes |
cupsys_pages | no |
df | yes |
df_abs | no |
df_inode | yes |
entropy | yes |
exim_mailqueue | yes |
exim_mailstats | yes |
forks | yes |
fw_conntrack | no |
…

The output is longer than that, but that's generally what you'll see — the plug-ins with "yes" next to them are enabled, the ones with "no" next to them are installed but disabled.

Deciding what to enable

To help you decide whether you want to enable any other munin plug-ins, run munin-node-configure with the "–suggest" option:

$ sudo /usr/sbin/munin-node-configure –suggest
Plugin | Used | Suggestions
—— | —- | ———–
acpi | no | [ACPI program not found]
apache_accesses | no | [LWP::UserAgent not found]
apache_processes | no | [LWP::UserAgent not found]
apache_volume | no | [LWP::UserAgent not found]
courier_mta_mailqueue | no | [spooldir not found]
courier_mta_mailstats | no | [could not find executable]
courier_mta_mailvolume | no | [could not find executable]
cupsys_pages | no | [could not find logdir]
hddtemp_smartctl | no | [smartctl not found]
if_ | yes |
if_err_ | yes |
ip_ | no |
mysql_isam_space_ | no |
nfs_client | no | [no /proc/net/rpc/nfs]
nfsd | no | [no /proc/net/rpc/nfsd]
ntp_ | no |
postfix_mailqueue | no | yes
postfix_mailvolume | no | yes
ps_ | no |
sendmail_mailqueue | no |
sendmail_mailstats | no | [no mailstats command]
sendmail_mailtraffic | no |
smart_ | no |
squid_cache | no | [could not connect: Connection refused]
squid_requests | no | [could not connect: Connection refused]
squid_traffic | no | [could not connect: Connection refused]

If your output includes any error messages at the end or complaints about "junk output", don't worry. That just means a plug-in was queried that didn't give a proper response, it doesn't affect munin's operation.

Note that the output with "–suggest" is much shorter than the complete list of installed plug-ins. When you ask munin-node-configure for its suggestions, it only lists plug-ins that are written to respond to that query and also omits most plug-ins that are already installed.

Each plug-in name is followed by a "yes" or "no" indicating whether or not it's currently enabled. The last column might contain a suggestion regarding a plug-in's status. A "yes" suggestion indicates that a plug-in is currently supported by your system and can be enabled without making changes (like the postfix plug-ins in the example above). Other entries in the "Suggestions" column can offer details about issues that need to be corrected before enabling a given plug-in.

Example in-depth: Apache plug-ins

In the example above, the suggestion for the apache monitor plug-ins includes:

[LWP::UserAgent not found]

It's not the most helpful suggestion you're likely to come across, granted, but with a little research it might make more sense. Fortunately we can skip the research in this case and get right down to what it means: Munin is actually a collection of scripts written in a language called Perl, and "LWP::UserAgent" is a Perl library. So the fact that LWP::UserAgent wasn't found means that particular Perl library isn't installed on our example slice.

To fix that problem we'll install the package that includes the LWP::UserAgent library:

sudo aptitude install libwww-perl

Once the installation completes, we run munin-node-configure again:

$ sudo /usr/sbin/munin-node-configure –suggest
Plugin | Used | Suggestions
—— | —- | ———–
…
apache_accesses | no | [no apache server-status or ExtendedStatus missing on ports 80]
apache_processes | no | yes
apache_volume | no | [no apache server-status or ExtendedStatus missing on ports 80]
…

Progress! We could enable the apache process monitor now, but munin still can't see details like the number of accesses apache is handling at a given point in time. This new error message might also require a bit of research to interpret, but to again save you time: The problem is that munin gets information about apache's activity by querying apache's status page, and the information it wants is only on that page if the "ExtendedStatus" setting is "on" in apache's configuration.

If you want to enable munin's apache monitoring, don't fret. You probably just need to add "ExtendedStatus on" to your apache server configuration and restart apache. If that doesn't work, or if you want more details, you'll need to read up on apache's "mod_status" module. We have an article detailing how to enable mod_status and how to read its output here.

Once you've ensured that apache's mod_status module is enabled and ExtendedStatus is turned on, you can run munin-node-configure yet again:

$ sudo /usr/sbin/munin-node-configure –suggest
Plugin | Used | Suggestions
—— | —- | ———–
…
apache_accesses | no | yes
apache_processes | no | yes
apache_volume | no | yes
…

That's more like it.

Enabling suggested plug-ins

So you've gone to a mess of trouble getting to the point where munin has no reservations about running the plug-ins you want. Now to actually enable them.

We could go into file locations and making symlinks and such, but let's opt for some automation instead. Take a look at the output from running munin-node-configure with the "–shell" option:

$ sudo /usr/sbin/munin-node-configure –shell
ln -s /usr/share/munin/plugins/apache_accesses /etc/munin/plugins/apache_accesses
ln -s /usr/share/munin/plugins/apache_processes /etc/munin/plugins/apache_processes
ln -s /usr/share/munin/plugins/apache_volume /etc/munin/plugins/apache_volume
ln -s /usr/share/munin/plugins/postfix_mailqueue /etc/munin/plugins/postfix_mailqueue
ln -s /usr/share/munin/plugins/postfix_mailvolume /etc/munin/plugins/postfix_mailvolume

If that looks like a bunch of shell commands for making symlinks, that's because it is a bunch of shell commands for making symlinks. Specifically, they're symlinks that tell munin to enable the plug-ins they're linking to. In the above example, the plug-ins for monitoring apache and postfix would be enabled.

Before you copy and paste, though, let's work a little shell magic to turn the above into a one-line command. Run this command on your munin node:

sudo /usr/sbin/munin-node-configure –shell | sudo sh

That's just like the command we ran to get a list of shell commands, but with a little bit tacked onto the end. The "|" character is known as a "pipe" in the unix shell. The "sh" after it (also run with sudo) is the command to run a basic Bourne shell. Combine the two, and in plain English it means, "take the output of the command before the pipe, and run it in a shell." Or, a plainer English summary: "Make those symlinks for me."

Indeed, once you run munin-node-configure with the –shell option and pipe it to sh, you can see how the suggestions change:

$ sudo /usr/sbin/munin-node-configure –suggest
Plugin | Used | Suggestions
—— | —- | ———–
acpi | no | [ACPI program not found]
courier_mta_mailqueue | no | [spooldir not found]
courier_mta_mailstats | no | [could not find executable]
courier_mta_mailvolume | no | [could not find executable]
cupsys_pages | no | [could not find logdir]
hddtemp_smartctl | no | [smartctl not found]
if_ | yes |
if_err_ | yes |
ip_ | no |
mysql_isam_space_ | no |
nfs_client | no | [no /proc/net/rpc/nfs]
nfsd | no | [no /proc/net/rpc/nfsd]
ntp_ | no |
ps_ | no |
sendmail_mailqueue | no |
sendmail_mailstats | no | [no mailstats command]
sendmail_mailtraffic | no |
smart_ | no |
squid_cache | no | [could not connect: Connection refused]
squid_requests | no | [could not connect: Connection refused]
squid_traffic | no | [could not connect: Connection refused]

Now that the apache and postfix monitors have been enabled they aren't listed as suggestions anymore. If you were to wait a few minutes to let the munin master run and query this node, you would see graphs for apache and postfix added to the node's reports.

Plug-in locations

In case you have trouble with the munin-node-configure command, or if you don't trust its automation, or you simply want to look more closely at the plug-ins (some do contain useful information in their comments), you can find the plug-in files here:

/usr/share/munin/plugins

Enabling a plug-in is just a matter of making a symlink from the original plug-in file to the munin node's active plug-in directory, which is here:

/etc/munin/plugins

Similarly, you can disable a plug-in by removing its symlink from the node's active plug-in directory.

Summary

The munin-node-configure command is a pretty handy way to check on your munin plug-ins and figure out what needs to be done in order to enable more. You should now be able to look over the list of plug-ins and decide which ones you'd like to see enabled on your munin reports. Bear in mind, however, that each munin node has to be configured individually. If you have more than one node, you'll have to enable a new plug-in on all nodes you want using it (not just the one running the munin master).

Fortunately once you've been through all the wordy details above, you'll know what the commands are and what to do with their output. They boil down to logging onto each node and running:

sudo /usr/sbin/munin-node-configure –suggest

Then fixing the issues for any plug-ins you want enabled, and then running:

sudo /usr/sbin/munin-node-configure –shell | sudo sh

And waiting for munin's reports to update. Piece of cake.

The next article in this series will discuss some advanced topics for munin, including installing plug-ins from munin's online repository and customizing the organization of the host tree on your report page.

Src:

http://articles.slicehost.com/2010/4/9/enabling-munin-node-plug-ins-on-debian

http://articles.slicehost.com/2010/4/9/enabling-munin-node-plug-ins-on-ubuntu