J’avais besoin d’un peu de monitoring sur mes serveurs auto-hébergés. Quelque-chose de simple et léger qui me permette de surveiller et historiser l’activité : CPU, disque, réseau etc.

Munin me semble bien adapté à ça : il fait des graphiques par jour/semaine/mois/année de tout un tas de métriques système (mais aussi serveur http, bases de données etc). Et il permet de le faire aussi pour des serveurs distants, et d’envoyer des alertes quand certains seuils sont dépassés.

… sauf que j’ai eu plus de difficultés que je pensais à le mettre en œuvre. En particulier pour l’adapter à la faible puissance de mes machines.

Architecture

Une machine maître pilote la recherche périodique des données sur x machines (les noeuds), puis les stocke, génère des graphes, et envoie des mails d’avertissements si nécessaire.

Source : https://munin.readthedocs.org/en/latest/tutorial/getting-started.html

Munin est plutôt positionné sur de la métrologie (construire et mettre à disposition des métriques) que sur de la supervision (vérification de l’état de serveurs ou services). Cf http://decrypt.ysance.com/2011/02/comparatif-outils-monitoring-metrologie-supervision-2-zabbix-centreon-nagios-cacti-munin/

Les plugins

Les métriques sont fournies par des plugins. Munin fournit en standard un grand nombre de plugins, capables de collecter des métriques très pertinentes sur plein de services.

A mon sens, c’est la principale force du produit.

D’autant que Munin est aussi capable de détecter lui-même quels plugins sont pertinents sur votre machine.

De plus, il existe plein de plugins supplémentaires fournis par la communauté (qu’il faut ajouter soi-même) : https://github.com/munin-monitoring/contrib/tree/master/plugins

Les graphiques

Munin produit en standard des pages HTML statiques, avec des graphiques par machine, plugin, et période de mesure.

Pour vous faire un avis : http://demo.munin-monitoring.org/

(Cette démo ne montre pas les plugins sur les bases de données, qui sont pourtant très complets, en tous cas sur MySQL et PostgreSQL)

Installation

Il y a des packages tout prêts pour les distributions les plus classiques.

Sur Debian, c’est le package « munin » pour le serveur maître, et « munin-node » pour chaque nœud (dans mon cas, le maître est aussi un nœud lui-même).

Utilisation de la version backport sur Debian Wheezy

Sur les dépôts non-backport, la version fournie avec Debian Wheezy est la 2.0.3. Le dépôt backport fournit la version 2.0.25, qui apporte pas mal de correctifs.

Finalement, je ne suis pas certain que c’était vraiment nécessaire.

Comme je ne voulais pas activer le dépôt backport pour tous les packages, j’ai installé manuellement les packages :

• télécharger les fichiers .deb depuis https://packages.debian.org/wheezy-backports/munin , https://packages.debian.org/wheezy-backports/munin-node , https://packages.debian.org/wheezy-backports/munin-common , https://packages.debian.org/wheezy-backports/munin-plugins-core , et https://packages.debian.org/wheezy-backports/munin-plugins-extra
• installer les packages munin-node (et munin pour le serveur principal) dans leur version standard, simplement pour que cela installe toutes les dépendances
• Puis supprimer ces packages : apt-get remove –purge « munin* »
• Et supprimer tout ce qu’il pourrait rester de configuration/données :

  rm -rf /etc/munin
  rm -rf /var/lib/munin
  rm -rf /var/lib/munin-node
  rm -rf /var/cache/munin

• puis faire un dpkg -i sur les packages munin-*.deb que vous avez téléchargés

Paramétrage

Toute la configuration se fait dans /etc/munin/

Lors de l’installation de chaque nœud, Munin détecte ce qui est installé sur la machine, et active les plugins correspondant. Il s’agit simplement de liens symboliques de /usr/share/munin/plugins/ vers /etc/munin/plugins/

On peut donc en ajouter/enlever en jouant sur ces liens symboliques.

Munin est aussi capable de suggérer lesquels devraient fonctionner :

munin-node-configure --suggest

