Modifier un service sur Icinga2

Dans un précédent article, j’avais expliqué comment installer Icinga2 ainsi que Icingaweb2. De base, Icinga2 surveille pas mal de services. Mais ces services ne sont peut-être pas bien configurés pour votre serveur. Il va donc nous falloir les modifier. On va prendre comme exemple dans cet article la modification du port à utiliser pour tester le SSH.
Mais avant de se lancer dans la modification des services, on va voir comment fonctionne Icinga2.

1) Arborescence des fichiers de configuration

Les fichiers de configuration de Icinga2 se trouvent dans le répertoire /etc/icinga2/conf.d/. Les fichiers que l’on va utiliser sont hosts.conf, commands.conf, services.conf et templates.conf. On va voir à quoi servent ces fichiers et comment ils interagissent les uns avec les autres.

  • templates.conf : comme son nom l’indique, ce fichier regroupe les templates, c’est à dire les configurations par défaut (temps entre chaque test, nombre d’essai en cas d’échec, etc), pour chaque type : test sur le serveur (tester s’il est accessible ou non), test des services (http, test de charge serveur, espace libre disque, etc), notification mail, etc.
  • commandes.conf : permet de configurer les commandes à lancer pour réaliser les tests ou les notifications.
  • services.conf : liste tous les services. Pour chaque service il faut indiquer quel template, défini dans le fichier templates.conf, utiliser et quelle commande, définie dans commands.conf, lancer pour tester ce service.
    On indique également une condition (exemple : telle variable doit avoir telle valeur) qui devra être vraie pour que le service soit actif sur tel ou tel host. Comprendre par « host » les serveurs que vous souhaitez surveiller. La valeur de la variable utilisé pour cette condition sera définie dans le fichier hosts.conf.
    Le but de cette condition, qui est obligatoire, est de pouvoir limiter l’activation de certains services sur des hosts spécifiques uniquement. Par exemple, si on créé un service pour tester que le protocole smtp soit actif, ça n’a aucun sens de le tester sur les hosts n’ayant pas de serveur mail.
  • hosts.conf : ce fichier liste votre ou vos hosts. A l’intérieur de chaque host est indiqué des services à tester spécifiques à ce host ou la valeur de variables de condition servant à activer certains services.
    Il sert également à pouvoir modifier des arguments de tests services. Par exemple, le service check_ssh va tester que le SSH est actif et va tester par défaut le port 22. Si vous utiliser un autre port, vous pouvez l’indiquer dans le fichier hosts.conf et ce pour chaque host.

Pour ma part, je n’ai qu’un seul serveur à surveiller (celui qui héberge ce site), je n’aborderai donc pas la surveillance de plusieurs serveurs/hosts avec Icinga2 car c’est un point que sur lequel je ne me suis pas du tout renseigné (mis à part les grandes lignes en me renseignant sur le fonctionnement des fichiers de configuration). Je préfère donc ne pas en parler plutôt que de raconter des âneries.
La suite de cet article partira donc du principe que vous n’avez qu’un seul serveur à surveiller et ce que j’explique ne fonctionnera peut-être pas dans le cas d’une surveillance de plusieurs serveurs.

Icinga2, pour faire ces tests, utilise des plugins, que vous pouvez trouver dans le répertoire /usr/lib/nagios/plugins si vous avez installé le paquet monitoring-plugins.
Ces plugins sont configurés via le fichier /usr/share/icinga2/include/command-plugins.conf ainsi que les fichiers de configuration présents dans le répertoire /etc/nagios-plugins/config/ (un par plugin).

Maintenant qu’on a la théorie, passons à la pratique.

2) Modifier le port SSH à utiliser

Comme j’ai indiqué précédemment, il est possible de modifier les arguments de tests existant, comme le numéro de port, l’adresse ip, le répertoire à tester, etc…
On va prendre comme exemple le port SSH à utiliser, une modification que la plupart des gens devront faire. Comme il est fortement déconseillé d’utiliser le port par défaut, il y a de forte chance que le port 22 ne corresponde pas à votre port SSH.

Tout d’abord, il nous faut vérifier que le test du SSH, activé par défaut sur Icinga2, permette de modifier le port. Pour ça, lancez la commande suivante :
icinga2 object list --name ssh --type checkcommand.

La commande icinga2 object list affiche tous les objets actifs. Qu’est-ce qu’un objet ? C’est un service (le test du SSH par exemple) ou une commande (la commande à lancer pour tester le SSH par exemple).
“–name” permet de filtrer par nom et “–type” permet de filtrer par type (service ou checkcommand). La ligne de commande que je vous ai fait entrer va donc nous afficher tous les détails de la commande de test du SSH. Ce qui nous intéresse est la partie argument :

