Monit – Installation et configuration

I. Présentation :

Il est essentiel de surveiller l’état général de votre serveur, c’est-à-dire les processus, les programmes, les répertoires, les fichiers, etc… C’est ce qu’on appelle le monitoring système. Le but est d’indiquer à l’application ce qu’on souhaite surveiller et elle effectuera des contrôles réguliers, et lorsqu’une erreur sera rencontrée, une alerte sera envoyée. Une alerte peut être envoyée mais pas seulement, on peut effectuer une action sur le processus et même exécuter un script lorsqu’une erreur est détectée.

Ces vérifications peuvent aller de la surveillance de la charge CPU à la vérification de la somme SHA-1 d’un fichier, ce qui permet une multitude de choix et une surveillance minutieuse.

En fait, c’est un peu le même principe que de la supervision sauf que là on surveille uniquement la machine locale. Ce n’est pas un serveur qui ira surveiller d’autres serveurs comme on peut le faire avec un serveur de supervision.

Dans notre cas, nous allons utiliser monit qui a l’avantage d’être simple à configurer en utilisant un seul fichier de configuration, et, il propose également une interface web pour accéder aux données.

II. Installation :

La première chose à faire est bien évidemment l’installation du paquet « monit » afin de disposer de l’application sur notre serveur. Pour se faire, on installe « monit » à l’aide du gestionnaire de paquets Aptitude :

apt-get update
apt-get install monit

III. Fonctionnement :

Comme je le disais précédemment, monit fonctionne avec un seul et unique fichier de configuration qui est le suivant :

/etc/monit/monitrc

Toutefois, selon les distributions et les versions, cela peut changer donc si vous n’avez pas le fichier indiqué ci-dessus, regardez aux chemins suivants :

~/.monitrc
/etc/monitrc

Si vous désirez utiliser un autre fichier de configuration, utilisez l’option « -c » de la commande monit, comme ceci :

monit –c /chemin/vers/votre/fichier

Avant de commencer la configuration, vérifiez la cohérence du fichier de configuration grâce à l’option « -t » de la commande monit :

monit –t

Si aucun message vous est renvoyé ou éventuellement le message « Control file syntax OK » alors la configuration est correcte. Sinon, on vous indiquera un message « Syntax error… ».

Faites une copie du fichier de configuration (adaptez le chemin si votre fichier de configuration n’est pas celui-ci).

cd /etc/monit/
cp monitrc monitrc.default

Si vous le souhaitez, vous pouvez partir d’un fichier vierge en le nommant « monitrc » et le construire en suivant les instructions qui vont suivent.

IV. Configuration globale :

Maintenant, passons à la configuration globale de monit c’est-à-dire à ses paramètres de fonctionnement. Ouvrez le fichier de configuration « monitrc » afin de voir ce qu’il a dans le ventre.

A. Délai de rafraîchissement :

La première directive déclarée dans le fichier est la suivante :

set daemon 120

Elle sert à indiquer le délai de rafraîchissement pour la vérification des services, c’est-à-dire dans ce cas que le contrôle aura lieu toutes les 120 secondes, soit 2 minutes. Cette commande indique également que monit est exécuté en mode démon.

B. Les journaux :

La seconde directive concerne les journaux (logs) de monit, qui par défaut sont stockés dans le fichier « monit.log » dans « /var/log/ ». En changeant la valeur de ce paramètre, vous changez de fichier de journalisation.

set logfile /var/log/monit.log

C. Les fichiers d’identification et d’état :

La troisième directive indique le chemin vers le fichier contenant l’identifiant unique de monit. Ne modifiez pas ce paramètre.

set idfile /var/lib/monit/id

La quatrième directive indique le chemin vers le fichier d’état de monit, qui est un fichier temporaire où monit stocke des informations. Ne modifiez pas ce paramètre.

set statefile /var/lib/monit/state

D. Serveur(s) SMTP pour les alertes :

Étant donné que monit propose les alertes par mails, il faut le configurer en ajoutant ceci dans le fichier monitrc :

set mailserver smtp.votre.serveur

Ceci vous permettra d’indiquer à monit le serveur SMTP qu’il doit utiliser pour envoyer des mails. Remplacez « smtp.votre.serveur » par votre serveur SMTP ou éventuellement celui de votre FAI.

Note : Pour indiquer plusieurs serveurs SMTP, séparez-les par une virgule.

Vous pouvez également ajouter le port :

