Capensis.fr
Support professionnel

L'installation et la configuration d'un agent Icinga2 sur Windows et Linux

icinga

#1

Icinga

Sommaire

  1. Une machine Icinga peut avoir trois rôles bien spécifiques : Master / Satellite / Client
  2. Les deux manières de superviser
  1. Les protocoles permettant cette supervision
  1. Présentation
  2. Où le trouver ?
  3. L’installation
  1. La configuration des fichiers
  2. Quelques commandes utiles
  1. Répertoires d’Icinga
  2. Fichiers d’Icinga
  3. Mise en place d’une sonde

Icinga, c’est quoi ?

Icinga premier du nom est créé en 2009 à partir d’un Fork de Nagios, il est à l’époque le premier Fork dans le domaine de la supervision ! Mais c’est cinq ans plus tard, en 2014, que la version 2.0 baptisée Icinga2 voit le jour, version totalement réécrite à partir du langage C++.

Icinga2 est donc un outil de supervision Open Source réalisant la plupart des fonctions de ce que vous pouvez attendre d’un outil de supervision classique, c’est-à-dire : exécution de commandes, récupération d’informations, traitement de l’information, notification d’alertes, création de graphiques,…

Les trois choses que VOUS devez savoir !

Votre serveur Icinga est installé ? Vous voulez commencer l’aventure Icinga et sonder des milliers de clients ? Vous êtes à la bonne place !
Voici un bref résumé de ce que vous devez savoir avant de commencer à utiliser Icinga, n’hésitez pas à aller voir les sources et les liens utiles qui vont vous apporter une aide et un soutien supplémentaire ( pour cela, rendez-vous en bas de page :wink: ).

1. Une machine Icinga peut avoir trois rôles bien spécifiques : Master / Satellite / Client

Leur hiérarchie est simple :

master : serveur central
satellite : serveur dans une zone différente rattaché au nœud master
client : Chargé de lancer des commandes locales

img1

2. Les deux manières de superviser.

Maintenant il faut savoir de quelle manière vous voulez superviser. Il existe deux manières pour arriver à vos fins.
Les définitions du site officiel étant assez complexes pour les plus néophyte, je vous propose une traduction façon Capensis.

Top Down Command Endpoint

Ici, le serveur Icinga2 ou le satellite va exécuter des commandes à distance sur un de ses Endpoints (votre hôte par exemple).
Le serveur n’aura que votre hôte distant et un ou plusieurs services de définis tandis que le client n’a besoin, de son côté, que d’avoir la commande définie.

img2

Avantages
Aucune vérification locale n’a besoin d’être définie sur le noeud enfant (client).
Le fait que la vérification soit basé sur des événements asynchrones fait que celle-ci est très efficace. Autrement dit, le serveur ou le satellite n’attend pas la réponse du client pour exécuter une autre vérification.

Inconvénients
Si le noeud enfant n’est pas connecté ou déconnecté, aucune autre vérification n’est exécutée. La machine restera donc dans son état même si elle a un changement de statut et sera (DOWN).
Le maître nécessite un répertoire de configuration avec le nom de la zone en dessous de etc/icinga2/zones.d.

Top Down Config Sync

Ce mode synchronise les fichiers de configuration d’objet dans les zones spécifiées. C’est à dire que les fichier de commandes, services et d’hôtes vont être synchronisés de la zone parente (dans zone.d/) vers les zones enfants.

img3

Avantages
Aucun redémarrage manuel n’est requis sur les nœuds enfants, car la synchronisation, la validation et les redémarrages ont lieu automatiquement.
Icinga2 relit les fichiers de logs en cas de perte de connexion.

Inconvénients
Le journal de log est répliqué lors de la reconnexion après la perte de connexion. Cela peut augmenter le transfert de données et créer une surcharge sur la connexion.

3. Les protocoles permettant cette supervision.
Une image vaut milles mots, voici donc une image :

img4

L’agent d’Icinga2

Assurez-vous que votre serveur soit installé et configuré correctement et que vous ayez bien accès à l’interface web où votre serveur s’auto-supervise.

1. Présentation

