Votre serveur Nagios est prêt, vous savez comment l’installer et comment il fonctionne. Il est maintenant temps de construire des éléments de supervision. Dans ce chapitre, je vous propose de détailler le fonctionnement du plugin check_http. À partir de son exécution initiale, vous apprendrez comment optimiser ses paramètres, et utiliser les seuils, pour modéliser une sonde au plus près de votre besoin.
Avant toute chose, vous allez vérifier que la présence et le bon fonctionnement du plugin check_http.
1. Vérifiez que le compte « nagios » peut exécuter le plugin
Dans cette démarche, il ne faut surtout pas oublier d’effectuer vos tests sous le compte nagios, car c’est sous ce compte que le service Nagios tourne et qu’il effectuera ses propres exécutions de plugins. Il arrive souvent que les tests effectués avec un utilisateur privilégié (comme root par exemple) ne fonctionnent plus une fois exécutés avec le compte nagios.
Depuis votre terminal de connexion, vérifiez votre identité avec la commande suivante :
nagios@NagiosDebian:~$ id
uid=1000(nagios) gid=1000(nagios) groupes=1000(nagios),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev),111(bluetooth),1001(nagcmd)Vous devez obtenir l’UID et le GID correspondants au compte nagios.
Rendez-vous ensuite dans le répertoire des plugins de Nagios avec la commande suivante :
nagios@NagiosDebian:/usr/local/nagios$ cd /usr/local/nagios/libexec/
nagios@NagiosDebian:/usr/local/nagios/libexec$Pour vérifier le fonctionnement du plugin, lancez-le simplement à l’aide de la commande suivante :
nagios@NagiosDebian:/usr/local/nagios/libexec$ ./check_httpSi le plugin est bien compilé et installé, cette commande doit produire la sortie suivante :
check_http: Impossible de décomposer les arguments Utilisation: check_http -H <vhost> | -I <IP-address> [-u <uri>] [-p <port>] [-J <client certificate file>] [-K <private key>] [-w <warn time>] [-c <critical time>] [-t <timeout>] [-L] [-E] [-a auth] [-b proxy_auth] [-f <ok|warning|critcal|follow|sticky|stickyport>] [-e <expect>] [-d string] [-s string] [-l] [-r <regex> | -R <case-insensitive regex>] [-P string] [-m <min_pg_size>:<max_pg_size>] [-4|-6] [-N] [-M <age>] [-A string] [-k string] [-S <version>] [--sni] [-C <warn_age>[,<crit_age>]] [-T <content-type>] [-j method]
Le plugin a répondu qu’il ne parvenait pas à « décomposer les arguments ». Vous pouvez constater qu’il attend au moins un argument de manière obligatoire :
-H <vhost>, pour indiquer une adresse de type URL, ou-I <IP-address>, pour indiquer directement une adresse IP, si vous ne souhaitez pas effectuer une requête DNS lors de l’exécution du plugin. Ce choix n’est pas du tout anodin : s’il y a beaucoup de sondes HTTP, éviter au serveur Nagios de faire des requêtes DNS pour chacune d’entre elles peut lui faire économiser beaucoup de ressources.
Bon, pour tester ce plugin sur le serveur HTTP local de Nagios, relancez une seconde fois le plugin en indiquant le paramètre -H pour localhost.
nagios@NagiosDebian:/usr/local/nagios/libexec$ ./check_http -H localhostLe résultat de cette commande devrait produire une sortie comme :
HTTP OK: HTTP/1.1 200 OK - 10975 octets en 0,001 secondes de temps de réponse |time=0,000928s;;;0,000000 size=10975B;;;0
2. Analysez le retour des exécutions des plugins
Le résultat de l’exécution de ce plugin peut être décomposé de la façon suivante :
SORTIE PLUGIN : CODE RETOUR SERVEUR HTTP - TAILLE REPONSE + TEMPS REPONSE | PERFORMANCE DATA
Le détail de ces champs peut s’expliquer ainsi :
SORTIE PLUGIN : le texte affiché ici est construit directement par le plugin et va dépendre de la réponse du serveur. Le mot OK donne une indication sur le statut que le plugin va renvoyer.
Cependant ce n’est qu’une indication. Nagios ne va pas se fier à cet affichage, mais va analyser le code de sortie du plugin au sens système du terme, c’est-à-dire le code transmis à l’instruction exit() dans le programme du plugin.
Sous Linux, il est possible de récupérer ce code dans la variable Bash $?.
Testons cela : exécutez les deux commandes suivantes de manière successive :
nagios@NagiosDebian:/usr/local/nagios/libexec$ ./check_http localhost ; echo $?Vous devriez obtenir le résultat suivant :
HTTP OK: HTTP/1.1 200 OK - 10975 octets en 0,001 secondes de temps de réponse |time=0,000904s;;;0,000000 size=10975B;;;0 0
La première ligne est similaire à la précédente exécution, avec éventuellement une variation sur le temps de réponse.
La seconde ligne affiche simplement 0. C’est ce chiffre, et uniquement ce chiffre, qui est analysé par Nagios pour déterminer le statut de l’objet supervisé. La nomenclature suivante a été définie pour les objets de type service :
Code | Signification |
|---|---|
| 0 | OK |
1 | WARNING |
2 | CRITICAL |
3 | UNKNOWN |
Lancez à nouveau votre plugin check_http avec l’URL d’un site qui n’existe pas :
nagios@NagiosDebian:/usr/local/nagios/libexec$ ./check_http www.unsitequinexistepas.com ; echo $?Le résultat de cette commande devrait être :
check_http: Adresse/Nom invalide - www.unsitequinexistepas.com 3
Pourquoi le plugin a-t-il retourné comme code de sortie la valeur 3, qui correspond à UNKNOWN ?
Tout simplement car, dans le processus de supervision, la requête DNS n’a pas renvoyé de résultat pour résoudre www.unsitequinexistepas.com. Par conséquent, le plugin n’a pas pu construire sa requête HTTP avec l’adresse IP résolue et ne sait pas si le site répond ou non… d’où ce code de sortie « 3 », pour UNKNOWN.
Ça, c’est fait ! Essayez maintenant de lancer ce plugin en indiquant le paramètre -I (plutôt que -H comme précédemment), et en précisant une adresse IP inexistante ou injoignable depuis le serveur Nagios :
nagios@NagiosDebian:/usr/local/nagios/libexec$ ./check_http -I 10.0.0.1 ; echo $?Si l’adresse n’existe pas ou n’héberge pas de service HTTP, le résultat de cette commande devrait donner :
CRITICAL - Socket timeout 2
Ici, le plugin renvoie un résultat CRITICAL, car le service HTTP sur l’adresse IP passée en paramètre ne répond pas !
Code | Signification |
|---|---|
| 0 | UP |
1 | UP |
2 | DOWN |
3 | DOWN (sauf si Nagios dispose de votre topologie et peut déterminer que le host est UNREACHABLE… Nous en avions parlé plus en détail dans la deuxième partie du cours.) |
3. Exploitez les options du plugin « check_http »
Il est facile de récupérer un résultat WARNING en testant ce plugin sur le site d’administration de Nagios. Pour cela, vous auriez intuitivement envie de lancer le plugin en indiquant, avec le paramètre -H, le répertoire du site d’administration /nagios :
nagios@NagiosDebian:/usr/local/nagios/libexec$ ./check_http -H localhost/nagiosEt vous obtiendriez le résultat suivant :
check_http: Adresse/Nom invalide - localhost/nagios
En effet, le plugin check_http oblige à faire la différence entre l’adresse native du site et la ressource à sonder. Pour obtenir la bonne syntaxe, il faut consulter la documentation de ce plugin. Celle-ci est bien fournie, car c’est un plugin standard développé et maintenu par l’équipe Nagios. Lancez la commande suivante :
nagios@NagiosDebian:/usr/local/nagios/libexec$ ./check_http --helpEt vous devriez obtenir un résultat commençant par :
check_http v2.2.1 (nagios-plugins 2.2.1) Copyright (c) 1999 Ethan Galstad <nagios@nagios.org> Copyright (c) 1999-2014 Nagios Plugin Development Team <devel@nagios-plugins.org> Ce *plugin* teste le service HTTP sur l'hôte spécifié. Il peut tester lesserveurs normaux (http) et sécurisés (https), suivre les redirections, rechercher deschaînes de caractères et expressions rationnelles, vérifier le temps de réponseet rapporter la date d'expiration du certificat. Utilisation : check_http -H <vhost> | -I <IP-address> [-u <uri>] [-p <port>] [-J <client certificate file>] [-K <private key>] [-w <warn time>] [-c <critical time>] [-t <timeout>] [-L] [-E] [-a auth] [-b proxy_auth] [-f <ok|warning|critcal|follow|sticky|stickyport>] [-e <expect>] [-d string] [-s string] [-l] [-r <regex> | -R <case-insensitive regex>] [-P string] [-m <min_pg_size>:<max_pg_size>] [-4|-6] [-N] [-M <age>] [-A string] [-k string] [-S <version>] [--sni] [-C <warn_age>[,<crit_age>]] [-T <content-type>] [-j method] NOTE : les paramètres `-H` et `-I` peuvent être spécifiés
Suivi par le détail de chaque option disponible.
Par exemple, si vous vous penchez plus particulièrement sur l’option -u vous pouvez lire les informations suivantes :
-u, --uri=PATH URI pour le GET ou le POST (défaut : /)
Relancez alors votre plugin en ajoutant cette option :
nagios@NagiosDebian:/usr/local/nagios/libexec$ ./check_http -H localhost -u /nagiosVous obtenez alors la sortie suivante :
HTTP WARNING: HTTP/1.1 401 Unauthorized - 686 octets en 0,001 secondes de temps de réponse |time=0,001097s;;;0,000000 size=686B;;;0
Ah… c’est un code de sortie WARNING ! Vérifiez la valeur de la variable $? avec la commande suivante :
nagios@NagiosDebian:/usr/local/nagios/libexec$ echo $?
1Pourquoi ce code WARNING ?
Eh bien, si vous analysez le code de retour HTTP vous pourrez constater un « 401 Unauthorized » !
Évidemment ! Souvenez-vous que dans la seconde partie de ce cours, chapitre 1, vous avez protégé l’accès à l’interface d’administration de Nagios par un accès htaccess.
Observez maintenant l’option -a du plugin check_httpen le relançant avec -help :
-a, --authorization=AUTH_PAIR Username:password on sites with basic authentication
Il semblerait que cette option vienne débloquer la situation. Pour vous en assurer, relancez le plugin et renseignez la combinaison login/password pour accéder à l’interface d’administration via cette option -a :
nagios@NagiosDebian:/usr/local/nagios/libexec$ ./check_http -H localhost -u /nagios -a nagiosadmin:passLe résultat de cette commande devrait ressembler à :
HTTP OK: HTTP/1.1 301 Moved Permanently - 531 octets en 0,001 secondes de temps de réponse |time=0,000854s;;;0,000000 size=531B;;;0
Le plugin envoie bien le login et le mot de passe de l’utilisateur, mais le site répond un 301. Et effectivement, si vous observez bien, vous pourrez constater que la page d’accueil du site d’administration a été créée avec une ancienne méthode de développement : les frames. On voit ainsi les menus à gauche avec la frame side.php, et la page principale avec la frame main.php.
Relancez le plugin en ajoutant la frame principale dans l’option -u :
nagios@NagiosDebian:/usr/local/nagios/libexec$ ./check_http -H localhost -u /nagios/main.php -a nagiosadmin:passLe résultat de cette commande devrait ressembler à :
HTTP OK: HTTP/1.1 200 OK - 8221 octets en 0,002 secondes de temps de réponse |time=0,002359s;;;0,000000 size=8221B;;;0
Pour cela, vous pouvez simplement lancez la commande suivante :
nagios@NagiosDebian:/usr/local/nagios/libexec$ ./check_http -H localhost -u /nagios/main.php -a nagios:passIci, le login d’accès est volontairement changé, et la sonde répond ainsi :
HTTP WARNING: HTTP/1.1 401 Unauthorized - 686 octets en 0,001 secondes de temps de réponse |time=0,000738s;;;0,000000 size=686B;;;0
Cela confirme son bon fonctionnement.
En résumé
Voilà quelques options intéressantes concernant le plugin check_http. Bien entendu, vous aurez constaté qu’il en reste un certain nombre ! Je vous invite, par exemple, à examiner les options -t pour fixer le temps maximum de réponse du plugin, -P pour envoyer des données en POST, ou encore -E pour récupérer plus d’informations de performance.
Dans le chapitre suivant, nous verrons comment exploiter ces options afin de créer un watchdog applicatif et ainsi découvrir ensemble les seuils.