set mailserver smtp.votre.serveur port 25

Si votre serveur SMTP requiert une authentification, dans ce cas vous devez utiliser la syntaxe suivante (exemple : utilisateur « florian » et mot de passe « 123456 ») :

set mailserver smtp.votre.serveur port 25
username florian password 123456
using TLSV1

 Note : La ligne « using » permet d’indiquer le protocole de sécurité utilisé, vous pouvez l’enlever ou alors indiquer une de ces 3 valeurs : SSLV2, SSLV3, TLSV1.

E. Personnaliser le format des mails :

Envoyer des mails en alerte c’est bien, les personnaliser c’est encore mieux ! Monit permet de le faire grâce à la directive « mail-format » :

set mail-format {
from: [email protected]
reply-to: [email protected]
subject: Alerte : $EVENT - $DATE
message: Monit $ACTION $SERVICE le $DATE sur le serveur $HOST: $DESCRIPTION.
}

Vous remarquerez la présence de différente variable, comme « $SERVICE », « $EVENT », « $DATE », « $ACTION » et « $HOST ». Elles permettent de faire en sorte que le message d’alerte s’adapte selon l’erreur détectée.

• $SERVICE : Nom du service indiqué dans monitrc.
• $EVENT : Type d’événement.
• $DATE : La date en cours.
• $ACTION : Le nom de l’action effectuée, qui correspondra à l’action définie dans monitrc pour ce service.
• $HOST : Le nom de l’hôte où est installé monit.

« from » correspond à l’adresse d’envoi, « reply-to » correspond à l’adresse pour répondre, « subject » au sujet du message » et « message » au message contenu dans le mail.

F. Destinataire des emails :

Il ne faut pas oublier de préciser à qui doivent être envoyées les alertes par mail. On utilise la directive « alert » comme ceci :

set alert [email protected]

 G. Stockage des alertes :

Si vous ne souhaitez pas recevoir d’alerte pas mail, vous pouvez indiquer à monit de stocker les alertes dans un répertoire pour que vous puissiez y avoir accès ultérieurement.

La directive « eventqueue » doit être utilisée pour cela et elle est déjà activée par défaut.

set eventqueue
# Répertoire de stockage des événements
basedir /var/lib/monit/events 
# La taille maximale de la file d’attente (facultatif)
slots 100

 H. Activation de l’interface web :

Comme je le disais dans la présentation, monit propose une interface web permettant de visualiser les données collectées. Toutefois, il faut l’activer et la configurer dans le fichier monitrc puisque ce n’est pas fait par défaut.

# Activation du serveur web sur le port 8080
set httpd port 8080
# Autoriser les connexions depuis 192.168.1.10 (ne pas mettre cette ligne revient
# À autoriser les connexions depuis n’importe quel client.
allow 192.168.1.10
# Autoriser l’utilisateur « admin » avec le mot de passe « monit »
allow admin:monit
# Autoriser tous les membres du groupe « informatique »
allow @informatique
# Autoriser tous les membres du groupe « stagiaire » en lecture seule
allow @stagiaire readonly

Tous les paramètres ne sont pas obligatoires mais vous devez au moins définir un nom d’utilisateur et un mot de passe.

Note : Vous pouvez indiquer n’importe quel port pour accéder à l’interface de monit. Toutefois, faites attention au conflit si un serveur web tourne déjà sur votre machine, notamment sur le port 80.

Avant de redémarrez, tester votre configuration :

monit -t

Pour finir, redémarrez votre service « monit » afin que les modifications soient prises en compte :

/etc/init.d/monit restart

 V. Configuration des services :

Monit est désormais configuré et prêt à nous envoyer des alertes lors de la détection d’une erreur mais pour cela il faut d’abord lui indiquer ce qu’il doit surveiller. Vous allez voir c’est très simple et très intuitif.

Dans ce tutoriel, nous ne pourrons pas voir tous les types de vérifications puisque c’est illimité et ça dépend de vos besoins. Néanmoins, nous verrons quelques exemples.

A. Les différents types d’action :

Vous devez indiquer à monit ce qu’il doit faire lorsqu’il détecte une erreur, en utilisant les actions suivantes :

• alert : Envoie un message d’alerte,
• start : Démarrer le service et envoie un message d’alerte,
• stop : Stoppe le service et envoie un message d’alerte,
• restart : Redémarre le service et envoie un message d’alerte,
• exec : Exécute un script et envoie un message d’alerte,
• unmonitor : Désactive la surveillance du service et envoie un message d’alerte,
• monitor : Active la surveillance.

