Créer son plugin de supervision

I. Présentation

Nous aborderons ici les principaux éléments nécessaires pour écrire son plugin de supervision. Pour rappel, les plugins, ce sont des scripts exécutés pour réaliser un contrôle. Ils retournent des informations qui seront ensuite interprétées par le système de supervision. Les plugins sont intégrables à n’importe quel outil de supervision du moment qu’il interprète de manière identique les retours décrits dans cet article. À ma connaissance, je n’ai pas d’exemple d’outils ne respectant pas ces règles.

Ici le but est de comprendre le principe du plugin afin que vous puissiez ensuite adapter le vôtre. Vous pourrez l’écrire dans le langage de votre choix, à vous de voir ce qui est le plus adapté pour votre script. Vous trouverez souvent en cherchant un peu sur le net un script qui correspond à vos besoins. Parfois, ils ne seront pas totalement adaptés ou bien pires, vous ne trouverez pas ce que vous cherchez! Dans ce cas vous devez vous lancer dans la création de votre plugin. Ou bien vous pouvez le faire tout simplement pour le fun :). Ready ?!

II. Les codes de retour

La première base indispensable pour votre plugin, retourner un code pour déterminer l’état de votre contrôle. Selon le « type » de votre plugin (hôte ou service) les codes retournés seront différents :

Pour un hôte :

• 0 : UP
• 1 : DOWN

Pour un service :

• 0 : OK
• 1 : WARNING
• 2 : CRITICAL
• 3 : UNKNOWN

En théorie vous n’aurez jamais besoin d’écrire un plugin pour un contrôle d’hôte. Le contrôle d’hôte détermine si votre équipement est en vie ou non. Par défaut (et dans la majorité des cas) c’est un ping et ça fait son job !

III. Messages de sortie

La deuxième partie à retourner dans votre script sont les messages de sorties. Ils sont de 3 types :

A. OUPUT

Il donne un descriptif rapide du contrôle. C’est le minimum obligatoire, sa taille est limitée à 255 caractères.

Cette sortie sert dans l’affichage des contrôles. Ses données :

Vous pourrez récupérer ces valeurs sur votre système de supervision dans la macro $SERVICEOUTPUT$.

B. LONGOUTPUT

Cette sortie donne les détails sur le contrôle effectué. Elle sert à retourner des informations complémentaires à la sortie principale. Elle n’est pas obligatoire, vous pourrez récupérer ces valeurs sur votre système de supervision dans la macro $LONGSERVICEOUTPUT$.

C. PERFDATA

Ou données de performances. Optionnels également, elles sont utilisées pour générer des graphiques. La sortie des données de performance est « normalisée » afin d’élargir les compatibilités entre les outils.

Voici une sortie complète de type perfdata : ‘label’=value[UOM];[warn] ;[crit];[min];[max]

Seuls le label et la valeur mesurée sont obligatoires. Si le label contient des espaces, il faut l'entourer de simples quottes. Concernant les unités, vous avez le choix parmi les suivantes.

• Secondes : us, s et ms
• Bytes : B, KB, MB, GB, TB
• Pourcentage : %
• Nombre entier : c

Ces données stockées précieusement permettront de créer des graphs. Vous pourrez retourner plusieurs séries de données de performances, sur vos graphs apparaitrons alors une courbe pour chaque série. Pour différencier deux séries, entre chacune d’entre elles nous mettrons un espace.

Exemple :

/=1300MB;15329;17244;0;19159 /home=1300MB;15329;17244;0;19159

IV. Mettre en forme la sortie

Comme précisé juste avant, tout plugin doit retourner au moins une ligne de texte sur la sortie standard et renvoyer un code de retour compris entre 0 et 3. On appelle la sortie standard STDOUT.

Prenons le script, ou plutôt les lignes de code suivantes en bash :

#!/bin/bash
echo "Attention j'ai un code 2!"
exit 2

Avec ce code vous retournez le strict minimum, vous avez une sortie texte, et un code 2. Si vous voulez intégrer les données de performances, il faudra les séparer de votre sortie texte avec le pipe (|) comme ceci :

#!/bin/bash
echo "Attention j'ai un code 2! | graph1=5000MB;15000;17000;0;19000"
exit 2

Pour rajouter encore une nouvelle sortie texte contenant des informations complémentaires vous pouvez le faire sur la ligne du dessous :

#!/bin/bash
echo "Attention j'ai un code 2! | graph1=5000MB;15000;17000;0;19000"
echo "Pour rappel 2 = critique!"
exit 2

Si vous souhaitez ajouter de nouvelles données de performances, vous pouvez le faire sur la 2eme ligne. Mais toujours avec le pipe pour séparer. Après le pipe, vous pourrez ne mettre que les perfdata. N’oubliez pas qu’il est possible de mettre plusieurs séries de donnés à suivre séparés par un espace, ci-dessous un exemple sur la ligne 2.

#!/bin/bash
echo "Attention j'ai un code 2! | graph1=5000MB;15000;17500;0;20000"
echo "Pour rappel 2 = critique! | ‘graph 2’=16000MB;15000;17500;0;20000 graph_3=18000MB;15000;17500;0;20000"
exit 2

À savoir que votre système se fiche complètement de ce que contient votre script entre la 1ere ligne et la sortie. Il interprète le retour qu’il reçoit, point final. Ceci veut dire qu’en passant ces 3 bouts de code comme un plugins et qu’on simule un contrôle, on obtient ça :

Le code 2 remonte bien une erreur critique et on repère bien la sortie OUTPUT. En cliquant sur les détails nous pourrons avoir la sortie complémentaire LONGOUTPUT et les PERFDATA.

V. Conclusion

Vous avez tous les éléments pour renvoyer une sortie propre et interprétable à votre système de supervision. À vous d’écrire le contenu du script. Je ne suis pas le mieux placé pour donner des conseils en développement, mais essayez d’optimiser au maximum votre code. C’est aussi avec des scripts de qualité qu’on assure la performance d’un système de supervision.

Cyprien Santana

Geek raisonnable, passionné par le "bidouillage" et les nouvelles technologies. Je viens ici pour partager mes connaissances avec vous ! Je travaille beaucoup sur les réseaux et la sécurité, avec une petite touche supervision. Je viens aussi en tant que lecteur sur IT-Connect pour augmenter mon capital connaissance ;)

See Full Bio