evolix/wiki
22
0
Fork 0
Code Releases Activity

ajout d'infos

Browse source
This commit is contained in:
Ludovic Poujol 2017-05-30 18:29:27 +02:00
parent 41eb76104a
commit 1529d9ec04
1 changed files with 26 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

39
HowtoIcinga.md
View file

@ -30,11 +30,7 @@ A noter qu'il est aussi possible de surveiller des services sans la présence de
**Attention, cette méthode est dépréciée depuis la sortie de la versions 2.6 et devrait être [retiré dans une future version](https://github.com/Icinga/icinga2/issues/4799)**
Dans ce mode de configuration, les machines locales sont configurées pour se surveiller elles-mêmes 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.
Plus [d'infos dans la documentation officielle (en anglais)](https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring#distributed-monitoring-bottom-up).
Dans ce mode de configuration, les machines locales sont configurées pour se surveiller elles-mêmes et remonter les résultats des checks. La configuration réside sur les machines locales et est synchronisée vers le 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-bottom-up).
### Configuration centrale (top down config sync)
@ -48,11 +44,8 @@ Plus [d'infos dans la documentation officielle (en anglais)](https://docs.icinga
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 un 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 localement (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.
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).
## Installation
Dans la suite, on va détailler une installation classique avec un cluster en **configuration centrale** (*top down configuration*). 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 un "client" (icinga2-client1, 192.0.2.10) qui va recevoir la configuration du master.
@ -82,9 +75,9 @@ Après l'exécution de l'assistant, notre master est configuré dans une zone ay
# service icinga2 restart
~~~
### WebUI
### Interface web
Pour fonctionner, la WebUI a besoin d'un serveur web avec PHP et d'un serveur de bases de données (MySQL ou PostgreSQL). Dans la suite de l'exemple, nous utiliseront [/HowtoApache]() et [/HowtoLAMP/MySQL]().
Pour fonctionner, l'interface web a besoin d'un serveur web avec PHP et d'un serveur de bases de données (MySQL ou PostgreSQL). Dans la suite de l'exemple, nous utiliseront [/HowtoApache]() et [/HowtoLAMP/MySQL]().
Ici, MySQL va servir à 2 choses :
@ -105,7 +98,7 @@ Une fois l'installation terminée, il est nécessaire d'activer le module `ido-m
# service icinga2 restart
~~~
Il est possible de lancer des commandes (planifier un check, downtimer une machine...) à partir du WebUI directement. Pour cela, il faut ajouter à l'utilisateur du serveur web au groupe `nagios`.
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`.
~~~
# addgroup --system www-data nagios
@ -115,7 +108,7 @@ Il est possible de lancer des commandes (planifier un check, downtimer une machi
*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 :
Pour continuer l'installation de l'interface wev, 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
@ -131,7 +124,7 @@ Si l'on choisit un backend base de données, il suffit de renter les information
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`.
Et voilà! Votre WebUI devrait être en place et vous devriez pouvoir vous connecter au <http://example.org/icingaweb2/>
Et voilà! Votre interface web devrait être en place et vous devriez pouvoir vous connecter au <http://example.org/icingaweb2/>
## Installation d'un client
@ -401,6 +394,26 @@ Ce dossier regroupe de base la configuration standard de l'instance icinga2. Qua
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.
### Timeperiods
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.
~~~
object TimePeriod "HO" {
import "legacy-timeperiod"
display_name = "Heures Ouvrées"
ranges = {
"monday" = "09:00-12:00,14:00-18:00"
"tuesday" = "09:00-12:00,14:00-18:00"
"wednesday" = "09:00-12:00,14:00-18:00"
"thursday" = "09:00-12:00,14:00-18:00"
"friday" = "09:00-12:00,14:00-18:00"
}
}
~~~
### Utilisation de NRPE
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.