Bien appréhender la Supervision… Partie 3

Cet article fait suite à :  Bien appréhender la Supervision… Partie 2

8. Les sondes ou moniteurs (le cœur des fonctionnalités)

On est ici dans le cœur du sujet puisque ce sont ces fameuses sondes qui vont être chargées de se connecter aux différents objets à superviser afin de faire remonter à la solution de supervision des valeurs (numériques, logiques ou texte principalement), valeurs que l'on pourra comparer aux valeurs que l'on juge « acceptables » pour un système donné ou, tout simplement à des fins de stockage pour des fonctions de reporting et non d'alarmes, quelques exemples simples :

• si le CPU global de la machine est inférieur à 75 %, alors c'est OK !
• Si le processus X utilise entre 50 et 100Mo de mémoire, c'est OK !
• Si la taille du fichier Y est supérieure à 20Mo, c'est pas OK !
• Si le service ou démon W est lancé, c'est OK !
• Si l'hygrométrie de la salle serveur No1 est comprise entre 45 et 55 % d'humidité, c'est OK !
• Si le fichier Z est présent, c'est pas OK !
• Si le fichier test.txt n'est pas âgé de plus de 24 heures alors c'est OK !

Ou un peu plus avancés :

• si la taille du disque A est supérieure de plus de 2 % par rapport au dernier test, c'est pas OK !
• Si la page web B ne contient pas la chaîne « Site institutionnel de la Sté ABC » n'est pas présente, alors c'est pas OK (un « défaçage » ?) !
• Si la requête Y sur la base de données A renvoie une valeur supérieure à 10000, alors c'est OK !
• Si la valeur renvoyée par le script A multipliée par celle renvoyée par le script B est inférieure à 100 alors c'est OK !

En fait il n'y a pas de limites dans ce que l'on peut imaginer en terme de sondes et c'est là qu'il faut faire attention ! Pourquoi ? Autant il est facile de mettre en place 50 sondes différentes pour un même système autant il est compliqué d'en analyser les résultats voire de documenter les actions à entreprendre au cas où la valeur renvoyée par le système de supervision ne correspond pas tout à fait à la valeur attendue…

Il faut donc y aller par étapes successives en commençant par les éléments qui s'avèrent les plus critiques pour vous et en peaufinant par la suite… Effectivement à quoi cela sert d'avoir 50 alarmes à traiter si vous ne pouvez décemment pas en traiter plus de 3 ou 4 à la fois…

