« Munit », le monitoring sans les dinosaures

Magazine
Marque
GNU/Linux Magazine
Numéro
187
Mois de parution
novembre 2015
Spécialité(s)


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/




Article rédigé par

Par le(s) même(s) auteur(s)

Proxmox : vis ma vie d’éleveur de machines virtuelles

Magazine
Marque
Linux Pratique
Numéro
134
Mois de parution
novembre 2022
Spécialité(s)
Résumé

J’ai lu, il y a quelque temps une phrase / un concept qui m’a marqué. C’est un peu cru, et ça dit qu’il faut traiter ses conteneurs (Kubernetes), comme du bétail et non pas comme des animaux de compagnie. En gros, chaque conteneur doit être jetable et très facilement remplaçable. Ce qui compte, ce sont les données à l’intérieur. Aimant particulièrement les animaux, j’ai vraiment eu du mal en lisant ce concept, mais après tout, je le trouve très pratique, et je m’y suis mis avec mes machines virtuelles.

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
Spécialité(s)
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).

Les derniers articles Premiums

Les derniers articles Premium

Sécurisez vos applications web : comment Symfony vous protège des menaces courantes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les frameworks tels que Symfony ont bouleversé le développement web en apportant une structure solide et des outils performants. Malgré ces qualités, nous pouvons découvrir d’innombrables vulnérabilités. Cet article met le doigt sur les failles de sécurité les plus fréquentes qui affectent même les environnements les plus robustes. De l’injection de requêtes à distance à l’exécution de scripts malveillants, découvrez comment ces failles peuvent mettre en péril vos applications et, surtout, comment vous en prémunir.

Bash des temps modernes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les scripts Shell, et Bash spécifiquement, demeurent un standard, de facto, de notre industrie. Ils forment un composant primordial de toute distribution Linux, mais c’est aussi un outil de prédilection pour implémenter de nombreuses tâches d’automatisation, en particulier dans le « Cloud », par eux-mêmes ou conjointement à des solutions telles que Ansible. Pour toutes ces raisons et bien d’autres encore, savoir les concevoir de manière robuste et idempotente est crucial.

Présentation de Kafka Connect

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Un cluster Apache Kafka est déjà, à lui seul, une puissante infrastructure pour faire de l’event streaming… Et si nous pouvions, d’un coup de baguette magique, lui permettre de consommer des informations issues de systèmes de données plus traditionnels, tels que les bases de données ? C’est là qu’intervient Kafka Connect, un autre composant de l’écosystème du projet.

Le combo gagnant de la virtualisation : QEMU et KVM

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

C’est un fait : la virtualisation est partout ! Que ce soit pour la flexibilité des systèmes ou bien leur sécurité, l’adoption de la virtualisation augmente dans toutes les organisations depuis des années. Dans cet article, nous allons nous focaliser sur deux technologies : QEMU et KVM. En combinant les deux, il est possible de créer des environnements de virtualisation très robustes.

Les listes de lecture

9 article(s) - ajoutée le 01/07/2020
Vous désirez apprendre le langage Python, mais ne savez pas trop par où commencer ? Cette liste de lecture vous permettra de faire vos premiers pas en découvrant l'écosystème de Python et en écrivant de petits scripts.
11 article(s) - ajoutée le 01/07/2020
La base de tout programme effectuant une tâche un tant soit peu complexe est un algorithme, une méthode permettant de manipuler des données pour obtenir un résultat attendu. Dans cette liste, vous pourrez découvrir quelques spécimens d'algorithmes.
10 article(s) - ajoutée le 01/07/2020
À quoi bon se targuer de posséder des pétaoctets de données si l'on est incapable d'analyser ces dernières ? Cette liste vous aidera à "faire parler" vos données.
Voir les 125 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous