Comme j’en parlais à la fin du précédent article, on va voir comment faire pour créer un service sous Icinga2

 

1) Surveiller un protocole – Méthode 1

Comme j’expliquais dans le précédent article, quand on créé un service on doit ajouter une condition qui activera ce service si elle est vraie

Le premier truc à faire, c’est d’identifier quel plugin nous allons utiliser pour notre test. Pour l’exemple, on va choisir le protocole ftp. Parmi tous les plugins présents dans le répertoire /usr/lib/nagios/plugins/, il y a le plugin check_ftp, qui sert à tester la connexion au serveur ftp.
Il va tout d’abord falloir apprendre comment fonctionne ce plugin et quels arguments il a besoin. Tapez la commande /usr/lib/nagios/plugins/check_ftp -h et l’aide de ce plugin va s’afficher (tous les plugins fonctionnent de la même manière). C’est le début de l’une des premières lignes de l’aide qui nous intéresse :
check_ftp -H host -p port [-w <warning time>] [-c <critical time>]. Que nous dit cette aide :

• l’argument -H permet d’indiquer à quelle adresse ip se connecter.
• l’argument -p permet d’indiquer quel port utiliser. Il y a peu de chance que vous utilisiez un port différent de celui par défaut pour le serveur ftp. Nous n’aurons donc pas besoin de cet argument
• les arguments -w et -c permettent d’indiquer à partir de quel temps de réponse déclencher, respectivement, un avertissement et une alerte. Comme je souhaite juste un test binaire, le serveur ftp répond/ne répond pas, nous ne les utiliserons pas.
• les autres arguments ne nous seront pas utile.

Ces 4 arguments, qui sont communs à quasiment tous les plugins, sont ceux que vous utiliserez le plus.

Maintenant que nous connaissons les arguments à utiliser, nous allons pouvoir créer la commande qui servira à tester le protocole ftp.

Ouvrez le fichier commands.conf qui est dans le répertoire /etc/icinga2/conf.d. A la fin du fichier, rajoutez les lignes suivantes :

[pastacode lang=”bash” manual=”object%20CheckCommand%20%22check_ftp%22%20%7B%0A%0A%20%20command%20%3D%20%5B%20PluginDir%20%2B%20%22%2Fcheck_ftp%22%20%5D%0A%20%20arguments%20%3D%20%7B%0A%20%20%20%20%22-H%22%20%3D%20%22%24ftp_host%24%22%0A%20%20%7D%0A%7D” message=”” highlight=”” provider=”manual”/]

Expliquons un peu ces lignes :

