18
0
Fork 0

HowtoIcinga2 : Ajout de détails sur la structure du clustering

This commit is contained in:
Ludovic Poujol 2017-03-03 17:03:13 +01:00
parent 8bcf6b0ee7
commit 742a00ae8c
2 changed files with 23 additions and 13 deletions

View File

@ -1,7 +1,5 @@
**Cette page a été importée automatiquement de notre ancien wiki mais n'a pas encore été révisée.**
# Icinga2
## Introduction
Icinga2 est un logiciel de monitoring réseau qui vise à surveiller des services en place sur des serveurs.
@ -10,11 +8,21 @@ Icinga2 se veut un remplacement pour Icinga, un fork bien établit de Nagios. Co
## Structure
Il existe plusieurs manières de déployer Icinga2 pour surveiller un ensemble de machines. Il est important avant de commencer la mise en place d'Icinga2 de bien réfléchir à la manière dont on souhaite monter notre système. Trois architectures différentes sont possibles, toutes les trois s'appuyant sur l'agent icinga2 qui sera présent sur le serveur de surveillance (master) que sur les machines surveillées (clients).
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 :
A noter qu'il est aussi possible de controller des services sans la présence de l'agent icinga2. Pour cela on pourra s'appuier SNMP, SSH, NRPE...
* 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. Il sert à
* Noeud client : Il est en bas de la hierarchie, connecté a un satellite ou un master. Il agit comme un agent.
### Configuration locale (Déprécié)
![Nom de rôles icinga](howtoicinga2_distributed_roles.png)
A noter que cette hierarchie s'applique en premier lieux a des zones, les noeuds étant des éléments d'une zone. Habituellement une zone contient un seul noeud et porte le même nom que celui-ci. 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.
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...
### Configuration locale (bottom up config sync)
**Attention, cette méthode est dépréciée depuis la sortie de la versions 2.6**
@ -24,7 +32,7 @@ L'avantage de cette méthode est que les clients locaux peuvent écrire leurs co
Plus [d'infos ici](https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring#distributed-monitoring-bottom-up).
### Configuration en cluster
### Configuration centrale (top down config sync)
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 ».
@ -32,9 +40,9 @@ Cette méthode est idéale si l'on souhaite centraliser l'ensemble de notre conf
Plus [d'infos ici](https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring#distributed-monitoring-top-down-config-sync).
### Pont d'exécution de commandes
### 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.
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 implique cependant que les machines locales doivent accepter des commandes directement du serveur central
@ -260,7 +268,7 @@ Si tout s'est passé correctement, vous devriez voir apparaître une nouvelle ma
* `/etc/icinga2` Dossier des fichiers de configuration
* `/usr/share/icinga2/include` Dossier des templates & commandes par défaut
* `/var/lib/icinga2` Dossier de "travail" d'`icinga2`, contient la CA, les logs cluster, la configuration chargée, un fichier dump de l'état du cluster
* `/var/lib/icinga2` Dossier de "travail" d'`icinga2`, contient la CA, les logs cluster, la configuration chargée et/ou reçue, un fichier dump de l'état du cluster
### Fichiers de configuration
@ -270,7 +278,7 @@ Les fichiers de configuration se trouvent dans `/etc/icinga2`. Tous les fichiers
# apt -t jessie-backports install vim-icinga2
~~~
La configuration d'icinga2 se base principalement sur des objets de types différents. Par exemple, l'objet `Service` sert à définir un service à vérifier sur une machine, alors que l'objet `Host` définit un nouveau client. On peut retrouver une description détaillée de tous les objets [ici](http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/object-types).
La configuration d'icinga2 se base principalement sur des objets de types différents. Par exemple, l'objet `Host` définit une machine (indépendament de la présence de l'agent icinga2) alors que l'objet `Service` sert à définir un service et il est rataché à une machine. On peut retrouver une description détaillée de tous les objets [ici](http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/object-types).
En général, l'emplacement 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.
@ -279,12 +287,14 @@ En général, l'emplacement des objets n'est pas réellement important. Dans l'e
Le premier fichier à être lu au démarrage du daemon. Il sert à définir sous quel groupe et quel user le daemon est lancé.
*Note* : Sous Debian, icinga2 fonctionne sous l'utilisateur et le groupe `nagios`
*Note* : Sous Debian 8, icinga2 fonctionne sous l'utilisateur et le groupe `nagios`
#### icinga2.conf
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`
#### constants.conf
Ce fichier regroupe les constantes globales d'Icinga2. On y trouve entre autres le Salt pour la génération de tokens et le nom de domaine du master (`NodeName`).
@ -324,13 +334,13 @@ Ce dossier regroupe les configurations de services sur le master et les configur
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.
Premièrement, il faut récupérer le client `NRPE` :
Pour cela, il faut d'abord récupérer le client `NRPE` :
~~~
# apt install nagios-nrpe-plugin
~~~
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 `remote-nrpe-host` qui exécutera la commande `check_swap` par NRPE
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 `remote-nrpe-host` qui exécutera la commande `check_swap` par NRPE.
~~~
object Service "nrpe-swap" {

Binary file not shown.

After

Width:  |  Height:  |  Size: 19 KiB