L’agent Icinga va servir à lier le client au serveur d’un point de vue logiciel et permettre de réaliser votre supervision tant souhaitée.

2. Où le trouver ?

Windows : juste en cliquant ici !
Linux : Le paquet Icinga2 vous offre la possibilité de configurer votre serveur en mode Maître ou en mode Client (ou satellite). Il faudra bien sûr ici choisir la configuration en mode client pour votre hôte.

3. L’installation

Prêt à mettre les mains dans le cambouis ? C’est partis !

Premièrement et avant toutes choses il est nécessaire de faire la commande suivante sur votre serveur Icinga2 :
icinga2 pki ticket --cn nom_de_hôte

Commande servant à générer un ticket sous forme d’ID.

Gardez le bien au chaud car il va vous servir plus tard.

Sous Windows

Votre client Windows est prêt ? Il va maintenant être sondé. Pas de panique, je vous accompagne.

w1

w2
Acceptez (après avoir lu, ou pas, les GNU), et cliquez sur Next.

w3
Choix du répertoire d’installation d’Icinga. cliquez sur Next.

w4
Puis install !

w5
cliquez sur “Run Icinga2 setup wizard” puis sur Finish.

Une première étape de faite, la suite va consister à configurer cette installation pour la faire communiquer avec le serveur.

Premièrement, il y a deux champs à remplir :
Instance name qui correspond au FQDN du client et Setup ticket qui permet de remplir le ticket réalisé sur le serveur (voir l’étape d’installation).

Advanced options permet d’accepter les deux types de configurations : Top Down Command Endpoint pour la première case et Top Down Config Sync pour la seconde, configurer l’utilisateur du service (de base NT AUTHORITY\NetworkService) et enfin d’installer NSClient++.

Il est possible dans TCP Listener de permettre à notre hôte d’écouter ou pas sur le port 5665. Cliquez sur Listen for connections, lors d’un netstat vous pourrez voir que le port écoutera bien.

Maintenant, pour ajouter un hôte il faut cliquer sur Add.

w7

Dans cette fenêtre nous avons deux choses à remplir : Instance Name ET host qui correspondent au nom du noeud final maître / satellite. Cliquez sur OK, il va apparaître dans la section Master instance.

Juste une vérification que les certificats SSL du master soient bien configurés. Cliquez sur Next.

Maintenant il est temps d’installer et configurer NSClient ++, sur la fenêtre qui apparaît cliquez sur Next, puis choisissez Generic. On va ici choisir une installation custom et suivre les images suivantes.

w9
Il faut choisir “Will be installed on local hard drive”

w10

Sur cette dernière image, il vous est demandé de choisir un mot de passe permettant de vous connecter à l’interface web de NSClient++ que vous allez activer en cochant la dernière case.
Cette fenêtre sert à activer les check sur les plugins, activer votre NSClient server et votre NRPE server avec différents modes de sécurité disponibles, activer NSCA qui est un protocole.
Cliquez maintenant sur Next, puis Install.

Une fois votre ceci terminé, cliquez sur Next.

Vous pouvez désormais accéder à l’interface de NSClient++ via : https://localhost:8443

Vous pouvez maintenant voir une fenêtre Icinga 2 Service Status, et en cliquant sur Examine Config vous retrouverez votre configuration.

Rendez vous à l’étape La configuration des fichiers pour pouvoir continuer !

Sous Linux

Nous voilà maintenant sur Linux, la configuration revient plus ou moins à la même chose que ce que l’on a vu sous Windows mais sans interface graphique, évidement !

Premièrement, faites la commande icinga2 node wizard, vous allez rentrer dans la configuration de de votre client.

Ce wizard va vous demander tout d’abord si vous voulez configurer votre client en temps que satellite / client ou maître. Pressez entrer ou répondez Y pour démarrer la configuration en mode client.

Starting the Client/Satellite setup routine...

Maintenant entrez le CN du client :

Please specify the common name (CN) [CN_DU_CLIENT]: CN_DU_CLIENT

Ensuite, il faut spécifier le parent de notre client :