• object CheckCommand "check_ftp" { : indique que vous allez créer un objet de type commande de test qui s’appelle “check_ftp” (vous pouvez l’appeler comme vous voulez).
• arguments = { : début de la liste des arguments
• "-H" = "$ftp_host$" : création de la variable “ftp_host” (là aussi vous pouvez mettre le nom que vous voulez) qui correspond à l’argument -H.
  Si vous utilisez un port autre que celui par défaut, il aurait fallu créer également une variable pour l’argument “-p” avec la ligne "-p" = "$ftp_port$".

Pour tous les tests de protocoles (smtp, pop, etc), la création de commande sera sur le même principe.

La commande étant créée, on va pouvoir créer le service. Il y a plusieurs manières de créer un service, on va voir ça en détails

Commençons par la méthode 1. Ouvrez le fichier services.conf. Rajoutez les lignes suivantes à la fin du fichier :

[pastacode lang=”bash” manual=”apply%20Service%20%22protocole_ftp%22%20%7B%0A%20%20import%20%22generic-service%22%0A%20%20check_command%20%3D%20%22check_ftp%22%0A%20%20vars.ftp_host%20%3D%20host.address%0A%20%20assign%20where%20host.address%0A%7D” message=”” highlight=”” provider=”manual”/]

Expliquons de nouveau ces lignes :

• apply Service "protocole_ftp" { : indique que vous allez créer un service qui s’appelle “protocole_ftp” (vous pouvez modifier le nom).
• import "generic-service" : on importe le template des services, qui se trouve dans le fichier templates.conf. Pour rappel, ce template sert à avoir des valeur par défaut pour le délai entre chaque test,  le nombre d’essai en cas d’échec, etc.
• check_command = "check_ftp" : indique quelle commande on va utiliser pour tester ce service. Le nom de la commande doit être le même que dans le fichier commands.conf.
• vars.ftp_host = host.address : on attribue à la variable “ftp_host” la valeur host.adress qui correspond à l’adresse ip du host définie dans le fichier hosts.conf. Comme ftp_host est la valeur que prendra l’argument “-H”, on se retrouvera bien avec “-H adresseipduhost”.
• assign where host.address : indique la condition qui doit être présente sur le host pour que le service soit actif. Là on a indiqué que si une adresse ip est spécifiée dans le host, cela rendra le service actif. Comme les hosts ont forcément une adresse ip spécifiée, ce service s’appliquera bien à notre host.
  Cette ligne est obligatoire.

Petit parenthèse sur les conditions. Il est possible de mettre d’autres condition que celle-là. On pourrait par exemple remplacer cette ligne par assign where host.vars.serveurFTP == true. On a créé une condition spécifiant que ce service ne sera actif que si la variable serveurFTP, qui sera déclarée dans le fichier hosts.conf, est vraie.
Pour spécifier la valeur de la variable serveurFTP, ouvrez le fichier hosts.conf et ajoutez la ligne vars.serveurFTP = true dans votre serveur.
Fin de la parenthèse.

 

Il existe également une autre méthode pour créer un service.

2) Surveiller un protocole – Méthode 2

Dans le fichier services.conf, créez le service de cette façon :

[pastacode lang=”bash” manual=”apply%20Service%20%20for%20(ftp%20%3D%3E%20config%20in%20host.vars.protocole_ftp)%7B%0A%20%20import%20%22generic-service%22%0A%20%20check_command%20%3D%20%22check_ftp%22%0A%20%20vars%20%2B%3D%20config%0A%7D” message=”” highlight=”” provider=”manual”/]

On peut voir que 2 lignes ont été remplacées :

• apply Service "protocole_ftp" { a été remplacé par apply Service for (ftp => config in host.vars.protocole_ftp){
• vars.ftp_host = host.address a été remplacé par vars += config.

La première ligne signifie que ce service sera activé dans le fichier hosts.conf grâce à la variable protocole_ftp.  Elle remplace la ligne “assign where” qui a disparue.

La seconde signifie qu’au lieu de renseigner la valeur des variables, créées dans le fichier commands.conf, dans le fichier services.conf lors de la création du service, on va les renseigner directement dans le fichier hosts.conf.
On va rajouter un cas pour expliquer l’utilité de renseigner les variables dans le fichier hosts.conf.

On va garder l’exemple du test du protocole ftp pour rester dans la continuité mais ça ne va pas être un cas très réaliste.
Vous vous souvenez que les variables correspondent aux arguments du plugin. Imaginons maintenant que vous hébergiez 3 serveurs ftp et que vous avez modifiés le port du ftp de chaque serveur (cas assez improbable avec un serveur ftp mais c’est juste pour l’exemple). Dans le fichier commands.conf, vous allez créer la commande servant à tester le ftp, comme dans le chapitre 1, et ajouter la ligne "-p" = "$ftp_port$". La variable “ftp-port” correspondra donc à l’argument “-p” qui sert à indiquer quel port tester.

Avec la méthode vu dans le chapitre 1, il vous faudrait créer 3 services dans le fichier services.conf, avec pour chacun une valeur différente pour la variable “ftp_port”.
Avec la méthode de ce chapitre, à savoir ajouter la ligne vars += config à la place des variables dans services.conf, vous aller indiquer pour dans le fichier hosts.conf  la valeur que prendra chaque variable déclarée dans la commande du test. Dans notre cas il nous faudra renseigner la valeur des variables “ftp_port” et “ftp_host”.
Pour ce faire, il suffit de rajouter les lignes

[pastacode lang=”bash” manual=”vars.protocole_ftp%5B%22ftp1%22%5D%20%3D%20%7B%0A%20%20%20%20%20%20%20%20ftp_port%3D%22num%C3%A9roport%22%0A%20%20%20%20%20%20%20%20ftp_host%3D%22ipduserveur%22%0A%7D%0Avars.protocole_ftp%5B%22ftp2%22%5D%20%3D%20%7B%0A%20%20%20%20%20%20%20%20ftp_port%3D%22num%C3%A9roport%22%0A%20%20%20%20%20%20%20%20ftp_host%3D%22ipduserveur%22%0A%7D%0Avars.protocole_ftp%5B%22ftp3%22%5D%20%3D%20%7B%0A%20%20%20%20%20%20%20%20ftp_port%3D%22num%C3%A9roport%22%0A%20%20%20%20%20%20%20%20ftp_host%3D%22ipduserveur%22%0A%7D%0A” message=”” highlight=”” provider=”manual”/]

dans le fichier hosts.conf pour chaque serveur pour lesquels vous souhaitez activer ce service. Il faut forcément que les valeurs des variables soient entres des guillemets.

Pour info, il est tout à fait possible de déclarer les valeurs des variables à la fois dans services.conf et dans hosts.conf. Reprenons notre exemple avec deux variables, une pour le port et une autre pour l’adresse ip. L’adresse ip est déjà déclarée dans le fichier hosts.conf. Le mieux à faire dans ce cas est donc de déclarer la valeur de la variable “ftp_host” dans le services.conf avec la ligne vars.ftp_host = host.address et de ne déclarer que la valeur de la variable “ftp_port” dans hosts.conf car elle sera propre à chaque serveur ftp.

Maintenant vous savez comment tester un protocole et comment remplir les différents fichiers de configuration. On va voir juste un dernier cas, comment vérifier qu’une application tourne sur le serveur.

3) Tester un processus

Comme vous devez vous en douter, le principe va rester globalement le même que pour tester un protocole. Commençons par le plugin à utiliser. On va utiliser le plugin “check_procs”. Un coup de commande /usr/lib/nagios/plugins/check_procs -h nous affiche l’aide suivante :

[pastacode lang=”bash” manual=”Utilisation%3A%0Acheck_procs%20-w%20%3Crange%3E%20-c%20%3Crange%3E%20%5B-m%20metric%5D%20%5B-s%20state%5D%20%5B-p%20ppid%5D%0A%20%5B-u%20user%5D%20%5B-r%20rss%5D%20%5B-z%20vsz%5D%20%5B-P%20%25cpu%5D%20%5B-a%20argument-array%5D%0A%20%5B-C%20command%5D%20%5B-k%5D%20%5B-t%20timeout%5D%20%5B-v%5D” message=”” highlight=”” provider=”manual”/]

Vous connaissez déjà les arguments “w” et “c”, qui servent à déterminer, respectivement, quand lever un avertissement et quand lever une alarme. L’autre argument qui nous intéresse est “C”, qui sert à indiquer quel processus on va tester. Ce plugin va chercher dans tous les processus en cours s’il y en a un ou plusieurs qui correspondent à la valeur de l’argument “-C”.

Le problème est que, comme c’est l’utilisateur “nagios” qui exécute les plugins, il ne pourra voir que les processus auxquels il a accès, ce qui limite considérablement le nombre de processus. On va donc remédier à ce problème.

On va permettre à l’utilisateur “nagios” d’exécuter le plugin “check_procs” avec sudo (donc en admin) sans mot de passe. Je sais que c’est pas très propre d’un point de vue sécurité, mais ça reste très limité vu que seul ce plugin pourra être exécuté en root.

Ouvrez le fichier /etc/sudoers et ajoutez la ligne suivante : nagios ALL=(ALL) NOPASSWD: /usr/lib/nagios/plugins/check_procs.
Comme expliqué plus tôt, cette ligne permettra donc à l’utilisateur “nagios” d’exécuter le plugin check_procs, et uniquement ce script, avec les droits root sans mot de passe.

Maintenant que ça c’est fait, passons à la configuration d’Icinga. Comme précédemment, on va devoir créer la commande servant à tester le processus ainsi que le service.

Ouvrez le fichier commands.conf et ajoutez les lignes suivantes :

[pastacode lang=”bash” manual=”object%20CheckCommand%20%22check_processus%22%20%7B%0A%0A%20%20command%20%3D%20%5B%22sudo%22%2C%20PluginDir%20%2B%20%22%2Fcheck_procs%22%20%5D%0A%20%20arguments%20%3D%20%7B%0A%20%20%20%20%22-c%22%20%3D%20%22%24critical_arg%24%22%0A%20%20%20%20%22-C%22%20%3D%20%22%24name_processus%24%22%0A%20%20%7D%0A%7D” message=”” highlight=”” provider=”manual”/]

J’ai appelé la commande “check_processus”. Cette commande va exécuter le plugin “check_procs” avec “sudo” et on va utiliser 2 arguments :

• “-c” qui prendra la valeur de la variable “critical_arg”. Cette valeur indique combien de processus doivent être en cours d’exécution. Cette valeur doit être exprimée sous forme de limite “min:max”. Imaginons que vous vouliez vérifier l’application “toto” et que cette application soit lancée 3 fois. Cette valeur devra donc plus tard être déclaré comme suit : “3:3”. Dés qu’Icinga2 trouvera moins ou plus de 3 processus nommés toto, il déclenchera une alarme. Si le nombre d’application lancé est variable, disons entre 3 et 6, vous pourrez déclarer comme valeur “3:6” quand vous créerez le service. La plupart des processus ne se lançant qu’une fois, la valeur que vous mettrez le plus souvent sera “1:1”.
• “-C” qui prendra la valeur de la variable “name_processus”. Cette valeur devra correspondre au nom du processus.

Je n’utilise pas l’argument “-w” car il n’y a pas d’intérêt à avoir des avertissement pour ce genre de test. A part cas très particulier.

Cette commande servira pour tous les tests de processus. Passons maintenant à la création du service. On va devoir créer un service pour chaque processus que nous voulons tester. Ouvrez le fichier services.conf et ajoutez les lignes suivantes :

[pastacode lang=”bash” manual=”apply%20Service%20%22processus_toto%22%20%7B%0A%20%20import%20%22generic-service%22%0A%20%20check_command%20%3D%20%22check_processus%22%0A%20%20vars.critical_arg%20%3D%20%221%3A1%22%0A%20%20vars.name_processus%20%3D%20%22toto%22%0A%20%20assign%20where%20host.address%0A%7D” message=”” highlight=”” provider=”manual”/]

Si vous le souhaitez vous pouvez utiliser la méthode vu au chapitre précédent pour créer un seul service générique et renseigner la variable “name_processus et “critical_arg” dans hosts.conf en appelant plusieurs fois le service. Pour ma part j’ai préféré créé plusieurs services car je trouve que c’est plus clair d’avoir un service = une application.

4) Désactiver la re-notification

Icinga2 a un comportement un peu con, il envoi un mail toutes les X minutes tant qu’un problème n’est pas résolu. Personnellement j’ai assez de neurones pour comprendre avec une seule notification qu’il y a un soucis.
On va donc changer ce comportement.

Ouvrez le fichier /etc/icinga2/conf.d/templates.conf. Vous devriez trouver les lignes template Notification "mail-host-notification" { et template Notification "mail-service-notification" {. Sous chacune de ces lignes, il y a ligne period = "24x7". Pour désactiver la re-notification, il vous suffit de rajouter la ligne interval = 0 // disable re-notification en dessous.

Vous devriez avoir quelque chose qui ressemble à ça :

[pastacode lang=”bash” manual=”%2F**%0A%20*%20Provides%20default%20settings%20for%20host%20notifications.%0A%20*%20By%20convention%20all%20host%20notifications%20should%20import%0A%20*%20this%20template.%0A%20*%2F%0Atemplate%20Notification%20%22mail-host-notification%22%20%7B%0A%20%20command%20%3D%20%22mail-host-notification%22%0A%0A%20%20states%20%3D%20%5B%20Up%2C%20Down%20%5D%0A%20%20types%20%3D%20%5B%20Problem%2C%20Acknowledgement%2C%20Recovery%2C%20Custom%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20FlappingStart%2C%20FlappingEnd%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20DowntimeStart%2C%20DowntimeEnd%2C%20DowntimeRemoved%20%5D%0A%0A%20%20vars%20%2B%3D%20%7B%0A%20%20%20%20%2F%2F%20notification_icingaweb2url%20%3D%20%22https%3A%2F%2Fwww.example.com%2Ficingaweb2%22%0A%20%20%20%20%2F%2F%20notification_from%20%3D%20%22Icinga%202%20Host%20Monitoring%20%3Cicinga%40example.com%3E%22%0A%20%20%20%20notification_logtosyslog%20%3D%20false%0A%20%20%7D%0A%0A%20%20period%20%3D%20%2224×7%22%0A%0A%20%20interval%20%3D%200%20%2F%2F%20disable%20re-notification%0A%7D%0A%0A%2F**%0A%20*%20Provides%20default%20settings%20for%20service%20notifications.%0A%20*%20By%20convention%20all%20service%20notifications%20should%20import%0A%20*%20this%20template.%0A%20*%2F%0Atemplate%20Notification%20%22mail-service-notification%22%20%7B%0A%20%20command%20%3D%20%22mail-service-notification%22%0A%0A%20%20states%20%3D%20%5B%20OK%2C%20Warning%2C%20Critical%2C%20Unknown%20%5D%0A%20%20types%20%3D%20%5B%20Problem%2C%20Acknowledgement%2C%20Recovery%2C%20Custom%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20FlappingStart%2C%20FlappingEnd%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20DowntimeStart%2C%20DowntimeEnd%2C%20DowntimeRemoved%20%5D%0A%0A%20%20vars%20%2B%3D%20%7B%0A%20%20%20%20%2F%2F%20notification_icingaweb2url%20%3D%20%22https%3A%2F%2Fwww.example.com%2Ficingaweb2%22%0A%20%20%20%20%2F%2F%20notification_from%20%3D%20%22Icinga%202%20Service%20Monitoring%20%3Cicinga%40example.com%3E%22%0A%20%20%20%20notification_logtosyslog%20%3D%20false%0A%20%20%7D%0A%0A%20%20period%20%3D%20%2224×7%22%0A%20%20interval%20%3D%200%20%2F%2F%20disable%20re-notification%0A%7D%0A” message=”” highlight=”” provider=”manual”/]

Il ne vous reste plus qu’à redémarrer Icinga2.

Voilà, cette série d’article sur Icinga2 est terminée. Vous voila capable de surveiller un paquet de truc sur votre serveur 😉
Si jamais j’ai l’occasion de faire de la surveillance de plusieurs serveurs, je ferai peut-être d’autres articles sur le sujet.