Introduction
Qu'est ce qu'une sonde ou un plugin?
Les sondes sont des exécutables compilés ou des scripts (Python, Perl, Shell, etc.) qui peuvent être lancés par une ligne de commande afin de vérifier le statut d'un hôte ou bien d'un check particulier sur un hôte. Shinken Enterprise utilise les retours de ces sondes pour déterminer le statut des éléments.
Shinken Enterprise lancera une sonde à chaque fois que ce sera nécessaire pour vérifier un statut. La sonde fait quelque chose (terme volontairement générique) pour procéder à la vérification en retournant simplement le résultat vers Shinken Enterprise qui prendra alors les actions nécessaires en fonction de ce retour (lancement d'événement, envoi de notifications, etc).
Les sondes à un niveau d'abstraction
De la même manière que pour Nagios (cf l'image ci contre), les sondes agissent à un niveau d'abstraction entre la logique de supervision présente dans les démons de Shinken Enterprise et les hôtes supervisés.
Le gros intérêt de l'approche "sonde" est que l'on peut superviser à peu près tout type d'élément.
Si vous pouvez automatiser le processus de vérification d'un élément, alors vous pouvez le faire avec Shinken Enterprise.
Il y a plusieurs milliers de sondes (ou plugins) créées pour superviser des ressources du type charge du processeur, utilisation disque, ping, etc..
Si vous souhaitez superviser quelque chose d'autre, référez vous au paragraphe Plugins API et créez le votre, c'est aussi simple !
| Panel |
|---|
|
Quels sondes sont disponibles ?
Shinken Enterprise est livré en standard avec un pack de sondes. Ces sondes sont placées dans le répertoire /var/lib/shinken/libexec et ces sondes sont utilisées par des commandes Shinken déjà créées lorsque vous installez Shinken Enterprise.
Si vous regarder comment est créé la commande depuis l'UI de configuration, vous verrez que la ligne de commande fait référence à la variable de remplacement $NAGIOSPLUGINS$ , $PLUGINSDIR$ ou encore $USERPLUGINSDIR$.
Ces variables sont globales, et déclarées depuis le fichier /etc/shinken/resource.d/paths.cfg et elle représente les chemins disques des sondes :
$NAGIOSPLUGINS$ :| Variable | Chemin | Description |
|---|---|---|
$NAGIOSPLUGINS$ | /usr/lib64/nagios/plugins | ce répertoire contient un certain nombre de sondes issues de Nagios |
$PLUGINSDIR$ |
/var/lib/shinken/ |
libexec | ce répertoire contient des sondes adaptées et utilisées spécifiquement pour Shinken Enterprise. Attention, les sondes de ce répertoire seront régulièrement mises à jour, ne pas les modifier. |
$USERPLUGINSDIR$ |
| /var/lib/shinken-user/libexec | ce répertoire vous permettra de placer vos propres sondes. Ce répertoire ne sera jamais modifié lors de mises à jour. |
Dans les répertoires $NAGIOSPLUGINS$ et $PLUGINSDIR$, il y a des sondes pour surveiller tout type d'éléments et services.
Ils utilisent des protocoles classiques WMI, SNMP, SSH, TCP, UDP, ICMP, LDAP et plus encore
Cela permet de surveiller à peu près tout:
Unix/Linux, Windows
Routeurs, Switches
services réseau: "HTTP", "POP3", "IMAP", "FTP", "SSH", "DHCP"
Charge CPU , utilisation disque, utilisation mémoire..
Applications, databases, logs et plus.
Récupérer des sondes
Vous pouvez en trouver beaucoup d'autres dans la communauté Nagios, et plus particulièrement dans les espaces suivants:
Monitoring Plugins Project: https://www.monitoring-plugins.org
Nagios plugin exchange: https://exchange.nagios.org/
Comment utiliser la sonde X?
La plupart des sondes présentent des informations de type utilisation en les exécutant avec l'extension "-h" ou "--help" dans la ligne de commande.
Par exemple, si vous voulez savoir comment fonctionne la sonde _http plugin works ou quelles options sont possibles, vous devez lancer la commande suivante :
| Code Block | ||
|---|---|---|
| ||
./check_http --help |
| Anchor | ||||
|---|---|---|---|---|
|
API de sonde
Concept de sonde
Les scripts et les exécutables doivent faire au moins 2 choses :
- sortir avec l'une des nombreuses valeurs possibles en retour (code retour)
- retourner au moins une ligne de texte vers "STDOUT"
Le fonctionnement interne de la sonde importe peu à Shinken Enterprise, c'est l'interface entre eux deux qui compte.
Votre sonde peut vérifier le statut d'un port TCP, lancer une requête sur une base de données, ou faire tout ce qui est nécessaire pour vérifier un élément.
Les détails dépendront ce qui doit être vérifié.
Code retour :
Shinken Enterprise détermine le statut d'un hôte ou d'un check en évaluant le code retour de la sonde .
La table suivante montre la liste des valeurs possibles, avec leur correspondance possible.
| Code retour | Etat du Service | Etat de l'hôte |
|---|---|---|
| 0 | OK | UP |
| 1 | WARNING | DOWN |
| 2 | CRITICAL | DOWN |
| 3 | UNKNOWN | DOWN |
ligne de texte vers "STDOUT" [Format de sortie des données de sonde]
Au minimum, la sonde doit retourner une ligne de texte. La sonde peut également retourner en option des données de performance pour la métrologie.
Le format standard de sortie d'une sonde est le suivant :
TEXT OUTPUT | OPTIONAL PERFDATA
Les données de performance sont optionnelles.
Si une sonde retourne des données de performance, elles doivent être séparées du reste du texte par le symbole pipe (|) .
Exemples de retour de sonde
Voyons quelques exemples possibles
Cas 1: une ligne de retour (texte seulement)
Imaginons une sonde qui retourne une ligne telle que décrite en dessous :
| Code Block | ||
|---|---|---|
| ||
DISK OK - free space: /var 3326 MB (56%); |
Si cette sonde est utilisée pour réaliser une vérification de service, la totalité de la ligne retour sera stockée dans $SERVICEOUTPUT$ .
Cas 2: une ligne de retour (texte et données de performance)
La sonde peut retourner en option des données de performance utilisable par une application tierce. Dans ce cas, les données de performance doivent être séparées par le symbole pipe (|) :
| Code Block | ||
|---|---|---|
| ||
DISK OK - used space: /var 3326 MB (56%); | /var=3326 |
Si cette sonde est utilisée pour vérifier un service, la partie à gauche du symbole sera stockée dans <$SERVICEOUTPUT$> et la partie à droite du séparateur sera stockée dans $SERVICEPERFDATA$
Une donnée de performance est composée au minimum de :
| Code Block |
|---|
key=value |
Par exemple:
/var=3326
Vous pouvez alors avoir en option plus d'informations :
key=valueUNIT;warning;critical;minimumvalue;maximalvalue
For example:
/var=3326MB;5948;5958;0;5968
Vous pouvez avoir une série de données de performance séparées par un espace :
| Code Block |
|---|
HTTP OK: HTTP/1.1 200 OK - 20156 bytes in 0.271 second response time |time=0.270634s;;;0.000000 size=20156B;;;0 |
Taille maximum du retour d'une sonde
Shinken Enterprise va seulement lire les premiers 64 KB de données qu'une sonde retourne. Cela évite de surcharger une base de données.
PREVOIR UNE SECTION AVEC :
path des sondes
variables globales resources.d
1/ télécharger et placer le script/sonde dans /var/lib/shinken-user/libexec/
(pour info, depuis shinken, ce chemin sera accessible via la variable de remplacement $USERPLUGINSDIR$ )
2/ pour donner les droits d'exécution : chmod +x monscript.py
3/ Ouvrir l'interface utilisateur (UI) de configuration et créer une commande "cmd_monscript" (par exemple) avec la ligne de commande suivante : $USERPLUGINSDIR$\monscript.py
4/ Créer un modèle d'hôte, par exemple : "monmodele"
5/ Pour appliquer systèmatiquement le script lors de l'application de "monmodele" à un hôte, créer un "check dédié à modèle d'hôte", par exemple check_monscript (cf par exemple le check dédié "http")
Mettre le modèle "monmodèle" dans la propriété "Attaché sur les modèles d'hôte"
La commande de vérification doit pointer vers la commande cmd_monscript
6/ Appliquer le modèle "monmodèle" à des hôtes, le check doit bien appliquer, vous pouver l'essayer le check depuis l'onglet "Checks"