[pastacode lang=”bash” manual=”%20*%20arguments%0A%20%20%20%20%25%20%3D%20modified%20in%20’%2Fusr%2Fshare%2Ficinga2%2Finclude%2Fcommand-plugins.conf’%2C%20lines%201354%3A2-1376%3A2%0A%20%20%20%20*%20-4%0A%20%20%20%20%20%20*%20description%20%3D%20%22Use%20IPv4%20connection%22%0A%20%20%20%20%20%20*%20set_if%20%3D%20%22%24ssh_ipv4%24%22%0A%20%20%20%20*%20-6%0A%20%20%20%20%20%20*%20description%20%3D%20%22Use%20IPv6%20connection%22%0A%20%20%20%20%20%20*%20set_if%20%3D%20%22%24ssh_ipv6%24%22%0A%20%20%20%20*%20-p%0A%20%20%20%20%20%20*%20description%20%3D%20%22Port%20number%20(default%3A%2022)%22%0A%20%20%20%20%20%20*%20value%20%3D%20%22%24ssh_port%24%22%0A%20%20%20%20*%20-t%0A%20%20%20%20%20%20*%20description%20%3D%20%22Seconds%20before%20connection%20times%20out%20(default%3A%2010)%22%0A%20%20%20%20%20%20*%20value%20%3D%20%22%24ssh_timeout%24%22%0A%20%20%20%20*%20host%0A%20%20%20%20%20%20*%20order%20%3D%201%0A%20%20%20%20%20%20*%20skip_key%20%3D%20true%0A%20%20%20%20%20%20*%20value%20%3D%20%22%24ssh_address%24%22″ message=”” highlight=”” provider=”manual”/]

On voit donc que l’argument indiquant le numéro du port à tester est “-p” est que la variable qui correspond à cet argument (on ne peut pas utiliser directement l’argument dans Icinga2) est “ssh_port”. Pour modifier le port à utiliser pour le test du SSH, il nous suffit donc de donner à cette variable pour valeur le numéro du port que l’on utilise pour le SSH.
Il nous faut rentrer cette valeur dans le fichier hosts.conf. Ouvrez-le. Il devrait ressembler à ça :

[pastacode lang=”bash” manual=”%2F*%0A%20*%20Host%20definitions%20with%20object%20attributes%0A%20*%20used%20for%20apply%20rules%20for%20Service%2C%20Notification%2C%0A%20*%20Dependency%20and%20ScheduledDowntime%20objects.%0A%20*%0A%20*%20Tip%3A%20Use%20%60icinga2%20object%20list%20–type%20Host%60%20to%0A%20*%20list%20all%20host%20objects%20after%20running%0A%20*%20configuration%20validation%20(%60icinga2%20daemon%20-C%60).%0A%20*%2F%0A%0A%2F*%0A%20*%20This%20is%20an%20example%20host%20based%20on%20your%0A%20*%20local%20host’s%20FQDN.%20Specify%20the%20NodeName%0A%20*%20constant%20in%20%60constants.conf%60%20or%20use%20your%0A%20*%20own%20description%2C%20e.g.%20%22db-host-1%22.%0A%20*%2F%0A%0Aobject%20Host%20NodeName%20%7B%0A%20%20%2F*%20Import%20the%20default%20host%20template%20defined%20in%20%60templates.conf%60.%20*%2F%0A%20%20import%20%22generic-host%22%0A%0A%20%20%2F*%20Specify%20the%20address%20attributes%20for%20checks%20e.g.%20%60ssh%60%20or%20%60http%60.%20*%2F%0A%20%20address%20%3D%20%22127.0.0.1%22%0A%20%20address6%20%3D%20%22%3A%3A1%22%0A%0A%20%20%2F*%20Set%20custom%20attribute%20%60os%60%20for%20hostgroup%20assignment%20in%20%60groups.conf%60.%20*%2F%0A%20%20vars.os%20%3D%20%22Linux%22%0A%0A%20%20%2F*%20Define%20http%20vhost%20attributes%20for%20service%20apply%20rules%20in%20%60services.conf%60.%20*%2F%0A%20%20vars.http_vhosts%5B%22http%22%5D%20%3D%20%7B%0A%20%20%20%20http_uri%20%3D%20%22%2F%22%0A%20%20%7D%0A%20%20%2F*%20Uncomment%20if%20you’ve%20sucessfully%20installed%20Icinga%20Web%202.%20*%2F%0A%20%20%2F%2Fvars.http_vhosts%5B%22Icinga%20Web%202%22%5D%20%3D%20%7B%0A%20%20%2F%2F%20%20http_uri%20%3D%20%22%2Ficingaweb2%22%0A%20%20%2F%2F%7D%0A%0A%20%20%2F*%20Define%20disks%20and%20attributes%20for%20service%20apply%20rules%20in%20%60services.conf%60.%20*%2F%0A%20%20vars.disks%5B%22disk%22%5D%20%3D%20%7B%0A%20%20%20%20%2F*%20No%20parameters.%20*%2F%0A%20%20%7D%0A%20%20vars.disks%5B%22disk%20%2F%22%5D%20%3D%20%7B%0A%20%20%20%20disk_partitions%20%3D%20%22%2F%22%0A%20%20%7D%0A%0A%20%20%2F*%20Define%20notification%20mail%20attributes%20for%20notification%20apply%20rules%20in%20%60notifications.conf%60.%20*%2F%0A%20%20vars.notification%5B%22mail%22%5D%20%3D%20%7B%0A%20%20%20%20%2F*%20The%20UserGroup%20%60icingaadmins%60%20is%20defined%20in%20%60users.conf%60.%20*%2F%0A%20%20%20%20groups%20%3D%20%5B%20%22icingaadmins%22%20%5D%0A%20%20%7D%0A%7D” message=”” highlight=”” provider=”manual”/]

