Vous maîtrisez désormais les principales options du plugin standard Nagios check_http. Vous vous êtes aussi assuré que ce plugin renvoyait exactement le résultat attendu lorsqu'il était exécuté dans l'environnement du compte système nagios.
Dans ce chapitre, nous procéderons ensemble à une analyse de l’exécution de votre plugin, étape nécessaire pour connaître la meilleure configuration de Nagios Core, et pour définir les bonnes options et les bons arguments de la commande Nagios associée. Pour cela, nous nous baserons sur un mini cahier des charges de supervision.
Analysez l'exécution de votre plugin check_http
Si vous reprenez l'ensemble des options du plugin check_http évoquées lors du précédent chapitre, vous pouvez construire la ligne de commande suivante :
/usr/local/nagios/libexec/check_http -H localhost -u /nagios/main.php -a nagiosadmin:pass -m 8200 -w 0,1 -c 0,2Lancez cette ligne de commande, et vous devriez obtenir quelque chose comme :
nagios@NagiosDebian:~$ /usr/local/nagios/libexec/check_http -H localhost -u /nagios/main.php -a nagiosadmin:pass -s '4.4.2' -m 8200 -w 0,1 -c 0,2 HTTP OK: HTTP/1.1 200 OK - 8221 octets en 0,004 secondes de temps de réponse |time=0,004151s;0,100000;0,200000;0,000000 size=8221B;8200;0;0
Dans cette ligne de commande, on peut identifier les éléments suivants :
/usr/local/nagios/libexec, le chemin qui adresse le répertoire d'installation des plugins standards Nagios. Nous avions détaillé l’arborescence d’installation de Nagios dans la deuxième partie de ce cours ;check_http, le fichier qui est exécuté par cette commande ;-H localhost, qui indique l'adresse de la machine hébergeant le site Web à superviser ;-u /nagios/main.php, qui indique la ressource cible de la requête HTTP ;-a nagiosadmin:pass, qui permet de passer les paramètres de l'authentification htaccess directement dans la requête HTTP de la sonde ;-s 4.4.2, qui spécifie la chaîne de caractères que le plugin doit trouver dans la réponse à la requête HTTP, dans le code de la page renvoyée ;-m 8200, qui indique que le plugin attend une page ayant un poids supérieur à 8 200 octets ;-w 0,1, qui indique le temps de réponse à partir duquel la sonde passera au statut « WARNING » ;-c 0,2, qui indique le temps de réponse à partir duquel la sonde passera au statut « CRITICAL ».
Cette sonde teste le site Web d'administration du serveur Nagios de manière très précise.
Premier exemple, nous pourrions imaginer un parc informatique disposant de plusieurs serveurs Nagios. Il suffirait alors de reprendre la même sonde en modifiant uniquement la valeur de l’option -H :
nagios@NagiosDebian:~$ /usr/local/nagios/libexec/check_http -H serveurNagios2 -u /nagios/main.php -a nagiosadmin:pass -s '4.4.2' -m 8200 -w 0,1 -c 0,2
nagios@NagiosDebian:~$ /usr/local/nagios/libexec/check_http -H serveurNagios3 -u /nagios/main.php -a nagiosadmin:pass -s '4.4.2' -m 8200 -w 0,1 -c 0,2
...Dans ce cas, vous comprenez bien que les autres options ont les mêmes valeurs sur toutes les exécutions du plugin. Vous pourriez alors écrire toutes ces exécutions de manière synthétique :
nagios@NagiosDebian:~$ /usr/local/nagios/libexec/check_http -H SERVEUR ARGUMENTSLes arguments se décomposent alors ainsi :
SERVEUR, qui contient l'adresse de la machine hébergeant le serveur Nagios, etARGUMENTS, qui contient tout le reste de la ligne de commande qui ne change pas (-u /nagios/main.php -a nagiosadmin:pass -s '4.4.2' -m 8200 -w 0,1 -c 0,2).
Deuxième exemple, également très vraisemblable : le compte d'accès à l'interface d'administration diffère selon le serveur Nagios à superviser. Ici, il existe donc une nouvelle partie variable dans la ligne de commande -a nagiosadmin:pass soit, de façon concise :
nagios@NagiosDebian:~$ /usr/local/nagios/libexec/check_http -H SERVEUR -a LOGIN-PASSWORD ARGUMENTSLes arguments se décomposent alors ainsi :
« SERVEUR », qui contient l'adresse de la machine hébergeant le serveur Nagios ;
« LOGIN-PASSWORD », qui contient la chaîne de caractères
login:passwordpermettant l'authentification htacces sur le serveur Nagios supervisé ;« ARGUMENTS », qui contient tout le reste de la ligne de commande qui ne change pas (
-u /nagios/main.php -s '4.4.2' -m 8200 -w 0,1 -c 0,2).
Vous pourriez décomposer cette ligne de commande en identifiant les éléments variables selon votre besoin. Le troisième exemple ci-dessous montre la décomposition la plus générique possible : il s’agit de la supervision d’un site Web. Celui-ci, protégé par htaccess, doit, en un temps bien défini, renvoyer une page d’un certain poids et contenant une chaîne de caractères :
nagios@NagiosDebian:~$ /usr/local/nagios/libexec/check_http -H SERVEUR -a LOGIN-PASSWORD -u URL -s CONTENU -m POIDS -w TEMPS-WARNING -c TEMPS-CRITICALLa décomposition de cette ligne de commande est exactement la même que lors de la première exécution de cette sonde au début du chapitre… sauf que toutes les options sont variables et peuvent changer d'une exécution à l'autre.
Il reste encore un dernier niveau d'abstraction ! Qu'en est-il de la sonde si vous souhaitez, par la suite, rajouter encore une option supplémentaire, comme l’option -t pour fixer le timeout de l'exécution, ou encore -E pour récupérer les informations de performance ?
Et dans ce cas, pourquoi ne pas modéliser toutes les options dans un seul argument ! La commande donnerait alors :
nagios@NagiosDebian:~$ /usr/local/nagios/libexec/check_http GROS-ARGUMENTOù GROS-ARGUMENT, contient l'ensemble des options nécessaires à la sonde. Cette modélisation est tout à fait possible avec Nagios. Cependant il est important de comprendre que, en fonction de votre contexte, ce n'est pas forcément la meilleure solution. Pour des raisons de sécurité vous pourriez, par exemple, limiter le périmètre des machines supervisées. En d’autres termes, vous devriez figer l’argument -H dans votre commande, ou figer les informations d’authentification avec l’option -a. Ou encore, vous pourriez vous concentrer sur les aspects de performance en figeant aussi les seuils -w et -c du plugin. Bref, tout dépend de votre besoin mais, avec Nagios, tout est possible.
Créez une commande Nagios pour ce plugin check_http
Maintenant que la ligne de commande d'exécution du plugin a été analysée, il est temps de faire le nécessaire pour que Nagios se charge lui-même de lancer les sondes !
Il est donc nécessaire de fixer un résultat de cette analyse, et dans le contexte de ce cours, je vais vous proposer le mini cahier des charges suivant :
MINI CAHIER DES CHARGES :
Il s'agit de superviser des sites Web, vous gardez donc le plugin
check_http.L'accès aux sites peut éventuellement être protégé par un mot de passe
htaccess.La page à superviser varie en fonction du site.
La page renvoyée par le plugin doit contenir une chaîne de caractères, qui varie en fonction du site.
Le poids de la page renvoyée varie en fonction du site.
Tous les sites doivent répondre entre 0,1 et 0,2 secondes.
Vous remarquerez que, dans ce mini cahier des charges, il existe des éléments variables et constants, obligatoires ou facultatifs. Pour modéliser ce type de ligne de commande, la bonne méthode est de :
ajouter, d’abord, les éléments obligatoires du plugin ;
ajouter, ensuite, les éléments facultatifs constants ;
terminer, enfin, par les éléments facultatifs variables.
Vous pouvez écrire la ligne de commande à exécuter de cette façon :
nagios@NagiosDebian:~$ /usr/local/nagios/libexec/check_http -H SERVEUR -w 0,1 -c 0,2 -u ARGUMENT1 -s ARGUMENT2 -m ARGUMENT3 ARGUMENT-HTACCESSLes arguments se décomposent alors ainsi :
-H SERVEUR, argument qui doit changer pour chaque site Web supervisé ;
-w 0,1 -c 0,2, arguments obligatoires qui indiquent les temps de réponse WARNING et CRITICAL, facultatifs mais constants dans ce mini cahier des charges ;
-u ARGUMENT1, premier argument obligatoire variable : l'URL de la ressource ;
-s ARGUMENT2, second argument obligatoire variable : la chaîne de caractères à rechercher dans le code résultat de la page ;
-m ARGUMENT3, troisième argument obligatoire variable : le poids minimal de la page renvoyée ;
ARGUMENT-HTACCESS, dernier argument : l’authentification éventuelle à la ressource par htaccess. Cet argument étant facultatif, le -a n’est pas indiqué en dur dans la ligne de commande, mais inclus dans l'argument.
Vous y êtes presque !
Souvenez vous désormais du chapitre 4 de la seconde partie du cours dans laquelle nous avons vu ensemble les différents éléments constituants de Nagios.
Maintenant que votre plugin est prêt, il est temps de passer à l'élément suivant : la command. Cet objet appartenant à Nagios permet de modéliser exactement ce que vous venez de faire à la main, c’est-à-dire qu’il décompose la ligne de commande qui exécutera le plugin.
Créez le fichier qui contiendra les différentes command du cours, en utilisant la commande suivante :
touch /usr/local/nagios/opencr_conf/commandes.cfgSouvenez-vous :
les fichiers de configuration de Nagios ont une extension .cfg ;
il est important de bien travailler dans un répertoire dédié (ici
/usr/local/nagios/opencr_conf, afin de ne pas modifier les fichiers de configuration livrés par Nagios.
Pour définir une command qui permette de réaliser le mini cahier des charges associé au plugin check_http, allez dans le fichier commandes.cfg et saisissez les lignes suivantes :
define command {
command_name check-http-exemple-opencr
command_line $USER1$/check_http -H $HOSTADDRESS$ -w 0,1 -c 0,2 -u $ARG1$ -s $ARG2$ -m $ARG3$ $ARG4$
}À quoi correspondent ces lignes ?
Dans le chapitre 4 de la partie 2, nous avions vu comment définir un objet host. Nagios possède aussi une syntaxe pour ses objets command. Vous pouvez retrouver le détail de la configuration des command sur la documentation officielle Nagios Core : https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/objectdefinitions.html#command
La syntaxe des command Nagios est très simple, il suffit de définir deux directives :
command_name, qui porte le nom de la commande telle que Nagios la reconnaîtra. L’idée est de choisir un nom parlant, pour que le rôle de la commande soit intelligible au premier coup d’œil. Le nom utilisé dans le cadre de ce cours, check-http-exemple-opencr, permet de savoir immédiatement que cette commande fait appel au plugin
check_httpet qu'elle sert d’exemple au cours OpenClassrooms ;command_line, directive qui contient l'appel à l'exécutable et qui se décompose de la sorte :
USER1$, USER MACRO que nous avons configurée dans le fichier
/usr/local/nagios/etc/resource.cfg, qui contient notamment le chemin d'accès vers le répertoire des plugins de Nagios (/usr/local/nagios/libexec) ;check_http, le plugin à exécuter ;
-H \$HOSTADDRESS\$, l’une des standard macros permettant à Nagios de stocker des informations sur les objets supervisés. Les standard macros, accessibles uniquement en lecture seule, sont listés ici : [ ](https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/macrolist.html). Dans notre cas, HOSTADDRESS sera remplacée, à chaque appel de la commande, par la valeur de l'attribut host_address de l'objet concerné ;
-w 0,1 -c 0,2, les arguments obligatoires et constants du mini cahier des charges ;
-u \$ARG1\$ -s \$ARG2\$ -m \$ARG3\$ \$ARG4\$, les argument variables, obligatoires et facultatifs. Là encore, Nagios propose un autre type de variables, les arguments. Ces variables, accessibles en lecture et en écriture, sont toujours nommées \$ARGx\$. Dans notre cas, \$ARG1\$ correspond à l'URL de la ressource telle qu’elle a été définie dans le mini cahier des charges évoqué précédemment.
Et voilà : la commande est prête ! Il faut maintenant l'exploiter en configurant un service.
nagios@NagiosDebian:/usr/local/nagios/opencr_conf$ more commands.cfg
define command {
command_name check-http-exemple-opencr
command_line $USER1$/check_http -H $HOSTADDRESS$ -w 0,1 -c 0,2 -u $ARG1$ -s $ARG2$ -m $ARG3$ $ARG4$
}
define command {
command_name check-ping-localhost
command_line $USER1$/check_ping -H localhost -w 40,40% -c 60,60%
}
define command {
command_name check-ssh-localhost
command_line $USER1$/check_ssh localhost
}Vérifiez votre configuration avec la commande suivante :
testNagiosElle devrait produire la sortie suivante :
Checking global event handlers... Checking obsessive compulsive processor commands... Checking misc settings... Total Warnings: 4 Total Errors: 0 Things look okay - No serious problems were detected during the pre-flight check
En résumé
Dans ce chapitre, vous avez suivi un mini cahier des charges de supervision, concernant le serveur Nagios et son site Web d'administration. Il est important de retenir la méthodologie que je viens de vous présenter, afin d’optimiser votre travail de configuration des host ou des service à superviser.
Dans un premier temps, pensez à tester votre plugin à la main sous le compte
nagioset à vérifier qu'il renvoie les bonnes alertes au bon moment ;Dans un deuxième temps, procédez à une analyse sur la ligne de commande obtenue, afin de déterminer les éléments obligatoires, facultatifs, constants ou variables ;
Enfin, terminez le travail en définissant la command Nagios, en définissant les bons arguments et en utilisant les bonnes macros.
Dans le chapitre suivant, je vous propose de terminer la configuration de cette sonde en créant l'objet service associé et en le rattachant à un objet host.