Remarque : Dans tous les cas une alerte est envoyée.

B. La syntaxe d’un contrôle :

La syntaxe d’un contrôle est toujours semblable et repose sur un test conditionnel, qui ressemble à ceci :

if <test_a_effectuer> then <action_en_cas_erreur>

Par exemple : « Si la charge CPU est supérieur à 90% alors on envoie une alerte » ou « Si la taille du répertoire /home/florian/ est supérieur à 500 Mo alors on exécute un script qui désactivera le compte d’utilisateur florian ».

Il est possible aussi d’utiliser à la suite la condition « else if » c’est-à-dire « Sinon si » et de faire un second test. Mais aussi, d’indiquer « and » entre chaque test pour en effectuer plusieurs.

C. La syntaxe d’un service :

La syntaxe d’un service dépend de ce qu’on souhaite vérifier mais le point commun entre tous les services, c’est que leur déclaration commence toujours par « check ». La première ligne contient donc le « check » suivit du type de ressource qu’on souhaite surveiller (system, directory, file, etc.) et les lignes d’en dessous correspondent à tous les contrôles contenu dans ce service. De ce fait, dans un seul service on peut effectuer une multitude de contrôle.

VI. Surveiller la charge système :

Le premier service que nous allons définir va surveiller la charge de notre système c’est-à-dire contrôler l’utilisation des ressources.

Le but est d’envoyer une alerte par mail si l’une des conditions suivantes est vraie :

- La charge mémoire dépasse 85%.
- La charge moyenne sur les 15 dernières minutes dépasse l’indice 4.
- La charge CPU d’un utilisateur dépasse 75%.
- La charge de la mémoire SWAP dépasse 25%.

# srvweb.neoflow.fr correspond au nom de votre service
check system srvweb.neoflow.fr
# Contrôle de la charge RAM
if memory usage > 85% then alert
# Contrôle de la charge moyenne
if loadavg (15min) > 4 then alert
# Contrôle de la charge CPU utilisateur
if cpu usage (user) > 75% then alert
# Contrôle de la charge de la mémoire SWAP
if swap usage > 25% then alert

 Note : On peut surveiller la charge avec « loadavg » pour 1 minute, 5 minutes et 15 minutes, comme le fait de base Linux avec la commande « top ».

Redémarrez votre service monit pour que le service soit pris en compte mais n’oubliez pas d’exécuter la commande de vérification de configuration auparavant.

Pour ma part, j’ai fait en sorte de déclencher une alerte et j’ai bien reçu par mail une notification pour le contrôle sur la charge mémoire. Vérifiez par vous-même :

Monit alert srvweb.neoflow.fr le Fri, 04 Jan 2013 15:14:06 sur le serveur srvweb.neoflow.fr: mem usage of 87.6% matches resource limit [mem usage>85.0%].

 VII. Surveiller le service Apache2 :

Imaginons que sur notre serveur tourne un serveur web Apache2, et qu’on veut éviter toute indisponibilité, nous allons donc devoir surveiller le service afin de le redémarrer en cas de défaillance.

Pour cela, on doit effectuer une vérification du processus « apache2 » en précisant son fichier de PID à la suite de « with pidfile » pour que monit sache quel processus il doit surveiller.

Pour savoir si le service Apache est toujours disponible sur le port 80, pour notre serveur web, on testera le serveur web sur le port 80 avec le protocole HTTP. En cas d’erreur on redémarrera Apache2.

# apache2 correspond au nom du service
check process apache2 with pidfile /var/run/apache2.pid
# Commande d’arrêt et démarrage du processus
start program = "/etc/init.d/apache2 start"
stop program = "/etc/init.d/apache2 stop"
# Test du port 80 pour le serveur
if failed host srvweb.neoflow.fr port 80 protocol http then restart

On peut ajouter de nombreux autres paramètres, comme le contrôle de la charge CPU utilisé par ce processus, la charge mémoire, effectuer des requêtes de tests, etc…

Remarque : Afin de préciser le protocole de transport UDP ou TCP, on indique dans le test de contrôle « type udp » ou « type tcp »

VIII. Surveiller le service SSHD :

Sur le même principe que pour le processus Apache2, voici comment contrôler que le processus sshd correspondant au service SSH est bien actif :

