« Munit », le monitoring sans les dinosaures

Magazine
Marque
GNU/Linux Magazine
Numéro
187
Mois de parution
novembre 2015
Domaines


Résumé
Dans les pages qui suivent nous allons voir comment mettre en place un système de monitoring avancé : surveillance des signes vitaux du serveur et des processus, alerte SMS en cas de danger et/ou de problèmes, etc. De plus, parce que nous aimons faire les choses différemment, nous allons voir comment nous passer des dinosaures qui règnent sur le domaine à savoir : Nagios, Centreon et leurs acolytes.

Body

« 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).

munin_mem_usage

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/




Articles qui pourraient vous intéresser...

Comparaison de deux méthodes d’isolation CPU

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
111
Mois de parution
novembre 2020
Domaines
Résumé

Afin de séparer les cœurs supportant les activités temps réel et temps partagé d'applications sur une architecture SMP sous Linux, le sous-système cpuset des cgroups est désormais mis en avant, au détriment de l’ancienne méthode basée sur le paramètre isolcpus.

Surveiller son système avec Monit

Magazine
Marque
Linux Pratique
HS n°
Numéro
49
Mois de parution
novembre 2020
Domaines
Résumé

La supervision d’un système en production demeure un enjeu aussi complexe qu’essentiel. Il existe de nombreuses solutions, très complètes, de supervision, mais la plupart adoptent une approche centralisée, qui demande l’utilisation de ressources dédiées. Aujourd’hui, nous étudierons une approche alternative, une solution de supervision décentralisée, nommée Monit.

Fabric, le couteau suisse de l’automatisation

Magazine
Marque
Linux Pratique
Numéro
122
Mois de parution
novembre 2020
Domaines
Résumé

Fabric est une bibliothèque Python et une interface en ligne de commandes facilitant l’utilisation de SSH, que ce soit pour des applications ou dans le but d’automatiser certaines tâches répétitives d’administration système. La grande force de Fabric est d’être particulièrement simple à utiliser.

Comprendre les bases de données relationnelles

Magazine
Marque
Linux Pratique
Numéro
122
Mois de parution
novembre 2020
Domaines
Résumé

Indispensables pour le stockage et le traitement massif de données, les bases de données relationnelles sont partout. Si elles sont utilisées principalement pour l’informatique de gestion, on les rencontre également dans des domaines aussi divers que les sites web, les systèmes d’exploitation ou même les jeux vidéo. Dans cet article, nous allons vous faire découvrir les principaux concepts qui sous-tendent leur fonctionnement.