evolix/wiki
22
0
Fork 0
Code Releases Activity

Corrections & ajouts sur check santé du cluster

Browse source
This commit is contained in:
Ludovic Poujol 2017-06-08 17:33:33 +02:00
parent 3143a208bc
commit 4fedfed495
1 changed files with 30 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

36
HowtoIcinga.md
View file

@ -19,7 +19,7 @@ Il existe plusieurs manières de déployer Icinga2 pour surveiller un ensemble d
![Illustration des noms des rôles dans Icinga2](howtoicinga_distributed_roles.png)
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.
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**
@ -51,10 +51,12 @@ Dans la suite, on va détailler l'installation puis la configuration de plusieur
* *icinga2-master* (192.0.2.1) - Master de notre cluster. Il hébergera aussi l'interface web
* *icinga2-client1* (192.0.2.10) - Client qui va recevoir la configuration du master
* *icinga2-client2* (192.0.2.20) - Client qui va être juste servir de pont d'éxécution de commandes
* *icinga2-client2* (192.0.2.20) - Client qui va servir de pont d'éxécution de commandes
* *no-icinga2-host* (192.0.2.30) - Machine surveillée sans instance icinga2 locale
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.
L'installation d'icinga2 est relativement simple. C'est le même paquetage à utiliser quelque soit la fonction de la machine dans le cluster.
Autre détail, la documentation disponible en ligne conseille d'utiliser les paquetages officiels disponible sur les dépôts proposés par les développeurs. En effet la version présente dans les dépôts de débian est assez ancienne et ne couvre pas toutes les fonctionalité mentionées ici. (Une autre solution est d'utiliser la version présente dans les backports de jessie, mais tout les paquets relatifs à l'interface web y sont absent).
~~~
# wget -O - http://packages.icinga.com/icinga.key | apt-key add -
@ -302,7 +304,7 @@ Et voilà ! En théorie, le master et le client peuvent se parler ! Comme nous n
#### Cas A - Client avec configuration centrale sur 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).
Dans ce premier cas, les fichiers de configuration sont présent et 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 correspondant à la zone (donc le client appartenant à celle-ci) que l'on souhaite configurer :
~~~
@ -369,7 +371,7 @@ apply Service "ssh" {
#### Cas B - Configuration en pont d'éxécution de commandes
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/`).
Dans ce cas, toute la configuration va rester sur la machine *icinga2-master*. (et donc dans le dossier `/etc/icinga2/zone.d/icinga2-master/`). C'est le master qui va planifier l'exécution des checks.
Ainsi, on peut définir dans un fichier `icinga2-client2.conf`
@ -508,7 +510,6 @@ object Zone "global-templates" {
}
~~~
### Envoi de notifications
Contrôler le bon fonctionnement de services, c'est bien. Alerter en cas de défaillance c'est mieux !
@ -557,6 +558,29 @@ object TimePeriod "HO" {
}
~~~
### Contrôle de santé du cluster
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.
Exemple avec *cluster-zone* :
~~~
# cat /etc/icinga2/zone.d/icinga2-master/cluster.conf
apply Service "cluster-health" {
check_command = "cluster-zone"
display_name = "cluster-health-" + host.name
vars.cluster_zone = host.name
assign where host.vars.client_endpoint
}
~~~
### Haute disponibilité