Une bonne pratique consistant, au début, à établir un modèle de sondes (ex. je définis une dizaine de moniteurs que j'applique à tous mes serveurs CentOS) et, ensuite, à chaque incident qui n'aurait pas été détecté par mon système de supervision je me pose la question suivante : Quelle sonde dois-je mettre en place afin que cet incident soit détecté avant même que les utilisateurs ne s'en rendent compte ou, au pire, au même moment... Car c'est quand même à cela que sert un tel outil avant tout !

En fonction des capacités de l'outil de supervision, vous aurez à votre disposition tout un tas de sondes « prédéfinies » qui vont vous permettre d'avancer plus vite, à l'inverse, il faudra mettre les mains dans le cambouis pour « scripter » vous-mêmes les sondes dont vous avez besoin à partir des ressources fournies par la solution de supervision que vous avez choisi de mettre en œuvre.

On pourrait répartir les sondes dans différentes familles telles que :

• les moniteurs dits de performances (CPU, RAM, Utilisation d'un disque, Bande passante...etc) qui sont là pour détecter la dégradation d'un « service »,
• les moniteurs concernant les processus qui, en général, vous alertent quand un processus (ou service) ne tourne pas « rond »,
• les moniteurs spécifiques aux bases de données, permettant entre autres, d'effectuer des requêtes sur les principales bases de données du marché,
• les moniteurs dédiés aux services « d'annuaires » tels qu'un ActiveDirectory, un LDAP, un DHCP, un DNS,
• les moniteurs nécessaires à l'analyse de logs (Eventlog de Windows, autres logs, interception de messages Syslog…),
• les moniteurs utilisant des scripts et qui du coup n'ont aucune limite sauf celle de votre imagination,
• les moniteurs dédiés aux services « Réseaux » (FTP, NTP, Ping, SSH2, Telnet, TFTP, TS,TCP,UDP …),
• les moniteurs dédiés aux services et serveurs Web et de messagerie (HTTP, HTTPS, IMAP, POP, SMTP…) permettant, par exemple, de vérifier la date de péremption d'un certificat,
• les moniteurs spécifiques aux sondes dites « environnementales » telle une sonde de température par exemple,
• les moniteurs SNMP permettant soit d'effectuer des requêtes sur un OID donné et de comparer la valeur reçue à une valeur prédéfinie, soit de détecter et de filtrer les traps envoyées par un périphérique SNMP,
• des moniteurs spécialisés dans l'analyse d'un système de fichiers comme la taille ou l'ancienneté d'un fichier, la taille ou le nombre de fichiers dans un dossier.

En voilà une belle panoplie non ?

Ensuite, c'est à vous de jouer et à tout organiser afin que cela ne ressemble pas rapidement à une usine à gaz qui clignote de partout, qui envoie 1000 mails par jour, et qui devient vite ingérable…

Rappelez-vous : trop d'alarmes tue l'alarme !

Enfin, il conviendra également de bien réfléchir à la manière dont les alarmes doivent être acquittées ou pas ! Il existe plusieurs écoles :

• celle qui permet à un utilisateur de « valider » (dans le sens « acquitter ») une alarme pour un temps donné ou pour toujours sous-entendant qu'il a pris le problème en charge…
• Celle qui laisse le voyant au rouge tant que le problème n'est pas résolu, c'est celle-ci que je préfère…
• Celle qui passe la main au système de gestion du support (du ticketting), c'est-à-dire qu'à chaque alarme un ticket de support est automatiquement généré pour être traité comme n'importe quelle autre demande de support, ce qui est en général constaté dans les grandes organisations.

9. Un outil de reporting (un minimum s'impose…)

Une solution de supervision digne de ce nom doit posséder des fonctions de « reporting » minimales et faciles d'accès, telles que :

• éditer un rapport sur les alarmes des 4 ou 24 dernières heures (c'est utile quand vous n'êtes pas aux manettes et que vous voulez savoir ce qui s'est passé la veille…),
• éditer un rapport sur toutes les alarmes d'un ou de plusieurs « systèmes » donnés, sur une date ou sur une période données,
• éditer un rapport sur une famille de moniteurs donnée (ex. toutes les alarmes dites de performances),
• éditer un rapport sur tous les moniteurs qui ont été désactivés ou qui sont en maintenance, très utile quand on commence à avoir plusieurs centaines ou plusieurs milliers de sondes,
• éditer un rapport de type « Bilan de santé » pour tout ou partie du SI vous permettant, en un seul coup d’œil, de voir quels systèmes sont souvent en alarme ou tout simplement d'établir un véritable rapport de qualité de services si vous êtes un fournisseur de type hébergeur par exemple…

En fonction de vos besoins, vous aurez peut-être envie également de connecter votre propre outil de reporting à la base de données contenant les données de votre système de supervision et concocter ainsi des rapports correspondant exactement à vos besoins.

Enfin, toutes les données récoltées par votre outil de supervision vont également vous servir à provisionner vos besoins futurs en terme de puissance de calcul, de mémoire, de stockage, etc...

En conclusion…

Dans cet article, en trois parties, je me suis efforcé a ne pas parler « technique » ni à citer une seule fois le nom d'une solution de supervision, car l'objectif n'était pas là !

Comme vous avez pu le constater, le « fonctionnel » est riche et l'organisation est le maître mot avant de se lancer dans une telle aventure au risque de se retrouver avec une solution que tout le monde fuit et qui est remise en cause à tout bout de champ par vos collaborateurs !

Dans les petites organisations on fera surtout attention à y aller par étapes et sachez que plusieurs mois, voire plusieurs années seront nécessaires pour arriver à une solution aboutie. Dans les organisations plus grandes, une équipe est dédiée plein-temps à la gestion de l'outil de supervision qui devient alors un des maillons les plus importants du SI.

LeCastillan

D.S.I autodidacte d'une E.T.I (Entreprise de Taille Intermédiaire) de 400 personnes ayant une activité internationale 24/7 - Passionné - Aime écrire - Aime les choses "simples" - Aime la Liberté - Aime l'Open Source - Curieux - Pragmatique...

See Full Bio