Readers of this little blog may know I’ve spent some time to have a munin setup that was tweaked to be optimized. But I’ve reached a point where my knowledge did not suffice to balance the design problems of munin. This is not a rant, I just say that when your infrastructure reaches a certain size munin reaches its limits. The pull based model, the graph generation (don’t tell me about the CGI graph, this thing never worked as expected) overloaded my management box. Talking with other peoples brought collectd to my attention so I gave it a try.

At $WORK I started using Nginx a while ago, first as a front end to my mongrel instances for puppet. Recently I began to use it for one of its most know features : reverse proxy (and caching too). Of course this work had to be puppetized !

Disclaimer : this work is mostly based upon DavidS work, available on his git repo. In the scope of my work I needed to have munin support for freeBSD & Solaris. I also wrote a class for snmp_plugins & custom plugins. Some things are quite dependant from my infrastructure, like munin.conf generation script but it can easily be adapted to yours, by extracting data from your CMDB.

Et voila, mon premier plugin pour munin ! C’est un plugin solaris only (utilisation du module Kstat oblige) qui permet de monitorer les I/O sur les pools ZFS. Je n’ai pas trouvé comment faire des stats par pool (comprendre à la “zpool iostat”) et si quelqu’un a une astuce à ce niveau là, je suis preneur. En attendant voici le fichier.

Tips rapide : pour accélerer la collecte des données avec munin-update, ajoutez dans /etc/munin/munin.conf du master :

Au boulot j’ai remplacé cacti par munin. Munin c’est choupi, la conf est en flat file mais ça a deux défauts, ou un selon le point de vue : le munin-cgi-graph est tout simplement moisi car d’une lenteur sans nom, et générer les images lors du poll c’est long. Sauf quand on tombe sur ce petit hack convivial qui permet de lancer en parallèle la génération pour X nodes. Malheureusement, l’exemple donné en lien n’est valable que pour la version du trunk (au moment ou j’écris ceci) et pas pour la version 1.2.6 livrée avec lenny. J’ai donc modifié mon munin-graph en “portant” le hack disponible. Résultat : 2min30s au lieu de 9min pour la génération de 80 machines (dont certaines avec beaucoup d’infos)