# sshd correspond au nom du service
check process sshd with pidfile /var/run/sshd.pid
# Commande d’arrêt et démarrage du processus
start program = "/etc/init.d/ssh start"
stop program = "/etc/init.d/ssh stop"
# Test du port 22 pour le serveur
if failed port 22 protocol ssh then restart

Là aussi, on peut ajouter de nombreux autres paramètres, comme le contrôle de la charge CPU utilisé par ce processus, la charge mémoire, etc.

IX. Surveiller la somme SHA1 d’un fichier :

Un autre type de surveillance qu’il est possible d’effectuer est le contrôle de la somme MD5 ou SHA1 d’un fichier, qui correspond à une empreinte unique du fichier dans son état actuel. Dès qu’il y aura la moindre modification au sein du fichier surveillé, la somme changera forcément et donc une alerte sera déclenchée par monit.

Grâce à ça, vous pouvez vous assurer qu’aucun changement ne soit effectué sur des fichiers sensibles du système, notamment sur les fichiers de configuration. Nous allons prendre l’exemple du fichier « sshd_config » qui est le fichier de configuration du service SSH.

Il y a deux manières de faire ça avec monit, la première consiste à calculer une première fois la somme SHA1 puis d’indiquer à monit qu’il contrôle qu’elle soit bien égale à ça tout le temps. La seconde consiste à contrôler si la somme change et, si c’est le cas, on pourra se faire avertir. Nous allons mettre en place la seconde méthode.

Pour rappel, voici le chemin vers le fichier de configuration SSH :

/etc/ssh/sshd_config

En ce qui concerne le fichier « monitrc », voici ce que vous devez y ajouter :

# sshd_config correspond au nom du service
check file sshd_config path /etc/ssh/sshd_config
# Envoie d’une alerte si la somme SHA1 du fichier change
if changed sha1 checksum then alert

 X. Surveiller les permissions :

Il est aussi possible de contrôler les permissions sur un fichier, ce qui peut être intéressant de faire sur les fichiers de configuration, afin d’être sûr que personne n’effectue de changement grâce au calcul de la somme et que personne ne modifie les permissions grâce au contrôle sur les permissions.

Pour cela, il suffit de compléter le service « sshd_config » créé précédemment et d’ajouter la condition suivante :

if failed permission 644 then alert

Pour résumé le service, cela donnera :

# sshd_config correspond au nom du service
check file sshd_config path /etc/ssh/sshd_config
# Envoie d’une alerte si la somme SHA1 du fichier change
if changed sha1 checksum then alert
# Envoie d’une alerte si les permissions sont différentes de 644
if failed permission 644 then alert

 XI. Surveiller la taille d’un fichier :

Si vraiment on veut aller encore plus loin dans la surveillance du fichier “sshd_config” utilisé dans cet exemple, on peut également contrôler la taille du fichier et recevoir une alerte au cas où elle change.

Là encore, il suffit d’ajouter une condition à notre service, comme ceci :

# Envoie d’une alerte si la taille du fichier change
if changed size then alert

Il est également possible, grâce aux différents opérateurs de déclencher une action si la taille du fichier est « supérieure ou égale à », « strictement supérieure », « strictement inférieure », « différente de », etc…

XII. Gestion des alertes :

Vous avez dû remarquer que pour tous les types d’événements (restart, exec, start, etc.), monit envoie automatiquement une alerte par e-mail, si la configuration le permet. Toutefois, il est possible d’indiquer qu’on ne doit pas envoyer de mail pour tel et tel type d’événement d’un service, ou au contraire, de dire qu’on doit en envoyer seulement pour tel et tel type d’événement d’un service.

Ceci se rajoute dans la configuration de chaque service, on ajoute une ligne supplémentaire pour indiquer ce qu’on souhaite effectuer au niveau des alertes. Si l’on n’indique rien, une alerte sera envoyée pour chaque type d’événement.

Dans le cas de cet exemple, nous allons désactiver l’alerte pour l’événement de type « restart » sur le service « sshd ». Il faudra donc ajouter la ligne suivante dans la configuration du service concerné :

alert [email protected] but not on { restart }

Dans le cas contraire, si l’on souhaitait envoyer une alerte uniquement lors d’un événement de type “restart”, on aurait ajouté ceci :

alert [email protected] only on { restart }

N'hésitez pas à utiliser le forum pour poser vos questions et pour parler de vos éventuels problèmes.

Florian BURNEL Co-founder of IT-Connect

Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture.

See Full Bio