Icinga est un fork bien établi de Nagios. Dans cette documentation, nous allons couvrir Icinga2. Contrairement à Icinga, qui reprenait une partie du code de Nagios et qui avait un système de configuration compatible, Icinga2 a été complètement réécrit et n'est pas compatible avec Nagios/Icinga.
Il existe plusieurs manières de déployer Icinga2 pour surveiller un ensemble de machines. Il peut fonctionner de manière centralisée ou distribuée. Icinga est assez flexible et permet de contruire des architectures en fonction des besoins. Pour mieux s'y retrouver, on peut catégoriser les instances Icinga2 en fonction de leur utilité :
Il faut savoir que cette hiérarchie s'applique en fait à des *zones* et non directement aux noeuds. Les noeuds (ou *endpoints*) font partie d'une *zone*. Habituellement une *zone* contient un seul noeud et porte le même nom par convention. Mais pour des *zones* de type master ou satellite, on peut être amené à placer plusieurs noeuds dans cette même *zone* pour les faire travailler ensemble en mode haute disponibilité et/ou répartition de charge.
C'est la notion de *zones* qui permet de décrire les portions de configuration à déployer sur les autres membres du cluster. La configuration contenue dans `/etc/icinga2/zone.d/foo` est poussé vers la zone **foo**
Pour configurer le cluster il existe 3 méthodes différentes, toutes les trois s'appuyant sur la présence de l'agent icinga2 sur les machines du cluster. A noter qu'il est aussi possible de surveiller des services sans la présence de l'agent icinga2. Pour cela on pourra s'appuyer sur d'autres protocoles comme SNMP, SSH, NRPE pour exécuter de manière distante un check.
**Attention, cette méthode est dépréciée depuis la sortie de la versions 2.6 et devrait être [retirée dans une future version](https://github.com/Icinga/icinga2/issues/4799)**
Dans ce mode de configuration, les machines locales sont configurées pour se surveiller elles-mêmes et remonter les résultats des checks. La configuration réside sur les machines locales et est synchronisée vers le serveur central. Plus [d'infos dans la documentation officielle (en anglais)](https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring#distributed-monitoring-bottom-up).
Le principe de la configuration en cluster est semblable à celui de la configuration locale. La seule différence est que la configuration des machines locales est faite sur le serveur central. Lorsque l'on redémarre le daemon, le serveur central s'assure que les machines locales ont la bonne configuration. Plutôt d'aller « du bas vers le haut » on va donc « du haut vers le bas ».
Cette méthode est idéale si l'on souhaite centraliser l'ensemble de notre configuration.
Plus [d'infos dans la documentation officielle (en anglais)](https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring#distributed-monitoring-top-down-config-sync).
Avec la méthode du pont d'exécution de commandes, l'ensemble des configurations sont sur le serveur central et y restent. Il n'y a pas de synchronisation de configuration avec les machines locales. Quand le serveur central souhaite effectuer un test sur une machine locale, il la lance directement sur cette dernière au travers de l'agent local icinga2. Le seul pré-requis est que les objets de type **CheckCommand** définissant les commandes à exécuter doivent être présent localement (i.e. là où la commande est exécutée). Le principe est similaire à NRPE.
Plus [d'infos dans la documentation officielle (en anglais)](https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring#distributed-monitoring-top-down-command-endpoint).
Dans la suite, on va détailler la configuration la configuration centrale et la configuration en pont d'éxécution de commandes. On a donc un "master" (*icinga2-master*, 192.0.2.1) qui héberge icinga2 avec toute la configuration du cluster et aussi l'interface web *icingaweb2* et deux clients :
L'installation d'icinga2 est relativement simple. Cependant, la documentation disponible en ligne conseille d'utiliser les paquetages officiels disponible sur les dépôts proposés par les développeurs.
La configuration d'icinga2 se base principalement sur des objets de types différents. Par exemple, l'objet **Host** définit une machine surveillée (indépendament de la présence de l'agent icinga2) alors que l'objet **Service** sert à définir un service rataché à une machine. On peut retrouver une description détaillée de tous les objets [ici (en anglais)](http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/object-types).
En général, le nom des fichiers contenant des objets n'est pas réellement important. Dans l'exemple plus haut, on aurait ainsi pu ajouter l'objet **Host** dans le fichier `/etc/icinga2/zones.d/icinga2-client1/foo_bar.conf` au lieu de `/etc/icinga2/zones.d/icinga2-client1/hosts.conf`. C'est cependant un bonne pratique de séparer clairement ses différents objets en fichiers nommés de manière claire.
Pour configurer Icinga2 en master, il faut se servir de son assistant de configuration. Il se chargera de créer une CA pour l'authentification avec les autres instances `icinga2` du cluster et activer l'API. La commande qui suit lance un assistant d'installation. Mis à part la première option où il faut répondre **n**, les autres peuvent être laissées vides pour conserver les valeurs par défaut :
Après l'exécution de l'assistant, notre master est configuré dans une zone ayant le même nom que lui. On termine par un redémarrage complet du daemon pour activer les changements de la configuration.
Pour fonctionner, l'interface web a besoin d'un serveur web avec PHP et d'un serveur de bases de données (MySQL ou PostgreSQL). Dans la suite de l'exemple, nous utiliseront [/HowtoApache]() et [/HowtoLAMP/MySQL]().
* Contenir les informations de configuration d'icinga2, le statut des hôtes et des services... qui sont mis à jour par le module **ido-mysql** d'icinga2
*Note* : Le paquetage *icinga2-ido-mysql* fournit un assistant d'installation pour configurer une base de données et un utilisateur MySQL automatiquement. Si on le souhaite, il est également possible de le faire manuellement. Il faut alors se charger de créer une base de données, un utilisateur ayant les accès à celle-ci et importer le schéma des tables. Les paramètres sont alors à écrire dans `/etc/icinga2/features-available/ido-mysql.conf` et le schéma des tables à importer est dans `/usr/share/icinga2-ido-mysql/schema/mysql.sql`
Il est possible de lancer des commandes (planifier un check, downtimer une machine...) à partir de l'interface web directement. Pour cela, il faut ajouter à l'utilisateur du serveur web au groupe **nagios**.
*Note* : Il est aussi possible de contrôler icinga2 directement via son API. Cela est pratique notament dans le cas où l'interface web n'est pas sur la même machine. Il faut à ce moment là créer un utilisateur API avec un couple login/pass et les renseigner dans la configuration de l'interface web.
Pour continuer l'installation de l'interface wev, il faut aller la page suivante <http://example.org/icingaweb2/setup>. L'installeur va nous demander un token. On peut créer ce token avec la commande suivante :
La prochaine étape de l'assistant vous demande quelles fonctions activer. Il faut au moins activer le mondule **Monitoring** (sinon, l'interface web perd tout son intérêt!).
L'assistant lance ensuite une série de tests. Il est important de s'assurer que tous les tests sont OK. Il est normal que les tests PostgreSQL s'affichent en jaune, car on utilise MySQL.
*Icingaweb2* offre plusieurs backends d'authentification. Pour une grande organisation, il est préférable d'utiliser le backend LDAP. Mais pour quelques comptes, il est cependant plus simple d'utiliser le backend basé sur une base de données.
Si l'on choisit un backend base de données, il suffit de renter les informations d'authentification que l'on souhaite avoir. La WebUI va ensuite nous informer que la base de données n'existe pas encore et nous demander le mot de passe administrateur pour en créer une pour nous. Encore une fois, il est possible de faire cela directement en ligne de commande avec MySQL.
Après avoir finalisé les informations pour l'authentification, il vous faudra donner au WebUI l'accès à la base de données créée précédemment pour *icinga2*. Si vous avez utilisé l'assistant de configuration du paquetage *icinga2-ido-mysql*, vous pourrez retrouver directement les informations d'authentification à MySQL utilisé par icinga2 dans `/etc/icinga2/features-available/ido-mysql.conf`.
Par défaut, quand on installe icinga2 sur une machine, le daemon est lancé et icinga2 se met à surveiller l'hôte local. Pour cet exemple, le client va être configuré de manière minimale pour juste le ratacher au master du cluster.
**Attention!** La seule commande `icinga2 node <paramètre>` que l'on devrait exécuter avec ce type de configuration est `icinga2 node wizard` au tout début du processus d'installation.
Malgré les apparences, les commandes `icinga2 node update-config` ou encore `icinga2 node add` s'appliquent à une configuration de type locale. De plus, ces commandes sont dépréciées.
À noter qu'à l'étape où l'assistant demande le ticket généré sur le master, il faut exécuter la commande suivante sur le master et copier l'output dans l'assistant :
Après l'exécution de l'assistant, l'instance icinga2 est réglée comme appartenant à sa propre *zone* (ayant le même nom que lui). Cette *zone* est fille du master renseigner lors de l'assistant.
Si client reconnaît maintenant le master, il est nécessaire de configurer le master pour qu'il reconnaisse le client. On va donc modifier le fichier *zones.conf* sur le master y ajouter la *zone* et le *endpoint* du nouveau client :
Et voilà ! En théorie, le master et le client peuvent se parler ! Comme nous n'avons pas encore configuré de test sur le nouveau client, il est normal qu'il n'apparaisse pas dans la WebUI.
Nous allons donc ajouter nos tests sur le master dans *zones.d*, le dossier prévu à cet effet. On commence par y créer un nouveau dossier correspondant à la zone (donc le client appartenant à celle-ci) que l'on souhaite configurer :
Dans ce dossier, on crée un fichier nommé *hosts.conf* qui va nous servir à définir un nouvel objet de type *Host*. Cet objet va nous permettre par la suite de lier d'autres types d'objets à notre nouveau client :
*Note* : Si, pour une raison ou une autre, la configuration venait à être invalide lors du reload, celui-ci va être avorté. Mais icinga2 va continuer de fonctionner avec l'ancienne configuration valide chargée avant. En effet, il contrôle la configuration avant de demander au daemon de s'arréter.
*Note* : Pour controler la syntaxe de la configuration, on peut utiliser la commande `service icinga2 checkconfig` ou `icinga2 daemon --validate`
Si tout s'est passé correctement, vous devriez voir apparaître une nouvelle machine dans l'inteface web, accompagné de deux nouveaux services : *disk* et *ssh*.
A noter que cette méthode de configuration est assez fastidieuse étant donné que l'on doit déclarer chaques services pour chaques machines. Ainsi, on tendra a préviligier l'utilisation de gabarits que l'on va ensuite appliquer sur les machines en fonctions de règles. Ces règles peuvent être basées sur :
* Des conventions de nommage des machines (i.e. foo-mail -> correspond à \*-mail -> Application de services propres à un serveur mail (SMTP, IMAP, mailq...))
Ainsi, à place de définir 1000 services ssh pour 1000 machine linux, on va définir une fois le service ssh et l'appliquer aux 1000 machines. Dans l'exemple suivant, on va ainsi appliquer le service ssh aux machines dont on connait l'addresse et dont l'attribut vars.os a pour valeur "linux".
Dans ce cas présent, toute la configuration va rester sur la machine *icinga2-master*. (et donc dans le dossier `/etc/icinga2/zone.d/icinga2-master/`).
La définition de l'hôte et des services est quasi identique que dans le cas précédent. Cependant, il faut ajouter en plus l'attribut **command_endpoint** aux objets de type *Service* pour definir l'*Endpoint* qui doit être commandé pour exécuter la commande.
Comme annoncé plus haut, il est aussi possible de surveiller une machine qui n'aurait pas icinga2 par d'autres moyens comme NRPE ou SSH. La commande de l'exécution des checks devra alors être prise en charge par un noeud du cluster icinga2. Idealement, un *master* ou un *satellite*. Ainsi, la configuration proposée doit être entreposée dans le dossier de la zone qui aura la charge de la surveillance de la machine.
Lors d'une migration de *nagios* vers *icinga2*, il peut être intéréssant de supporter tout les checks fait par NRPE pour fluidifier la transition vers la nouvelle plateforme.
En suite, il suffit juste de créer les services dans la configuration du master pour paramettrer les checks voulu. L'exemple suivant crée un service *swap* pour la machine *no-icinga2-host* décrite plus haut qui exécutera la commande *check_swap* par NRPE.
Dans certaines situations, l'utilisation de NRPE, ou icinga2 n'est pas possible (restrictions firewall, NAT...). Dans ces cas là, on peut aussi exécuter des commandes via une connexion SSH.
Quelques pré-requis avant :
* L'utilisateur du daemon icinga2 doit avoir une clé ssh pour s'authentifier. Celle-ci doit être autorisée par l'hôte distant.
* Le daemon doit avoir l'empreinte du serveur ssh dans son known_hosts. (Sinon, il refusera de se connecter)
* Les scripts/plugins/commandes à exécuter doivent être présents sur la machine et exécutables par l'utilisateur utilisé par icinga2
Avec ces pré-requis, il suffit alors de définir une commande de check important l'objet *by_ssh* fournit avec icinga2. Ensuite, il suffit d'utiliser cette commande lors de la définition des services
Contrôler le bon fonctionnement de services, c'est bien. Alerter en cas de défaillance c'est mieux !
On peut définir un objet notification qui sera appliqué a nos services pour envoyer des mails. Il utilisera le script d'envoi d'emails fournit avec icinga2
L'objet **Notification** 'mail' est définit pour envoyer une notification par couriel à l'utilisateur 'foo' lorsqu'un service est en état *Critical* ou *Unknown* sur la période *9to5* fournit dans la configuration par défaut.
On peut facilement décrire de nouveaux objets **Timeperiod** pour décrire par exemple les heures ouvrées et envoyer des notifications uniquement durant cette période. Ici, c'est défini du lundi au vendredi, de 9h à 12h et de 14h à 18h.
Dans certaines situations, on va vouloir mettre plusieurs instances icinga2 (ou *endpoint*) dans une même zone à fin de les faire travailler ensemble et ainsi répartir la charge et avoir une tolérance de panne.
* notification : De même, il peut répartir l'envoi des notifications entre chaque machines. C'est aussi désactivable avec le paramètre *enable_ha* - A ce moment là chaque noeuds avec la fonctionalité de notification active envera une notification
* ido-{mysql,postgresql} : Là, les noeuds de la zone vont s'accorder pour qu'une seule instance écrive dans la base de données MySQL. Si l'instance en charge d'écrire est down, une autre prendra la relève. Désactivable avec le paramettre *enable_ha*
Pour ajouter un nouveau noeud une *zone* master, il suffit de l'installer normalement comme expliqué plus haut, puis d'ajuster le fichier `zone.conf` pour faire en sorte que les deux noeuds appartiennent bien à la même zone.
Dans certains cas, on peut être amené à générer manuellement le certificat TLS pour l'authentification d'un nouveau noeud.
La commande suivante sert à générer une CSR, pour une machine "icinga2-client2". Elle peut être directement lancée sur la machine désignée ou depuis le master du cluster (si la machine monitorée n'as pas encore été provisionée par exemple).
~~~
# icinga2 pki new-cert --cn icinga2-client2 \
--key icinga2-client2.key \
--csr icinga2-client2.csr
~~~
En suite, depuis le master, on génère le certificat avec la CSR.
