typo + ajout zone globale & autres fix

This commit is contained in:
Ludovic Poujol 2017-06-08 16:15:13 +02:00
parent 2ba902dcc3
commit 3143a208bc

View file

@ -47,10 +47,12 @@ Plus [d'infos dans la documentation officielle (en anglais)](https://docs.icinga
## Installation
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 :
Dans la suite, on va détailler l'installation puis la configuration de plusieurs machines. Dans notre exemple on a quatre machines :
* *icinga2-client1* (192.0.2.10) qui va recevoir la configuration du master
* *icinga2-client2* (192.0.2.20) qui va être juste servir de pont d'éxécution de commandes
* *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
* *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.
@ -210,7 +212,7 @@ Et voilà! Votre interface web devrait être en place et vous devriez pouvoir vo
### Configuration d'un client
#### Configuration minimale
#### 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 ratacher au master du cluster.
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.
@ -399,7 +401,7 @@ object Service "ssh" {
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.
#### Cas C (bonus) - Monitoring d'une machine distante sans icinga2
#### Cas C - Monitoring d'une machine distante sans icinga2
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.
@ -425,6 +427,13 @@ Pour cela, il faut d'abord récupérer le client **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 *no-icinga2-host* décrite plus haut qui exécutera la commande *check_swap* par NRPE.
~~~
object Host "no-icinga2-host" {
import "generic-host"
check_command = "hostalive"
address = "192.0.2.30"
}
object Service "swap" {
import "generic-service"
@ -489,6 +498,17 @@ apply Service "ssh-nrpe-load" {
## Plus loin dans la configuration
### Zone globale
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 :
~~~
object Zone "global-templates" {
global = true
}
~~~
### Envoi de notifications
Contrôler le bon fonctionnement de services, c'est bien. Alerter en cas de défaillance c'est mieux !