« Munit », ou l'association de Munin et Monit, est une solution de monitoring avancée. En effet, Munin permet de « prendre les constantes » de votre serveur et de vous alerter en cas de problème imminent, ou déjà avéré. De son côté Monit peut surveiller et relancer automatiquement les processus voulus en cas de soucis.
Les solutions habituelles de monitoring se basent très souvent sur Nagios, Centreon et assimilés. C'est à dire des solutions dédiées au monitoring. Ces solutions bien que fonctionnelles (malgré leur grand âge) sont souvent très lourdes et sous-exploitées (un peu comme Apache pour faire juste du Web, c'est de l' « overkill »). Vu que j'aime faire les choses différemment et sortir des sentiers battus, j'ai décidé de composer ma propre solution de monitoring basée sur deux très bons outils Open Source : Munin et Monit. Laissez-moi vous présenter ce système que j'utilise depuis plusieurs années.
1 La prise de constantes : Munin
Un peu comme à l'hôpital, un système de monitoring doit permettre de prendre les constantes du serveur à intervalles réguliers. Voici un exemple , non exhaustif, des éléments pouvant être surveillés par Munin :
- usage mémoire / CPU important ;
- espace disque restant faible ;
- surcharge de la bande passante ;
- etc.
Ces différentes mesures sont ensuite affichées au sein d'une interface Web sous forme de graphiques et archivées sur de longues périodes (voir figure 1).
Fig. 1: Graphique de l'utilisation de la mémoire (Munin).
Enfin, comme tout système de monitoring, Munin se compose d'une partie serveur qui centralise les informations et d'une sonde placée sur chaque hôte à surveiller (et donc aussi sur le serveur principal).
1.1 Installation de la partie serveur
Côté serveur (ici une Debian Jessie), nous installons les paquets nécessaires avec les droits « root » :
# apt-get install munin
Cela va aussi installer la sonde (paquet : munin-node) qui est utilisée sur le serveur afin de prendre ses propres constantes.
Pour accéder aux graphes de Munin, nous devons configurer un virtualhost. Partons du principe que nous avons déjà un serveur Apache fonctionnel sur notre serveur. Il suffit simplement de s'inspirer de la configuration fournie avec Munin et située à /etc/munin/apache.conf ou /etc/munin/apache24.conf.
Il faut ensuite, comme toujours, limiter l'accès de ce virtualhost aux seules personnes autorisées. Les méthodes varient selon les goûts et les humeurs : .htaccess avec un mot de passe, limite par IP ou les deux. Quoi qu'il en soit il s'agit d'une procédure standard propre à votre serveur Web.
Apache 2.4 change un peu la donne et, pour plus d'informations, je vous recommande un article [1], voire tout particulièrement la section sur les autorisations « allow from ».
Si vous utilisez Nginx, vous trouverez une page très utile sur internet [2].
Éditons ensuite le fichier principal de configuration de Munin :
# vim /etc/munin/munin.conf
Décommentons les quatre lignes correspondant aux différents « chemins » :
dbdir /var/lib/munin
htmldir /var/cache/munin/www
logdir /var/log/munin
rundir /var/run/munin
Un peu plus bas dans le fichier, j'ai pour habitude de commenter les lignes suivantes afin de regrouper tous mes serveurs au même endroit, tout à la fin du fichier :
# a simple host tree
#[localhost.localdomain]
# address 127.0.0.1
# use_node_name yes
Du coup, tout en bas du fichier, nous allons y mettre la liste de nos serveurs à surveiller :
[GLMF;munit-server]
address 127.0.0.1
use_node_name yes
[GLMF;munit-sonde]
address 192.168.122.225
use_node_name yes
[Test;bobby]
address 192.168.122.168
use_node_name yes
Ici, je note les serveurs sous la forme XXX;YYY, XXX étant le groupe et YYY étant le nom du serveur. Pour plus d'informations sur les conditions de nommage, n'hésitez pas à lire la documentation du fichier en question.
1.2 Installation de la sonde
Commençons par installer le paquet nécessaire avec les droits « root » :
# apt-get install munin-node
Pour bien faire les choses, nous avons besoin d'au minimum deux sondes, sur deux serveurs différents. La première sonde se trouvera sur le serveur « central » lui-même et la seconde sur un serveur satellite. Dans les deux cas, la procédure reste la même.
Ensuite, il s'agit de configurer avec votre éditeur de texte préféré (oui, même emacs si vous y tenez vraiment) la fameuse sonde par l'intermédiaire du fichier /etc/munin/munin-node.conf.
Dans ce fichier, seuls deux éléments nous intéressent :
- lui donner un nom qui l'identifiera au niveau du serveur central :
host_name munit-server
Ce nom (sans le groupe) doit correspondre au nom donné dans le fichier de configuration /etc/munin/munin.conf du serveur principal.
- l'adresse IP autorisée à interroger la sonde :
allow ^127\.0\.0\.1$
Ici l'adresse IP est 127.0.0.1, car nous sommes en train de configurer la sonde du serveur principal. Sur un serveur satellite, nous aurions eu une IP de la forme : ^192\.168\.XXX\.XXX$, ou un « cidr ». Le fichier est bien documenté, n'hésitez pas à le lire.
Enfin, côté sonde, une petite commande bien pratique nous permet de suggérer les plugins les mieux adaptés à votre système. La commande est la suivante (avec les droits « root ») :
# munin-node-configure --suggest
Plugin | Used | Suggestions
------ | ---- | -----------
acpi | no | no [cannot read /proc/acpi/thermal_zone/*/temperature]
amavis | no | no
apache_accesses | no | yes
apache_processes | no | yes
apache_volume | no | yes
Nous voyons dans cet exemple, que Munin a détecté Apache et nous propose trois plugins à activer. Pour ce faire, deux solutions s'offrent à vous :
- soit vous utilisez la méthode manuelle, décrite vers la fin de cet article ;
- soit vous utilisez la méthode « automatique », qui consiste à profiter de la beauté de notre OS et du système de « pipe » :
# munin-node-configure --shell | sh
Avant de lancer la commande ci-dessus, essayez-la sans le « pipe » et vous comprendrez de quoi je parle.
En guise d'exercice, je vous laisse configurer de votre côté la sonde sur le serveur satellite.
Une fois la configuration effectuée, vous devez relancer la sonde pour prendre en compte les changements :
# /etc/init.d/munin-node restart
Nous aborderons dans une partie dédiée, vers la fin de cet article, la gestion des notifications qui fait partie intégrante de Munin, ainsi que le fonctionnement des plugins.
2 Gestion automatisée des processus : Monit
Mettre en place un système de relevé des constantes, c'est bien. Avoir un système un minimum « intelligent » qui soit capable d'essayer de « réparer » les erreurs lui-même c'est mieux.
Nous allons donc voir comment Monit peut nous aider à gérer notre serveur avec le minimum d'interventions humaines possibles. Ce qui, dans ce domaine-là, présente beaucoup d'avantages en limitant les erreurs (humaines) tout en réduisant les délais d'actions.
En effet, Monit permet de relancer automatiquement un processus qui a planté, ne répond plus, ou consomme trop de ressources.
2.1 Installation et configuration de Monit
Monit s'installe simplement avec la commande suivante :
# apt-get install monit
N'oubliez pas de l'installer sur chacun de vos serveurs, qu'ils soient des satellites ou le serveur principal.
La configuration de Monit se fait dans le fichier /etc/monit/monitrc. Il est intéressant de régler l'intervalle de temps des vérifications selon vos besoins :
set daemon 120 # check services at 2-minute intervals
with start delay 240 # optional: delay the first check by 4-minutes
Si vous le désirez, vous pouvez activer « l'interface Web ». C'est une fonction que je n'utilise pas, mais, sous ce nom, se cache aussi un moyen d'accéder à des commandes supplémentaires en mode console, et ça j'aime bien !
Du coup, on active une interface Web « bidon », en ajoutant les lignes suivantes dans le fichier de config :
set httpd port 2812 and
use address localhost
allow localhost
Le port 2812 n'est autorisé que depuis le serveur en lui-même, donc il ne sera pas ouvert au public. Vous pouvez en plus de cela utiliser un pare-feu pour filtrer tous les ports non utilisés.
Désormais, vous avez accès aux commandes suivantes :
$ monit summary
The Monit daemon 5.6 uptime: 5m
Process 'nginx' Running
Process 'mysqld' Running
Process 'sshd' Not monitored
Process 'php-fpm' Running
Process 'artillery' Running
Process 'munin-node' Running
System 'nesobox' Running
Et aussi :
$ monit status
Cette dernière commande donne un aperçu détaillé, processus par processus. Très pratique pour vérifier d'un coup d’œil si tout fonctionne, depuis combien de temps tourne chaque processus, ou encore la consommation en ressources.
Enfin, dans ce même fichier /etc/monit/monitrc, nous configurerons dans la partie suivante les services à surveiller.
Allez faire un tour dans /etc/default/monit et assurez-vous que le démarrage de Monit est autorisé :
# Set START to yes to start the monit
START=yes
Une fois Monit correctement configuré, vous pouvez le lancer, au besoin, avec la commande :
# /etc/init.d/monit start
À noter aussi, qu'il est tout à fait possible de recevoir des alertes à chaque fois que Monit effectue une action sur un serveur.
2.2 Exemple détaillé de configuration
L'intérêt principal de Monit est de le configurer processus par processus afin de répondre au mieux à vos besoins. Voyons ensemble comment le configurer pour les processus les plus courants.
- Nginx :
## NGiNX
check process nginx with pidfile /var/run/nginx.pid
group www-data
start program = "/etc/init.d/nginx start"
stop program = "/etc/init.d/nginx stop"
if 5 restarts within 5 cycles then timeout
L'exemple suivant permet de vérifier que Nginx fonctionne correctement grâce au fichier .pid. Si Nginx tourne, alors ce fichier est présent et contient le numéro de PID du process en question ; si Nginx a crashé, alors ce fichier ne sera pas présent sur le disque. Monit relancera donc le service avec la commande indiquée dans l'exemple ci-dessus.
- MySQL :
## MySQL
check process mysqld with pidfile /var/run/mysqld/mysqld.pid
group database
start program = "/etc/init.d/mysql start"
stop program = "/etc/init.d/mysql stop"
if failed host 127.0.0.1 port 3306 then restart
if 5 restarts within 5 cycles then timeout
Dans certains cas le PID ne suffit pas. Un processus peut tourner mais sans répondre aux requêtes. Monit peut donc essayer de se connecter sur un port précis, ici le port 3306 afin de vérifier si MySQL fonctionne correctement. Si ce n'est pas le cas, alors Monit le relancera lui-même.
- Vérifications basées sur la mémoire, le CPU, etc :
## Apache
check process apache with pidfile /var/run/apache2/apache2.pid
group www-data
if cpu usage > 90% for 5 cycles then restart
if mem usage > 90% for 5 cycles then restart
start program = "/etc/init.d/apache2 start"
stop program = "/etc/init.d/apache2 stop"
if 5 restarts within 5 cycles then timeout
Dans ce dernier exemple, nous surveillons Apache pour être sûr qu'il fonctionne correctement, mais surtout qu'il ne consomme pas trop de ressources. Si jamais ce dernier dépasse les 90 % d'usage processeur et/ou mémoire, alors Monit le relancera automatiquement.
N'hésitez pas à consulter le site officiel de Monit [3] pour plus d'information.
3 Utilisation avancée de Munin
3.1 Les plugins
Munin bénéficie d'un très grand nombre de plugins. Ceux de base se trouvent dans le dossier /usr/share/munin/plugins/, d'autres peuvent être trouvés sur le Web [4].
D'une manière générale, vous placerez les plugins de votre choix dans le répertoire indiqué ci-dessus, et vous créerez un lien symbolique pour les activer :
# ln -s /usr/share/munin/plugins/bobby /etc/munin/plugins/
Une fois les plugins « installés », vous pouvez les configurer en passant par le fichier /etc/munin/plugin-conf.d/munin-node.
Par exemple, certains plugins tel multips_memory (qui permet de suivre l'usage mémoire d'un processus donné au cours du temps) se configure de la sorte :
[multips_memory]
nginx mysqld monit python
Dans cet exemple, nous « graphons » l'usage mémoire des processus nginx, mysql, monit et python.
Enfin, à la manière des systèmes GNU/Linux, une fois nos modifications effectuées, nous devons redémarrer le systè… Non, je rigole ! Relançons simplement le service concerné :
# /etc/init.d/munin-node restart
3.2 Les notifications
Dans le fichier de configuration de Munin, /etc/munin/munin.conf, vous pouvez ajouter la ligne suivante afin de recevoir des notifications :
contact.nesousx.command curl -k 'https://smsapi.free-mobile.fr/sendmsg?user=XXXXXX&pass=XXXXXXX&msg=*${var:host}* -> ${var:graph_title} <-warnings: ${loop<,>:wfields ${var:label}=${var:value}} criticals: ${loop<,>:cfields ${var:label}=${var:value}}'
Cette ligne décrit l'action à effectuer lorsqu'une notification doit être envoyée. La plupart du temps, il s'agit d'envoyer un email, voire un email vers une passerelle SMS (souvent payante) si vous préférez les messages textes.
Dans mon cas, j'utilise l'API Free qui me permet de m'envoyer des SMS gratuitement. Pour ce faire, j'utilise donc la commande curl sur l'URL donnée par Free (voir gestion des options de la ligne) avec les messages d'alerte formatés comme je le désire. Voici un exemple de message reçu :
*munit-server* -> Disk usage in percent <-warnings: /home=94.35 criticals:
On voit sur ce message qu'il s'agit uniquement d'un avertissement concernant la partition /home du serveur munit-server qui occupe 94.35%. Il est possible de régler les seuils d'alertes pour les avertissements et les problèmes critiques [5].
Conclusion
Comme nous venons de le voir, il est tout à fait possible d'avoir un système de monitoring relativement complet et efficace tout en se passant des « poids lourds » du marché. En effet, notre système actuel nous permet de suivre l'état de notre serveur de façon assez précise. Cerise sur le gâteau, ce système permet aussi de régler automatiquement une partie des problèmes les plus courants.
Références
[1] Changements Apache 2.2 vers 2.4 : http://httpd.apache.org/docs/2.4/upgrading.html
[2] Configurer un virtualhost Munin pour nginx : http://uname.pingveno.net/blog/index.php/post/2013/08/25/Configure-Munin-graphs-with-Nginx-and-Debian-7
[3] Différentes configurations pour Monit : https://www.mmonit.com/wiki/Monit/ConfigurationExamples
[4] Ajouter des plugins à Munin : http://munin-monitoring.org/wiki/plugins
[5] Régler les seuils d'alerte de Munin : http://blog.edseek.com/archives/2006/07/13/munin-alert-email-notification/