Puis de préparer les lignes de commande pour créer ces liens symboliques :

munin-node-configure --shell

Cas du plugin MySQL

Première chose à savoir : pour qu’il fonctionne, il faut que le package libcache-cache-perl soit installé (en plus de MySQL, bien sûr)

Deuxième chose à savoir : il y a une petite incompatibilité entre munin 2.0.x et mySQL>=5.5. C’est corrigé dans munin 2.1 mais, en attendant, le plus simple est de désactiver les 3 plugins qui posent problème (tous les autres fonctionnent), en supprimant les liens symboliques associés :

rm /etc/munin/plugins/mysql_replication
rm /etc/munin/plugins/mysql_innodb_io_pend
rm /etc/munin/plugins/mysql_innodb_insert_buf

Cas du plugin Apache

Pour que Apache puisse être monitoré par Munin, il faut qu’il soit accessible en localhost (sur le port 80, par défaut), sur une URL http://127.0.0.1/server-status.

C’est le cas sur une configuration Apache par défaut (module status activé par défaut), mais peut ne pas l’être suivant votre configuration. Dans mon cas, il a fallu que je crée un VirtualHost exprès pour ça.

Sur Debian, il faut aussi installer le paquet libwww-perl.

Exposition des graphiques par Apache

Lors de l’installation, Munin ajoute lui-même un fichier de configuration pour Apache, dans /etc/munin/apache.conf, avec un lien symbolique dans /etc/apache2/conf.d

Par sécurité, l’accès est réservé à la machine locale, par défaut.

Pour autoriser l’accès à n’importe qui, il faut y mettre :

Allow from all

à chaque ligne commençant par Allow from.

Évidemment, je vous encourage ensuite à sécuriser l’accès d’une manière ou d’une autre.

Configuration avec un seul maître et plusieurs nœuds

Sur chaque nœud, il faut autoriser l’accès depuis le serveur maître, en modifiant le fichier /etc/munin/munin-node.conf : ajouter une ligne commençant par allow

Sur le serveur maître, on liste les nœuds à contacter dans /etc/munin/munin.conf

Avertissements par email

Il suffit dans /etc/munin/munin.conf de rajouter une ligne du type :

contact.email.command mail -s "Munin: ${var:graph_title} - ${var:host}" nom@domaine.tld

Avertissements par SMS (chez Free Mobile)

Comme on peut mettre n’importe quelle ligne de commande dans la syntaxe ci-dessus, on peut aussi envoyer des SMS avec l’API Free Mobile :

contact.sms.command wget --ca-certificate=/path/to/RapidSSLCABundle.pem -O /dev/null "https://smsapi.free-mobile.fr/sendmsg?user=12345678&pass=abcdefgh&msg=Munin : ${var:graph_title} - ${var:host} : warnings: ${var:wfields} - criticals: ${var:cfields} - unknowns: ${var:ufields}"

Pour des explications sur le paramètre ca-certificate, voir mon autre article sur l’envoi de SMS Free Mobile depuis Fail2ban.

Unité des graphiques

Par défaut, toutes les métriques sont affichées par seconde (ex : nombre de requêtes par seconde). Avec un serveur pas très chargé, ça donne des valeurs pas très parlantes.

Il est possible de changer ça dans /etc/munin/munin.conf , en passant la valeur de graph_period à minute (voire hour)

NB : ça n’a aucune influence sur la fréquence de la collecte : il s’agit uniquement d’avoir un affichage plus parlant.

Difficultés

Gestion des erreurs

S’il y a une erreur sur un nœud, cela annule l’envoi complet des données au serveur maître. Symptôme classique : les graphes sont mis à jour, mais sans données dedans.

Dans ce cas, il faut aller voir les fichiers de log de chaque noeud, dans /var/log/munin/munin-node.log et/ou le fichier de log de la mise à jour du maître, dans /var/log/munin/munin-update.log

J’aurais préféré l’affichage d’une erreur explicite dans les pages web générées, ou une alerte par email. Et j’aurais aussi préféré que ça ne bloque que les données du plugin concerné…

