With the latest versions of munin-async, this article is out of date. Instructions for munin 2.0.17 on Ubuntu 12.04 are here
When using munin, one often runs into one of two problems:
With version 2.0, the designers of munin have started addressing those problems. Today we look at one part of that solution, munin-async. Note that I am using the packages from Debian experimental. Your experience on other OSs may vary. You can tell that munin-async in version 2.0.1 is not quite ready for prime time yet. Here are the steps I needed to take in order for the client to collect munin-async data from the various servers:
The munin-async debian package contains both the client AND the server scripts for async work. This is not consistent, since previously all the data fetching scripts were in the munin package, and all the data serving scripts were in the munin-node package. It also means that you have to install munin-async (creating the munin-async user, with it’s own entry in passwd file and it’s shell set to /bin/bash) on the server, not just on the clients. I don’t like leaving that open. (on remote machine and on server)
apt-get install munin-async
If your distro isn’t including munin-2.0.1 packages yet, you should download them from debian experimental, and install them with
dpkg --install --force-overwrite munin-async_2.0.1-1_all.deb munin-common_2.0.1-1_all.deb munin-node_2.0.1-1_all.deb munin-plugins-*
The force-overwrite is needed due to this error message:
dpkg: error processing munin-common_2.0.1-1_all.deb (--install): trying to overwrite '/usr/share/munin/plugins/plugin.sh' which is also in package munin-node 0:1.4.4-1ubuntu1
The /etc/init.d/munin-async file is looking for a script called munin-async-server instead of munin-asyncd
--- /etc/init.d/munin-async.orig 2012-07-15 01:10:56.000000000 -0700 +++ /etc/init.d/munin-async 2012-07-15 01:12:23.000000000 -0700 @@ -16,7 +16,7 @@ # PATH should only include /usr/* if it runs after the mountnfs.sh script PATH=/sbin:/usr/sbin:/bin:/usr/bin DESC="Munin asynchronous server" -NAME=munin-async-server +NAME=munin-asyncd DAEMON=/usr/share/munin/$NAME DAEMON_ARGS="" PIDFILE=/var/run/munin/$NAME.pid
(on remote machine) service munin-async start
Change the shell of the munin user to bash so you can do these changes as the munin user:
vipw su - munin cd /var/lib/munin mkdir .ssh cd .ssh ssh-keygen
(tell ssh-keygen to create a key with an empty passphrase and place it in /var/lib/munin/.ssh) (on the remote machine)
(on the server)
scp /var/lib/munin/.ssh/id_rsa.pub firstname.lastname@example.org:/var/lib/munin-async/.ssh/authorized_keys chown -R munin:munin /var/lib/munin/.ssh
(on the remote machine)
chown -R munin-async:munin-async /var/lib/munin-async
(on the server, test the connection)
Note that you need to check the connection for EVERY host from which you intend to collect data in the async manner. munin is NOThandling this dialogue:
The authenticity of host 'example.net (2600:more:fool:you:f9b)' can't be established. RSA key fingerprint is 61:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'example.net,2600:moore:fool:you:f9b' (RSA) to the list of known hosts.
So you need to log in “by hand” first, from the user munin, in order to record the key. Or you need to copy the key from antoher known_hosts file, which may be tricky. Now change the shell of munin back to /bin/false, for security.
(or, as I prefer to do it, in /etc/munin/munin-conf.d/hostlist.conf ).
[async.my-machine.net] address ssh://email@example.com /usr/share/munin/munin-async --spooldir /var/lib/munin/spool --spoolfetch use_node_name yes
I am using async in the definition name merely so that I can compare the data from the two collection methods.
To prevent your monitored server being compromised if someone manages to break into your munin collection server, you should edit the /var/lib/munin-async/.ssh/authorized_keys file and add
no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="/usr/share/munin/munin-async --spooldir /var/lib/munin/spool --spoolfetch"
to the beginningof the relevant line.
When you add a plugin, it won’t be visible unless you first restart munin-node and THENmunin-async.
If you haven’t logged in to the host “by hand” or added it’s keys to known_hosts some other way, the fetch will fail. The only log in the munin-update file will say something like
Socket read from async.example.net failed. Terminating process. at /usr/share/perl5/Munin/Master/UpdateWorker.pm line ...
Another possible cause of mysterious failure to fetch data from the remote host (that does not give a clear error message) is munin-asyncd not running on the target server, or having no prefetched data yet.
Balint Deaksuggested in a post on the munin-users mailing list: What I would add to this is that if you have many hosts, or hosts are added on a daily basis, it may be annoying to always remember to log in to each new box and say “yes” at the prompt.