« 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/


Sur le même sujet

Collectez et exploitez les métriques de votre système avec Collectd

Magazine
Marque
Linux Pratique
HS n°
Numéro
47
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Par défaut, votre système journalise dans différents fichiers les événements qui se passent vous permettant de déceler une activité anormale et autre plantage. Mais vous avez aussi besoin de collecter des métriques de votre système et de ses applications, et de générer les graphiques associés. Car c’est seulement grâce à ces données et graphiques que vous pourrez faire de l’analyse de performance pour détecter les goulots d’étranglement, ou faire de la gestion de capacité en prédisant la future charge système. Un des moyens les plus simples de collecter des données d’un serveur est d’utiliser le démon Collectd.

Hébergement privé de dépôts Git

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
109
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Nous allons voir comment mettre en place un hébergement de dépôts Git privé indépendant et évolutif, avec seulement trois containers. Cela comprendra une interface web, la possibilité de gérer plusieurs utilisateurs, organisations et leurs dépôts, qu’ils soient privés ou publics.

Cluster et orchestration de conteneurs avec Docker Swarm

Magazine
Marque
Linux Pratique
HS n°
Numéro
47
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Cet article prolonge mon précédent article [1] et parle de la capacité à introduire de la haute disponibilité dans les environnements de conteneurs Docker, critère indispensable pour pouvoir utiliser ces technologies jusqu’à la production, ceci au travers de la notion de cluster et d’orchestration de conteneurs.

Introduction au dossier : Déployez votre système de supervision

Magazine
Marque
Linux Pratique
HS n°
Numéro
47
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Technique à ne pas négliger, la supervision va permettre de s’assurer du bon fonctionnement de votre système. La mise en place d’une supervision permet ainsi à tout administrateur d’être alerté en cas de problème, d’avoir à l’œil un suivi de son infrastructure, ses machines, son réseau... et d’agir ainsi au plus vite en cas de dysfonctionnement, en s’étant informé un maximum en amont par le biais de logs et rapports d’activités.

Crostini : débridez Chrome OS avec les applications Linux

Magazine
Marque
Linux Pratique
Numéro
120
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Chrome OS est basé sur un système Linux (Gentoo), mais l'approche adoptée par Google est de limiter les possibilités de paramétrage et d'installation d'applications. Pour améliorer la polyvalence de son système sans remettre en cause son modèle sécuritaire, Google a, par la suite, introduit Crostini : une solution basée sur LXC pour que les utilisateurs de Chrome OS puissent travailler avec Linux dans un conteneur.

Analysez, diagnostiquez et dépannez votre système avec Sysdig

Magazine
Marque
Linux Pratique
HS n°
Numéro
47
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Un système ne manque pas d’avoir des problèmes matériels, de plantage système, de performances, au niveau utilisateur ou noyau. Et malheureusement, les systèmes Linux ne sont pas exempts de ces problèmes à dépanner. Mais heureusement, Linux n’est pas en reste d’outils pour vous aider à diagnostiquer les problèmes. Des outils simples comme top pour surveiller l’usage CPU, ou ps pour les processus. Vous voulez tracer un appel système d’un processus : strace est votre ami. tcpdump, ou tshark vous aideront à inspecter le trafic réseau en ligne de commandes. Vous avez donc beaucoup d’outils à disposition, dans l’esprit « un outil précis pour une tâche unique », cher à Linux. Le problème c’est que lorsque l’on dépanne un système, on n’a pas le temps de se souvenir de tous les outils à disposition et taper toutes ces commandes en live. Outils qui ont chacun une philosophie différente, une interface d’entrée et de sortie différentes, ce qui peut poser soucis dans des situations stressantes et créer de la confusion lors d’occasions qui demandent de réagir dans l’urgence. Surtout que la plupart de ces outils ne sont pas pensés et optimisés pour être utilisés dans des conteneurs, plateformes de plus en plus utilisées et répandues.

Par le même auteur

Découvrez RetroPie, la distribution dédiée au rétrogaming sur Raspberry Pi

Magazine
Marque
Linux Pratique
HS n°
Numéro
41
|
Mois de parution
février 2018
|
Domaines
Résumé
Dans l’article qui suit, je vais vous présenter RetroPie, une solution clé en main permettant de jouer (ou de rejouer) aux jeux vidéo de ma jeunesse (et peut-être aussi de la vôtre) avec les technologies d’aujourd’hui (c’est-à-dire, sans se lever de son canapé pour changer de jeu, c’est beau le progrès).

InfluxDB, Grafana et Glances, le monitoring qui brille

Magazine
Marque
GNU/Linux Magazine
Numéro
209
|
Mois de parution
novembre 2017
|
Domaines
Résumé
Dans l’article qui va suivre, je vais vous guider, si vous l’acceptez, dans la mise en place d’un système de monitoring peu conventionnel. En nous basant sur des programmes très spécifiques, mais complémentaires, nous allons créer un outil capable de surveiller vos serveurs tout en affichant vos données dans une interface digne du XXIème siècle.

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

Jouer aux jeux vidéos sous GNU/Linux (ou presque)

Magazine
Marque
Linux Pratique
Numéro
77
|
Mois de parution
mai 2013
|
Domaines
Résumé
Joueur PC depuis ma plus tendre enfance, j'avais mis fin à ce passe-temps il y a plusieurs années de cela, lorsque je suis passé sous GNU/Linux à temps plein. Désormais, les choses ont changé. Fini le « dual boot » pour jouer, voici venue la machine virtuelle Xen avec gestion des cartes graphiques pour les OS invités !