[Icinga](https://www.icinga.com/) est un logiciel libre de surveillance système et réseau d'équipements. Au départ (en 2009), c'est un fork de [Nagios](https://www.nagios.com/) avec pour objectifs davantage d'évolutivité et une interface web plus moderne. La version 1 d'Icinga a une configuration compatible avec Nagios, ce qui n'est pas le cas de la version 2qui a été complètement ré-écrite.
* nœud **satellite** : pour le mode cluster, serveur rattaché au nœud master pour de la haute disponibilité
* nœud **client** : serveur chargé de lancer des commandes locales (semblable à un serveur *nrpe*)
On peut également découper la configuration Icinga en différentes zones où seront regroupées des nœuds master et satellite. Cette notion de zone permet d'avoir des nœuds distants, par exemple répartis dans plusieurs pays. (TODO: est-ce qu'une zone est super-master avec un noeud master qui contient toute la conf ??). Si l'on utilise un nœud client, il aura généralement sa propre zone.
La configuration d'Icinga se base sur des objets de types différents : l'objet **Host** définit une machine surveillée alors que l'objet **Service** définit un service rattaché à une machine. Voir [description détaillée de tous les objets](http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/object-types).
Le nom des fichiers contenant les objets n'est pas important, mais une bonne pratique est de séparer ses objets dans des fichiers du type `/etc/icinga2/zones.d/<ZONE>/hosts.conf` et `/etc/icinga2/zones.d/<ZONE>/services.conf` (si il n'y a qu'une zone, on peut l'appeler _master_).
On utilise l'assistant de configuration : il se chargera d'activer l'API et de créer une autorité de certification pour l'authentification avec les éventuels autres nœuds.
> *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 le faire manuellement, les paramètres sont stockés dans le fichier `/etc/icinga2/features-available/ido-mysql.conf` et le schéma des tables 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 web, il faut aller sur <http://monitoring.example.com/icingaweb2/setup> : un tocken sera demandé qui peut être créé avec la commande `icingacli setup token create`.
La prochaine étape de l'assistant demande quelles fonctions activer : il faut au moins activer le module **Monitoring** sinon l'interface web perd = 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).
Pour le paramétrage de l'authentification à l'interface web, on peut utiliser la même base de données utilisé par icinga2 pour exporter son état ou un annuaire LDAP.
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`.
C'est la méthode la plus simple, similaire à NRPE : le nœud master souhaitant effectuer un check, il lance une commande au travers de l'agent local icinga2 installé. 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).
_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)_
Avec cette méthode, les équipements sont configurés pour se surveiller eux-mêmes et remonter les résultats des checks. La configuration réside sur les machines locales et est synchronisée vers le nœud master.
Le principe est semblable à la méthode précédente, la 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 permet de centraliser l'ensemble de notre configuration.
#### Configuration de base
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 rattacher au master du cluster (TODO: on est dans quel mode ??)
C'est dans la configuration que l'on fera sur la machine *icinga2-master* que l'on va décider comment on utilise la machine.
On utilise l'assistant de configuration (_note_: les autres commandes `icinga2 node <paramètre>` sont dépréciées) :
> *Note* : Pour contrôler l'empreinte du certificat de la machine à laquelle on se connecte, on peut utiliser la commande `openssl x509 -noout -in /etc/icinga2/pki/icinga2-master.crt -fingerprint -sha1`
À 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 Icinga est réglée comme appartenant à sa propre *zone*. 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 Icinga 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. Pour controler la syntaxe de la configuration, on peut d'ailleurs utiliser la commande `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, toute la configuration va rester sur lae nœud master (et donc dans le dossier `/etc/icinga2/zone.d/master/`). C'est le master qui va planifier l'exécution des checks.
La définition de l'hôte et des services est quasi identique au 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 Icinga par d'autres moyens comme NRPE ou SSH. La commande de l'exécution des checks devra alors être prise en charge par un nœud du cluster Icinga. Idéalement, 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 *Icinga*, 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 Icinga n'est pas possible (restrictions firewall, NAT...). Dans ces cas là, on peut aussi exécuter des commandes via une connexion SSH.
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
Une bonne pratique est de créer une zone globale. Elle va aisi permettre de pousser des fichier de configuration sur tous les noeuds icinga2 du cluster. C'est pratique pour déployer des éléments de configuration générique et/ou globaux. Ainsi, si on appelle notre zone globale *global-templates*, il suffit de créer un dossier `/etc/icinga2/zone.d/global-templates` et d'ajouter le bloc suivant au fichier `/etc/icinga2/zone.conf` pour **chaque** installations d'icinga2 :
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.
Une autre bonne pratique est de rajouter des checks pour s'assurer du bon fonctionnement de notre cluster. Il existe deux commandes utilisables qui sont complémentaires :
* cluster : Elle s'assure que tout les *endpoints* de la zone soient actifs et que les zones directement connectés fonctionnent correctement
* cluster-zone : Elle s'assure que la zone donnée en paramètres est bien connecté au cluster
Idéalement, il faut donc utiliser **cluster** pour des zones de plus d'une machines, et **cluster-zone** pour s'assurer que chaque zone filles fonctionnent bien. Dans notre cas on va utiliser des checks *cluster-health* depuis le master pour s'assurer que nos deux endpoints *icinga2-client1* et *icinga2-client2* soient bien connectés.
Dans certaines situations, on va vouloir mettre plusieurs instances Icinga dans une même zone à fin de les faire travailler ensemble et ainsi répartir la charge et avoir une tolérance de panne. Les modules d'Icinga sont capables de gérer la répartition entre chaque membres actifs d'une même zone.
* 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.
