Salut à tous, vous avez été très nombreux (plus de 150 !) à me demander si le script shell bash pour Linux que j’ai présenté au cours de mon dernier live coding intitulé « Live coding : un script de monitoring serveur complet en BASH sous Linux » pouvait être mis en ligne. Pour ceux qui veulent voir ou revoir la vidéo, elle est disponible ci-dessous.
Petites explications que j’ai eu l’occasion de donner au cours de mon dernier live général : attention, il y a quelques différences entre les scripts que je vous montre dans mes live coding et leur version « finale ». Pourquoi ? Simplement, parce que je vous montrer le « squelette », la partie commune et fonctionnelle qui vous permet de vous aiguiller et de créer par la suite vos propres outils.
En ce qui me concerne, comme ils ont généralement des objectifs spécifiques, je les adapte ensuite à mes propres besoins. Ainsi même si vous y trouverez la même chose que dans mon live coding, ce sera toujours en général une version plus élaborée et adaptée à mes besoins. Ce script ne fait pas exception. De plus il sera régulièrement mis à jour.
Du coup pour le télécharger, il vous suffit d’utiliser le lien suivant : sms.sh . Je vous mets également quelques informations complémentaires sur le fonctionnement du script plus bas.
Dans la pratique, voilà à quoi ressemble la page générée :
Tout d’abord, j’ai placé le script sous licence GPL 3.0. Ensuite, il faut savoir qu’à la base, ce script via en complément d’une application beaucoup plus lourde qui est une sorte de gros « stack deployer » qui me sert à livrer des clients. Donc certains éléments qu’utilisent le script sont normalement générés automatiquement par le deployer. Je vous ai rajouté un maximum d’informations dans les commentaires en début de fichier mais je reprends ici les principales informations.
1) Ce script effectue une sortie en html, il est fait pour être intégré dans un langage web dynamique tel que php, python, etc. Voici un exemple d’intégration en php :
Pensez bien à ne pas mettre votre script (et encore plus votre fichier credentials) dans un répertoire non listable par votre serveur web..
2) Le logo qui s’affiche normalement dans le script est disponible ici : ScalarX.jpg. Il vous suffit donc de remplacer soit le nom de fichier dans le script, soit de mettre un fichier du même nom à la place pour y mettre votre propre logo par exemple ou de télécharger le fichier et de le mettre dans la même racine que votre script php, python ou autre pour garder son format d’origine.
3) Je n’utilise pas ce script de manière « directe » : en fait dans mon cas je fais un call API chez pingdom (ou sur n’importe quel plateforme de monitoring qui le permet), afin de rajouter un check qui mentionne un certain nombres d’informations dont l’url de la page (générée d’après un algo propre au deployer), qui vient check si la page contient le mot « ERROR« . Si c’est le cas, alors une alerte est envoyée (que je reçois via différentes voies tel que Telegram), email, sms et qui contient le lien : il me suffit alors de cliquer sur le lien pour avoir, avant même de lancer ma connexion la liste de tout ce qui cloche (ou du moins qui m’intéresse au premier abord).
4) Le fichier process2monitor.txt contient la liste de tous les processus à monitorer. Là encore dans mon cas, ce fichier est généré automatiquement par serveur. Voici un exemple de ce que contient le fichier dans l’exemple de la vidéo :
apache2
fail2ban-server
memcached
miniserv.pl
php-fpm5.6
php-fpm7.0
php-fpm7.1
php-fpm7.2
php-fpm7.3
php-fpm7.4
php-fpm8.0
pure-ftpd
sshd
Note : le nombre entre parenthèses à coté de chaque processus dans le rendu de monitoring indique le nombre de processus en cours d’exécution pour chacun.
5) Le fichier fs_list.txt contient l’ensemble des points de montage qui sont sensés être présents sur la machine. Contrairement au check disque que vous trouverez dans le code et qui permet de tester l’espace et le nombre d’inodes disponibles sur chaque partition, le fs_list.txt est généré à l’installation de la machine (et upgradé en fonction des modifications). Il permet de savoir si un point de montage qui est censé être monté est présent ou pas sur le système. Le check d’espace et d’inodes et lui totalement dynamique et s’applique automatiquement à l’ensemble des systèmes de fichiers.
Là encore ceci est généré automatiquement de mon coté lors du deploy des serveurs, via des commandes tel que :
grep -v '#' /etc/fstab |awk '{print $2}' > fs_list.txt ou encore grep 'sshfs' /etc/fstab |awk '{print $2}' >> fs_list.txt pour les filesystem sshfs par exemple, etc. Il faut donc adapter à votre besoin.
Exemple du contenu du fichier fs_list.txt :
/
/datastore
/datadrop/cd101
6) Un fichier de configuration est utilisé. Il est déclaré en début de script de cette manière :
CONF_FILE="/home/sx/.sx" # Replace by your config file
Exemple de contenu pour les entrées qui vous intéressent :
loginsxmysql:sx
passsxmysql:prxotpoofas
L’utilisateur doit avoir le droit sur une database désignée seulement d’effectuer les opérations nécessaires. Si vous avez besoin d’utiliser le check de réplication MySQL (que je ne montre pas dans la vidéo mais que j’ai intégré ensuite, il faudra également que l’utilisateur est les droits lui permettant de checker la réplication.
7) Les options des fonctions
En fin de fichier vous trouverez une liste de fonctions appelées qui servent à générer l’ensemble de la page, cela donne :
startpage "StackX Local monitoring"
title "StackX Monitoring System"
table_init
titlecheck "Server process"
all_process_check
internet_check 1.1.1.1 8.8.8.8
dns_check google.com cloudflare.com
fs_check
center_column
mysql_check $LOGINSXMYSQL $PASSSXMYSQL 0
memcached_check 127.0.0.1 11211
disk_check 95 90 95 90
mem_check 95 90
load_check
table_end
endpage
internet_check : supporte autant d’argument que souhaité (je me sers de ces 2 ips pour savoir si la connexion vers internet en général semble ok, mais vous pouvez en ajouter ou en supprimer.
dns_check : supporte également autant de sites que vous souhaitez (attention à la durée des requêtes si vous en mettez beaucoup, cela rallongera d’autant le temps de génération de la page)
fs_check : si vous souhaitez que ce check soit actif (voir point 5 plus haut), il faut également rajouter le paramètre yes, ce qui donne fs_check yes
mysql_check : si le 3eme paramètre est passé à 1 au lieu de 0 il ajoute les checks de réplication MySQL (donc à utiliser uniquement dans le cadre de serveurs répliqués).
disk_check : vous pouvez changer les différents niveau de seuil (error, et warning pour l’espace et le nombre d’inodes en paramètres). Par défaut c’est réglé sur 95% pour ERROR et 90% pour le niveau warning.
memcached_check : vous pouvez préciser l’adresse ip et le port. Par défaut c’est réglé sur localhost et le port par défaut 11211. Si vous avez 4 instances de memcached différents vous pouvez répéter le check autant de fois que nécessaire : cela fonctionne aussi bien local que pour check des serveurs distants.
mem_check : supporte également 2 niveau : ERROR et WARNING. Comme pour disk_check vous pouvez régler les seuils dans les paramètres de la fonction qui sont réglés là encore sur 95% et 90%
load_check : n’utilise pas de paramètres dynamiques, mais vous pouvez changer la méthode dans le code au besoin. Actuellement le seuil d’alerte est fixé en multipliant par 2 le nombre de core/thread disponible sur la machine (c’est donc une valeur dynamique). Ensuite, il y a aussi une variable WAIT_B4_CHECK : elle indique le nombre de secondes d’attente entre 2 checks. Là encore, attention au temps de génération de la page si vous l’utilisez de cette manière. Que fait cette fonction ? Elle effectue une première mesure de la charge machine, puis elle attends le temps prévu (1 seconde par défaut), dans la variable WAIT_B4_CHECK puis effectue une seconde mesure.
Si la charge mesurée est inférieure au seuil elle réponds OK. Si la charge mesurée est supérieure au seuil mais que cette charge est en cours de diminution alors elle renvoie un WARNING. Enfin si cette charge est supérieure au seuil et continue d’augmenter elle génère ERROR pour déclencher une alerte.
Si vous avez un doute sur les valeurs à utiliser je vous renvoie à ma vidéo explicative sur la charge moyenne / le load average disponible ici :
Vous pouvez bien entendu rajouter très simplement vos propres check, des banner grabber, etc. J’ai mis un exemple dans les commentaires en début de script également.
Addendum : je viens de rajouter une petite fonction, le livecoding est disponible ici :
Sur ce, enjoy !
—
Christophe Casalegno (Brain 0verride)
Laisser un commentaire