Dans l’administration de tout système, une partie très importante est d’avoir un système de monitoring et d’alertes pour tout incident pertinent. Il existe actuellement de multiples systèmes open source créés et pensés à cet effet, certains simples et d’autres très complexes avec différentes approches et finalités. Ce n’est pas la même chose de surveiller des serveurs homogènes que des routeurs via SNMP ou un mélange de différents OS, clusters, clouds…
L’un de mes préférés est monit pour les serveurs Linux/*BSD. C’est un « simple » programme écrit en C léger par définition avec une polyvalence difficilement égalable par d’autres « agents » avec une conception KISS qui m’a séduit dès le début et qui avec de l’imagination vous permet d’avoir le parfait gardien de votre serveur pour tout événement que vous pouvez imaginer.
Le complément idéal de monit est M/Monit. Un panel centralisé auquel monit peut, si vous le configurez, envoyer toutes ses métriques et alertes et de façon unifiée avoir une vue de tous vos systèmes. Le seul inconvénient de M/Monit est qu’il n’est pas open source et nécessite une licence, mais c’est l’un des rares logiciels non open source que je peux recommander et qui vaut la peine d’acquérir sa licence, tant pour son coût relativement faible que pour sa grande valeur ajoutée. De plus ce sont les mêmes développeurs que monit, qui lui est open source, et à lui seul est déjà un outil indispensable. En acquérant la licence de M/Monit vous aidez à améliorer monit.
Mais concentrons-nous sur « monit » puisque dans de nombreux cas il sera suffisant pour les petites infrastructures. Son avantage comme je l’ai mentionné est sa légèreté comme processus en cours d’exécution, étant écrit en C il est très léger en consommation, idéal même pour les systèmes embarqués. Il est autonome et opère tout en offrant un petit panel web qui montre l’état des différents services/événements surveillés et vous permet d’effectuer certaines actions comme arrêter ou redémarrer des services. Sa configuration bien qu’elle puisse intimider initialement est très bien pensée et permet de surveiller tout ce que vous pouvez imaginer sur votre système puisqu’en plus des « checks » intégrés il vous permet d’utiliser n’importe quel programme externe comme source d’événements à surveiller, cette possibilité combinée avec des scripts shell vous donne des options où la seule limite est votre imagination.
Voyons un cas pratique sur un serveur FreeBSD.
Pour réaliser l’installation nous pouvons utiliser le playbook Ansible simple suivant :
- name: Install monit
pkgng: name=monit state=present
- name: create monit directories
file: path={{item}} mode=0700 state=directory
with_items:
- /usr/local/etc/monit
- /usr/local/etc/monit/scripts
- /usr/local/etc/monit/conf.d
- /var/lib/monit
- /var/lib/monit/events
- name: monit logrotation
copy:
src: newsyslog.conf
dest: /usr/local/etc/newsyslog.conf.d/monit.conf
mode: 0600
- name: copy monit conf
template: src=monitrcdest=/usr/local/etc/monitrcowner=0 group=0 mode=0600
- name: enable monit on boot
service: name=monit enabled=yes state=started
Le contenu du template monitrc de base :
set daemon 10 with start delay 10
set logfile /var/log/monit.log
set pidfile /var/run/monit.pid
set idfile /var/lib/monit/id
set statefile /var/lib/monit/state
set mailserver 127.0.0.1
set alert [email protected] not on { instance, action }
set httpd unixsocket /var/run/monit.sock
uid root
gid wheel
permission 0600
allow root:CHANGEMEPASS
set eventqueue
basedir /var/lib/monit/events
slots 100
include /usr/local/etc/monit/conf.d/*
check system $HOST
if memory usage > 90% for 10 cycles then alert
if swap usage > 20% for 10 cycles then alert
if cpu usage (user) > 80% for 10 cycles then alert
if cpu usage (system) > 30% for 10 cycles then alert
if cpu usage (wait) > 10% for 10 cycles then alert
Le fichier /usr/local/etc/newsyslog.conf.d/monit.conf :
/var/log/monit.log root:wheel 640 7 * $W1D01 JC /var/run/monit.pid
Comme vous l’aurez remarqué, vous avez besoin d’un serveur SMTP actif pour envoyer les alertes, cela est normalement installé par défaut sur tout serveur Unix même si c’est uniquement pour l’envoi de logs. Vous devez également indiquer l’email où les alertes seront envoyées et établir un user/password que le client monit en console utilisera pour effectuer des opérations avec le daemon monit lui-même (monit est à la fois le serveur et le client CLI local).
Avec cette simple configuration de base nous avons déjà la mémoire et le CPU de notre serveur surveillés avec des alertes. La vérification se réalise à intervalles de 10s (set daemon 10 with start delay 10).
Dans cette configuration le port HTTP du serveur web intégré est désactivé, je me débrouille beaucoup mieux en console qu’avec un panel web et je préfère, si ce n’est pas nécessaire, éviter d’avoir tout port TCP ouvert, d’autant plus si celui-ci s’exécute avec des privilèges root même si en principe c’est une application sûre et bien programmée (tout est susceptible d’avoir un exploit caché).
À partir de là les options incluses dans monit lui-même sont multiples et je vous recommande vivement de consulter sa documentation (https://mmonit.com/monit/documentation/monit.html) et son wiki avec des exemples (https://mmonit.com/wiki/Monit/ConfigurationExamples)
Si vous voulez connecter monit avec M/Monit il suffit d’indiquer dans sa configuration une ligne comme la suivante :
set mmonit https://USER:PASS@MONITSERVER:25083/collector
Avec cela (et après avoir créé le user/password correspondant dans M/Monit), en plus des notifications et alertes vous aurez disponible un panel avec des graphiques et un historique très polyvalent et utile, surtout si vous souhaitez voir l’évolution d’un système dans le temps et le comparer avec d’autres serveurs. Si vous ne voulez pas utiliser M/Monit et utiliser uniquement les alertes de monit vous pouvez toujours recourir à un autre outil simple comme Munin pour les graphiques installé sur le serveur local lui-même mais c’est une autre histoire.
Voyons maintenant un autre exemple de la polyvalence de monit, bien que par défaut il n’ait pas de « check » pour vérifier la température du CPU nous pouvons créer une alerte très simplement avec un script shell. Dans le cas de ce serveur FreeBSD nous utiliserons l’application hwstats et ce simple script que nous créerons dans /usr/local/etc/monit/scripts/cpu1temp.sh :
#!/bin/sh
TEMP=`/usr/local/bin/hwstat |grep CPU10|awk '{print $2}'|cut -d '.' -f 1`
echo $TEMP
exit $TEMP
Dans monit nous ajouterons le check suivant :
check program CPUTemp1 with path "/usr/local/etc/monit/scripts/cpu1temp.sh" timeout 2 seconds
if status > 80 for 3 cycles then alert
De cette façon, toutes les 10s, la température du CPU sera vérifiée et si pendant 30s (3 cycles) la température du CPU est supérieure à 80 degrés une alerte sera envoyée.
Facile non ?