la ligne object Host NodeName { marque le début de la configuration de votre host. Vous pouvez, si vous le souhaitez, remplace NodeName par un nom personnalisé.
La ligne import "generic-host" sert à charger le template du host, template qui est détaillé dans le fichier templates.conf.

Pour modifier la valeur de la variable “ssh_port”, et donc modifier le port du SSH, il suffit de rajouter la ligne vars.ssh_port = numéroport dans le host, entre object Host NodeName { et la dernière accolade.

Si vous souhaitez modifier un argument d’un autre service existant, le principe sera le même :

  1. Trouver le nom du service : il suffit d’aller sur l’interface web d’Icinga2
  2. Taper la commande icinga2 object list --name nomduservice --type checkcommand
  3. Voir dans la partie argument si un argument correspond à ce qu’on veut modifier.
  4. Récupérer le nom de la variable correspondant à cet argument
  5. Modifier la valeur de la variable dans le fichier hosts.conf en ajoutant la ligne vars.nom_variable = valeursouhaitée dans le host, entre object Host NodeName { et la dernière accolade.

On sait maintenant comment modifier un service existant. Mais comment créer un nouveau service afin de surveiller un serveur ftp ou un processus par exemple ? On verra ça dans un prochain article 😉

 

3 réponses pour “Modifier un service sur Icinga2”

  1. Ping : Icinga2 en configuration maître/client

  2. Baptiste25 octobre 2019 à 12 h 15 minRépondre

    Petite question :

    Comment faire quand on a des arguments qui prennent plusieurs valeurs ?
    Par exemple on fait
    ./check_load -r -w 0.15,0.10,0.05 -c 0.30,0.25,0.20

    Car
    “-w” = {
    value = “$wload$”
    }
    vars.wload = “0.15,0.10,0.05”

    Ne marche pas, il prend l’ensemble comme une valeur unique
    Voilà pour ma question, j’espère trouvé une réponse, merci d’avance !

    Baptiste

  3. fate25 octobre 2019 à 14 h 01 minRépondre

    Bonjour Baptise,

    Je ne sais pas d’où tu sors ““-w” = {
    value = “$wload$”
    }”, mais si tu suis les commandes données dans l’article, tu es censé trouver les variables à utiliser pour la charge.

    Voici comment faire pour la charge :
    Comme indiqué dans l’article, pour connaître la ou les arguments d’une commande, il faut lancer la commande linux “sudo icinga2 object list –name load –type checkcommand” (spécifique à ta demande vu que c’est la commande “load” qui t’intéresse). Tu vas avoir, dans la partie “arguments”, les lignes suivantes :
    * -c
    * description = “Exit with CRITICAL status if load average exceed CLOADn; the load average format is the same used by ‘uptime’ and ‘w'”
    * value = “$load_cload1$,$load_cload5$,$load_cload15$”
    * -w
    * description = “Exit with WARNING status if load average exceeds WLOADn”
    * value = “$load_wload1$,$load_wload5$,$load_wload15$”
    Là aussi comme indiqué dans l’article, tu as l’argument qui est donné, -c pour le criticals et -w pour les warnings, et à la suite de chaque argument tu as la ou les variables correspondant à cet argument.
    Tu vois donc que si tu veux modifier le seuil warning de la moyenne de charge sur une minute, il te faudra utiliser la variable load_wload1, pour la charge moyenne sur 5 minutes ça sera load_wload5, etc

    N’hésite pas si tu as d’autres questions 😉

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.