• 15 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 11/06/2021

Découvrez le fonctionnement des plugins Nagios avec check_http

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_http

Si 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 localhost

Le 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/nagios

Et 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 --help

Et 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&nbsp;:
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&nbsp;: 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&nbsp;: /)

Relancez alors votre plugin en ajoutant cette option :

nagios@NagiosDebian:/usr/local/nagios/libexec$ ./check_http -H localhost -u /nagios

Vous 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 $?
1

Pourquoi 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:pass

Le 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:pass

Le 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:pass

Ici, 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.

Et si vous obteniez un diplôme OpenClassrooms ?
  • Formations jusqu’à 100 % financées
  • Date de début flexible
  • Projets professionnalisants
  • Mentorat individuel
Trouvez la formation et le financement faits pour vous
Exemple de certificat de réussite
Exemple de certificat de réussite