Please specify the parent endpoint(s) (master or satellite) where this node should connect to:

Master/Satellite Common Name (CN from your master/satellite node): CN_DU_MASTER

Entrez Y ou entrer pour établir la connexion à notre master :

Do you want to establish a connection to the parent node from this node? [Y/n]:

Ici on ajoute quelques détails de connexion à notre master.

Please specify the master/satellite connection information:
Master/Satellite endpoint host (IP address or FQDN): IP OU FQDN DU CLIENT
Master/Satellite endpoint port [5665]: 5665

Vous allez obtenir ceci, vérifiez les informations et entrez Y pour continuer :

Parent certificate information:

Subject:     CN = CN_DU_MASTER
Issuer:      CN = Icinga CA
Valid From:  XXX GMT
Valid Until: XXX GMT
Fingerprint: AC 99 8B 2B 3D B0 01 00 E5 21 FA 05 2E EC D5 A9 EF 9E AA E3

Is this information correct? [y/N]: y

Vous vous souvenez du ticket à garder précieusement ? Il faut maintenant le ressortir et le rentrer ici :

Please specify the request ticket generated on your Icinga 2 master (optional).
(Hint: # icinga2 pki ticket --cn 'CN_DU_CLIENT'):
ID DU TICKET

Ici il est possible de rentrer des informations optionnelles :

Please specify the API bind host/port (optional):
Bind Host []:
Bind Port []:

Comme sur Windows il est possible d’accepter les deux types de configurations : Top Down Command Endpoint pour la première proposition et Top Down Config Sync pour la seconde.

Accept config from parent node? [y/N]: y
Accept commands from parent node? [y/N]: y

Redémarrez Icinga, et c’est terminé !

Reconfiguring Icinga...
Done.
Now restart your Icinga 2 daemon to finish the installation!

systemctl restart icinga2

4. La configuration des fichiers.

Nous allons voir comment configurer nos client en Top down Command Endpoint fichiers par fichiers :

vim /etc/icinga2/zones.conf

object Endpoint "CN_DU_MASTER" {
  host = "IP_MASTER"
}

object Endpoint "CN_DU_CLIENT" {
  host = "IP_CLIENT"
}

object Zone "master" {
  endpoints = [ "CN_DU_MASTER" ]
}

object Zone "CN_DU_CLIENT" {
  endpoints = [ "CN_DU_CLIENT" ]
  parent = "master"
}

object Zone "global-templates" {
  global = true
}

vérifiez dans /etc/icinga2/features-enabled/api.conf chez le client que les options sont bien sur true.

object ApiListener "api" {
   //...
   accept_commands = true
   accept_config = true
}

Puis vérifiez les fichiers et redémarrez Icinga2.

icinga2 daemon -C
systemctl restart icinga2

Passez sur le master, nous allons créer une zone :

mkdir -p /etc/icinga2/zones.d/master

C’est ici que nous allons mettre nos fichiers services.conf, commands.conf et hosts.conf.

Il faut maintenant vérifier la configuration de nos fichiers, puis redémarrer Icinga2.

icinga2 daemon -C
systemctl restart icinga2

5. Quelques commandes utiles

  • icinga2 daemon -C pour la validation des fichiers, cela permet de repérer les erreurs de syntaxe et de savoir arguments ou de variables mal utilisée dans un des fichiers.

  • systemctl restart/reload/status icinga2.service commande assez explicite permettant de connaître l’état d’Icinga, de le redémarrer, etc.

  • /var/log/icinga2/icinga2.log emplacement des logs d’Icinga.

Exemple de mise en place de sondes

1. Répertoires d’Icinga

Vous allez principalement utiliser trois répertoires : conf.d , features et zone.d . Le premier contient des fichiers de paramétrage de Icinga2 et de définition des hôtes et services à vérifier. Il peut être aussi utilisé pour définir des constantes globales. Le second est un répertoire listant les composants d’Icinga2 disponibles. (director,api,checker…). Enfin zone.d sert à séparer ses objets (services,hosts,…) dans des zones distinctes.

2. Fichiers d’Icinga

Il y a trois principaux fichiers : hosts.conf, services.conf et commands.conf. Il sont tous trois liés et en concordance, de la définition des arguments à leur envoi vers le plugin. Voici leur hiérarchie.
hosts.conf est un fichier où sont définis des hôtes. A l’intérieur de chaque hosts est indiqué des services à tester spécifiques à ce host avec des variables que l’on retrouve dans service.conf , c’est dans hosts.conf qu’on va attribuer une valeur aux variables définies dans services.conf.
Ce dernier permet de créer un service à l’aide de l’attribut “Apply”. Il va définir une variable complétée par hosts.conf qui va être appelée dans commands.conf pour définir au plugin avec quel arguments il va fonctionner.
Pour chaque services il faut indiquer quel template, défini dans le fichier templates.conf , il va utiliser. On peut aussi définir sa zone d’action avec l’expression d’évaluation booléenne “assign where” (AND et OR utilisant && et ||). Ce fichier peut-être définit dans une zone.
commands.conf est un fichier qui va se servir de services.conf pour pouvoir faire fonctionner un plugin. Il sert à envoyer les arguments au plugin pour qu’il puisse renvoyer des informations pertinentes.

Il y a quelques autres fichiers ayant un rapport plus ou moins direct avec les précédents fichiers :
icinga2.conf : Ce fichier sert à ce que les paramètres de l’application Icinga2 soient pris en compte à l’aide de constantes tel que les plugins Linux et Windows, les répertoires en .conf, le répertoire de features,…
constants.conf : Le fichier constants.conf contient des constantes définissants les fichiers où sont stocké les plugins, les nom d’instances et de zone locale, la clé pour les tickets des noeuds distant. Il est possible d’ajouter autant de constantes que l’on souhaite.
zones.conf : Ce fichier sert à spécifier l’objet de configuration définissant la Zone et l’Endpoint requis pour la surveillance distribuée.
templates.conf : Ce fichier regroupe les configurations par défaut pour chaque type d’instances : services, hôte, serveur Icinga, … Ces configurations peuvent-être le temps entre chaque tests, l’accessibilité, un test de charge sur un service, les notifications, …

3. Mise en place d’une sonde

Vous aurez besoin de trois fichiers : hosts.conf, constants.conf, services.conf, dans cet exemple nous allons mettre en place une simple sonde qui contrôlera si un périphérique est monté sur le point de montage via SSH.

Nous allons d’abord configurer votre serveur, à noter que selon votre configuration il faudra écrire certains fichiers sur le client et d’autres sur le maître. Rendez-vous dans le fichier services.conf et y mettre les lignes suivantes.

apply Service "check_mount_" for ( name => fs in host.vars.check_mounts) {
import "generic service"
import "ts_service_by_ssh"
if ( fs.display_name){
display_name = fs.display_name
}
check_command = "command_check_mount"
check_interval = 60m
vars.check_mount_partition = name
}

Rendez-vous dans le fichier commands.conf, pour y mettre ces lignes :

object CheckCommand "command_check_mount" {
import "plugin-check-command"
import "tc_by_ssh"
vars.by_ssh_arguments = {
"-p" = "$check_mount_partition$"
}
vars.by_ssh_command = CHEMIN_VERS_PLUGIN + "/check_mount.sh"
}

Le “CHEMIN_VERS_PLUGIN” correspond à une constante définie dans constants.conf comme suis :

const Non_constante = "/usr/lib64/nagios/plugins" //Ou tout autres chemins où les plugins sont présents.

Le plugin est trouvable ici

Allez maintenant dans le fichier hosts.conf , nous allons faire en sorte que cette sonde soit utilisée par le serveur.
Dans l’Object Host correspondant à votre serveur, ajoutez ces lignes.

vars.check_mounts["/dev"]={
display_name="Display_Name_Mnt"
}

Maintenant rendez-vous sur votre interface web, vous aurez remarqué qu’une nouvelle sonde est apparue !

icinga

Sources

La source principale de cet article est le site officiel d’Icinga2 :
disponible ici
Ainsi que ce tutoriel de LunixTechi :
disponible ici
suite ici