18
0
Fork 0

MàJ Howto Icinga2

This commit is contained in:
Ludovic Poujol 2017-04-19 11:58:36 +02:00
parent 8470b8d09a
commit 69218c2842
1 changed files with 38 additions and 27 deletions

View File

@ -1,3 +1,8 @@
---
categories: monitorinf
title: Howto Icinga2
---
**Cette page a été importée automatiquement de notre ancien wiki. Elle est en cours de révision**
## Introduction
@ -8,7 +13,7 @@ Icinga2 se veut un remplacement pour Icinga, un fork bien établit de Nagios. Co
## Structure de l'infrastructure de monitoring
Il existe plusieurs manières de déployer Icinga2 pour surveiller un ensemble de machines. Icinga est assez flexible et permet de contruire des architectures distribuées ou centralisées en fonction des besoins. Pour mieux s'y retrouver, on peut donner des noms au noeuds en fonction de leur fonction :
Il existe plusieurs manières de déployer Icinga2 pour surveiller un ensemble de machines. Icinga est assez flexible et permet de contruire des architectures distribuées ou centralisées en fonction des besoins. Pour mieux s'y retrouver, on peut donner des noms aux machines (aka noeuds) qui hébergent une instance de icinga2 en fonction de leur utilité :
* Noeud master : Il est en haut de la hierarchie. C'est la machine centrale du cluster.
* Noeud satellite : C'est un fils d'un master ou d'un autre satellite.
@ -16,17 +21,17 @@ Il existe plusieurs manières de déployer Icinga2 pour surveiller un ensemble d
![Illustration des nom des rôles dans icinga2](howtoicinga2_distributed_roles.png)
A noter que cette hierarchie s'applique en premier lieux à des zones, les noeuds étant membre d'une zone. Habituellement une zone contient un seul noeud et porte le même nom que celui-ci par convention. Mais pour un master ou des satellites, on peut être amené à placer plusieurs noeuds dans une même zone pour les faire travailler ensemble en mode haute disponibilité et répartition de charge.
A noter que cette hierarchie s'applique en premier lieux à des `zones`, les noeuds étant membres d'une seule zone. Habituellement une zone contient un seul noeud et porte le même nom que celui-ci par convention. Mais pour un master ou des satellites, on peut être amené à placer plusieurs noeuds dans une même zone pour les faire travailler ensemble en mode haute disponibilité et répartition de charge. La notion de `zones` est très importante en mode cluster, car c'est elles qui sont directement configuées, les machines récupérant la configuration de la `zone` qui leur a été attribuée
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'appuier sur d'autres protocoles SNMP, SSH, NRPE...
A noter qu'il est aussi possible de surveiller des services sans la présence de l'agent icinga2. Pour cela on pourra s'appuier sur d'autres protocoles SNMP, SSH, NRPE pour exécuter de manière distante un check.
### Configuration locale (bottom up config sync)
**Attention, cette méthode est dépréciée depuis la sortie de la versions 2.6**
Dans ce mode de configuration, les machines locales sont configurées pour se surveiller elles-même et envoyer au serveur central les résultats. La configuration réside sur les machines locales et est synchronisée vers le serveur central.
Dans ce mode de configuration, les machines locales sont configurées pour se surveiller elles-même et remonter les résultats des checks. La configuration réside sur les machines locales et est synchronisée vers le serveur central.
L'avantage de cette méthode est que les clients locaux peuvent écrire leurs configurations directement sans à avoir à passer par une gestion centralisée des tests et des configurations.
@ -42,9 +47,9 @@ Plus [d'infos dans la documentation officielle (en anglais)](https://docs.icinga
### Pont d'exécution de commandes (top down command endpoint)
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 une 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 localemement (là où la commande est exécutée). Cela fonctionne sur le même principe que NRPE.
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 une 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 localemement (i.e. là où la commande est exécutée). Le principe est similaire à NRPE.
Cela implique cependant que les machines locales doivent accepter des commandes directement du serveur central
Cela implique cependant que les machines locales doivent accepter des commandes directement du 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-top-down-command-endpoint).
@ -66,13 +71,13 @@ L'installation d'`icinga2` sur le master est relativement simple. Cependant, la
# apt install icinga2
~~~
Pour finaliser l'installation d'icinga2 en master, il faut se servir de son assistant de configuration. Il se chargera de créer une CA 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:
Pour finaliser l'installation d'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:
~~~
# icinga2 node wizard
~~~
On termine par un redémarrage complet du daemon pour activer les changements de la configuration.
Après l'exécution de l'assitant, 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.
~~~
# service icinga2 restart
@ -80,7 +85,7 @@ On termine par un redémarrage complet du daemon pour activer les changements de
### WebUI
Pour fonctionner, la WebUI a besoin d'un serveur web avec PHP et d'un serveur de base de donnée. Dans les exemples qui suivent, nous utiliseront [/HowtoApache]() et [/HowtoLAMP/MySQL]().
Pour fonctionner, la WebUI a besoin d'un serveur web avec PHP et d'un serveur de base de donnée (MySQL ou PostgreSQL). Dans la suite de l'exemple, nous utiliseront [/HowtoApache]() et [/HowtoLAMP/MySQL]().
Ici, MySQL va servir à 2 choses :
@ -92,7 +97,7 @@ Ici, MySQL va servir à 2 choses :
# apt install icingaweb2 icinga2-ido-mysql
~~~
*Note* : Le paquetage `icinga2-ido-mysql` fournit un assistant d'installation pour configurer une base de donnée et un utilisateur MySQL automatiquement. Si on le souhaite, il est également possible de le faire manuellement. 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`
*Note* : Le paquetage `icinga2-ido-mysql` fournit un assistant d'installation pour configurer une base de donnée 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ée, 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`
Une fois l'installation terminée, il est nécessaire d'activer le module `ido-mysql` d'icinga2 :
@ -109,7 +114,9 @@ Il est possible de lancer des commandes (planifier un check, downtimer une machi
# service icinga2 restart
~~~
Pour continuer l'installation du WebUI, on visite le <http://example.org/icingaweb2/setup> L'installeur va nous demander un token. On peut créer ce token avec la commande suivante :
*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 du WebUI, 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 :
~~~
# icingacli setup token create
@ -119,9 +126,9 @@ La prochaine étape de l'assistant vous demande quelles fonctions activer. Il fa
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. Pour quelques comptes, il est cependant plus simple d'utiliser le backend basé sur une base de données.
`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 choisi 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ée n'existe pas encore et nous demander le mot de passe root pour en créer une pour nous. Encore une fois, il est possible de faire cela directement en ligne de commande avec MySQL.
Si l'on choisi 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ée 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ée créée précédemment pour `icinga2`. Si vous avez utilisé l'assitant 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`.
@ -131,9 +138,9 @@ Et voilà! Votre WebUI devrait être en place et vous devriez pouvoir vous conne
### Configuration du lien master-client
Par défaut, quand on installe icinga2 sur une machine, le daemon est lancé et icinga2 se met à surveiller l'hôte local. Pour cette documentation, nous allons monter une architecture de surveillance de type [#Configurationencluster "configuration en cluster"]. Cela va nous permettre de pouvoir centraliser la configuration à un seul endroit et de la gérer à travers Git.
Par défaut, quand on installe icinga2 sur une machine, le daemon est lancé et icinga2 se met à surveiller l'hôte local. Pour cette documentation, nous allons monter une architecture de surveillance de type [configuration en cluster](#Configurationencluster). Cela va nous permettre de pouvoir centraliser la configuration à un seul endroit et de la gérer à travers git.
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.
**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.
@ -201,7 +208,7 @@ Accept commands from master? [y/N]: n
~~~
icinga2 pki ticket --cn '<nom du client>'
~~~
Après l'exécution de l'assitant, 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 :
~~~
@ -217,13 +224,12 @@ object Zone "icinga2-client1" {
}
~~~
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 le WebUI.
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.
### Ajout de tests sur le client depuis le master
Avec le type de configuration que l'on a choisi, les fichiers de configuration sont modifiés sur le master, qui les synchronise sur le(s) client(s).
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 du nom du client que l'on souhaite configurer:
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:
~~~
# mkdir /etc/icinga2/zones.d/icinga2-client1
@ -234,8 +240,8 @@ Dans ce dossier, on crée un fichier nommé `hosts.conf` qui va nous servir à d
~~~
object Host "icinga2-client1" {
check_command = "hostalive"
address = "<adresse ip du client>"
zone = "master"
}
~~~
@ -263,16 +269,19 @@ Pour que la synchronisation se fasse entre le master et le client, on redémarre
# service icinga2 reload
~~~
Si tout s'est passé correctement, vous devriez voir apparaître une nouvelle machine dans le WebUI, accompagné de trois nouveaux services, `ping4`, `disk` et `ssh`.
*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 le WebUI, accompagné de trois nouveaux services, `ping4`, `disk` et `ssh`.
A noter que cette méthode de configuration est assez fastidieuse étant donné que l'on doit déclarer chaque services pour chaque 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
* Des conventions de nommage des machines (i.e. foo-mail -> correspond à \*-mail -> Application de services propres à un serveur mail (SMTP, IMAP, mailq...))
* L'appartenance à des groupes
* La présence d'attributs personalisés sur l'hôte
Ainsi, à place de définir 1000 services ssh pour 1000 machine linux, on va définir une fois le service ssh et l'appliquer au 1000 machines. Dans l'exemple suivant, on va ainsi appliquer le service ssh au machines dont on connais l'addresse et dont l'attribut personalisé de l'os a pour valeur "linux".
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 au machines dont on connais l'addresse et dont l'attribut personalisé de `os` a pour valeur "linux".
~~~
apply Service "ssh" {
@ -315,7 +324,7 @@ Le premier fichier à être lu au démarrage du daemon. Il sert à définir sous
Le fichier de configuration principal. Il sert surtout à définir les fichiers de configuration qui seront lus, comme `/features-enabled/*` par exemple. Ce fichier est le second à être lu au démarrage du daemon.
*Note* : En configuration en cluster, une bonne pratique est de commenter l'inclusion du dossier `conf.d`
*Note* : En configuration en cluster, une bonne pratique est de commenter l'inclusion du dossier `conf.d` et de placer la totalité de la configuration dans les zones qui seront déployées.
#### constants.conf
@ -347,7 +356,9 @@ Ce dossier regroupe les différents scripts qui sont lancés lors d'événements
#### conf.d/
Ce dossier regroupe les configurations de services sur le master et les configuration plus globales, comme les définitions de users et de groupes, ou encore les différents modes de surveillance (24h/7, 8h à 17h, etc.).
Ce dossier regroupe de base la configuration standard de l'instance icinga2. Quand on travaille en mode cluster, il est préférable de ne pas prendre appui dessus (en commentant la ligne d'inclusion dans le fichier `icinga2.conf`). A place on va mettre la totalité de la configuration dans les zones à fin qu'elle contrôlable et déployée depuis le master.
*Note* : On peut néanmoins copier son contenu dans le dossier de la zone du master et s'en servir comme base pour construire sa configuration.
#### repository.d/
@ -355,11 +366,11 @@ Ce dossier regroupe les configurations de services sur le master et les configur
#### zones.d/
Dans une configuration en mode cluster, ce dossier héberge sur le master la totalitée des configurations déployées dans des sous dossier. Chaque sous dossier contenant la configuration de la zonne ayant le même nom.
Dans une configuration en mode cluster, ce dossier héberge sur le master la totalitée des configurations déployées dans des sous dossier. Chaque sous dossiers contient la configuration de la zone ayant le même nom.
### Utilisation de NRPE
Lors de la bascule 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.
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.
Pour cela, il faut d'abord récupérer le client `NRPE` :