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.
Sommaire
- 1 Architecture
- 2 Les plugins
- 3 Les graphiques
- 4 Installation
- 4.1 Utilisation de la version backport sur Debian Wheezy
- 4.2 Paramétrage
- 4.3 Cas du plugin MySQL
- 4.4 Cas du plugin Apache
- 4.5 Exposition des graphiques par Apache
- 4.6 Configuration avec un seul maître et plusieurs nœuds
- 4.7 Avertissements par email
- 4.8 Avertissements par SMS (chez Free Mobile)
- 4.9 Unité des graphiques
- 5 Difficultés
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.
Bonjour,
Merci pour cet article de l’année dernière. Tu es le seul que j’ai trouvé qui aborde la question du plugin Apache.
Chez moi « munin-node-configure –suggest »
réponds : « [Port 80: Can’t connect to 141.138.156.122:443 (certificate verify failed)] »
Tu me donnes la piste de la solution : créer un Virtualhost …
mais là j’ai des doutes, j’ai toujours créé mes virtualhost par nom de domaines, jamais par IP … Si tu pouvais indiquer comment faire ce virtualhost, tu me rendrais un véritable service. (essais erreurs sur un serveur en production bof bof !!)
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.
Oups, pardon pour les 2 derniers paragraphes arrivés ici par erreur
Voici le code de mon VirtualHost pour le server-status :
<VirtualHost 127.0.0.1:80>
ServerName 127.0.0.1
<Location />
Deny from all
Allow from 127.0.0.1
</Location>
</VirtualHost>
(pas sûr que la directive Location soit vraiment nécessaire, ni le ServerName d’ailleurs)
L’idée est de faire écouter Apache sur le port 80, mais uniquement sur l’interface locale (127.0.0.1), c’est-à-dire que ce VirtualHost ne sera utilisé que pour les requêtes venant du serveur lui-même.
Dans ton cas de figure, il semblerait que ton serveur Apache écoute sur le port 80, mais fasse systématiquement une redirection sur le port 443 (avec un certificat auto-signé : c’est ce que Munin dit).
Avec ce VirtualHost activé sur ton Apache, il est probable que Munin passe par lui, et que ça fonctionne, sans pour autant impacter les requêtes qui viennent de l’extérieur.
Dans tous les cas, je ne peux qu’encourager de tester ça sur un autre serveur avant de le mettre en production…
Bravo pour le diagnostic, tu as bien interprété le message de munin
Les plugins apache marchent maintenant
C’est tout bon
(ou alors j’ai pas encore vu le bug)
MERCI