Limiter l’overhead sur les serveurs

Sur un serveur « classique », l’overhead n’est pas très important. Mais sur mes petites machines peu puissantes, il n’est pas négligeable.

Aux premiers essais, la machine maître n’avait pas le temps de terminer la collecte/génération des 3 machines avant la collecte suivante (toutes les 5 minutes par défaut). Il a donc fallu faire du paramétrage plus fin :

Réduire le nombre de plugins

Munin active par défaut tous les plugins qu’il peut. En pratique, ils n’ont pas forcément tous une utilité.

Dans mon cas, il y avait énormément de métriques sur les bases MySQL et PostgreSQL, alors que je me peux me contenter de quelques-unes.

En les supprimant, la charge CPU a été réduite de moitié environ, ainsi que la durée de collecte.

Avant/après sur une Sheevaplug :

Et sur un Olinuxino A20 :

Caractéristiques de la machine pour le serveur maître

J’avais mis le maître sur une Sheevaplug, qui était vraiment trop juste en termes de puissance CPU. Avec un Olinuxino A20, ça passe déjà beaucoup mieux.

Il faut aussi faire attention à placer les répertoires /var/lib/munin et /var/cache/munin sur un filesystem pas trop « sensible » : il va y avoir de fréquentes mises à jour dessus, ce qui peut occasionner une usure plus rapide (dans le cas de mémoire flash ou SSD) et/ou augmenter le temps de latence en lecture/écriture pour les autres applications.

En laissant ces fichiers sur une carte SD, Munin me signalait souvent que la latence en écriture dépassait 4 secondes (son seuil d’alerte par défaut).

Ma solution a été de les placer sur un périphérique dédié (une clé USB), et de paramétrer munin pour être plus tolérant sur la latence en écriture de ce périphérique, en ajoutant la ligne ci-dessous dans /etc/munin/munin.conf, pour le nœud concerné :

diskstats_latency.sdb.avgwrwait.warning 0:10

Cf http://alexcline.net/2012/10/18/configuring-the-diskstats-plugin-in-munin/

Bien sûr, une clé USB n’est pas un stockage fiable du tout. Mais peu importe : l’objectif n’est pas de sécuriser les données de Munin, mais de sécuriser les autres services de la machine.

Générer les graphiques à la demande

Plutôt que de générer les graphiques après chaque collecte, il est possible de configurer Munin pour qu’ils ne soient générés qu’à la consultation.

Cela économise beaucoup de CPU sur la machine maître (mais ralentit aussi beaucoup la consultation des graphiques).

Pour cela, il suffit de créer un fichier /etc/munin/munin-conf.d/graph.conf avec le contenu suivant (cf http://doc.ubuntu-fr.org/munin) :

graph_strategy cgi
cgiurl /munin-cgi
cgiurl_graph /munin-cgi/munin-cgi-graph

Réduire la fréquence de collecte

Pour mon besoin, une collecte toutes les 5 minutes est bien plus que nécessaire. Une période de 30 minutes entre chaque collecte me suffirait.

Hélas, après pas mal d’essais, je n’ai pas réussi

Sur le papier, ça devrait pourtant être possible, en modifiant de manière cohérente :

• la fréquence de lancement du cron dans /etc/cron.d/munin
• la valeur de l’update_rate dans /etc/munin/munin.conf
• et peut-être le graph_data_size (Cf http://pellelatarte.fr/2012/11/munin-configurer-le-temps-de-rafraichissement/)

On trouve plusieurs articles sur le web qui expliquent comment augmenter la fréquence de collecte (toutes les 1 minutes), mais aucun pour la réduire.

En m’appuyant sur les mêmes principes, j’ai soit des graphiques qui ne se mettent plus à jour (sans aucun message d’erreur dans les logs), soit des graphiques hachés de ce type :

Pour l’instant, je reste donc sur une collecte toutes les 5 minutes.

Si quelqu’un arrive à faire des collectes moins fréquentes en gardant des graphiques propres, je suis preneur.