18
0
Fork 0

Typo3...SOLEIL (+ correction liens, déplacement de la partie sur la configuration en sous partie de la plomberie et ajout de quelques infos sur NRPE) icinga2

This commit is contained in:
Ludovic Poujol 2017-02-24 15:27:14 +01:00
parent ad8eeb5536
commit bb445214f0
1 changed files with 59 additions and 33 deletions

View File

@ -22,7 +22,7 @@ Dans ce mode de configuration, les machines locales sont configurées pour se su
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 ici](https://github.com/Icinga/icinga2/blob/master/doc/6-distributed-monitoring.md#-bottom-up-import).
Plus [d'infos ici](https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring#distributed-monitoring-bottom-up).
### Configuration en cluster
@ -30,7 +30,7 @@ Le principe de la configuration en cluster est semblable à celui de la configur
Cette méthode est idéale si l'on souhaite centraliser l'ensemble de notre configuration.
Plus [d'infos ici](https://github.com/Icinga/icinga2/blob/master/doc/6-distributed-monitoring.md#-top-down-config-sync).
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
@ -38,7 +38,7 @@ Avec la méthode du pont d'exécution de commandes, l'ensemble des configuration
Cela implique cependant que les machines locales doivent accepter des commandes directement du serveur central
Plus ["d'infos ici"](https://github.com/Icinga/icinga2/blob/master/doc/6-distributed-monitoring.md#-top-down-command-endpoint).
Plus [d'infos ici](https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring#distributed-monitoring-top-down-command-endpoint).
## Installation du master
@ -68,7 +68,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 [/HowtoLAMP/Apache] et [/HowtoLAMP/MySQL].
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]().
Ici, MySQL va servir à 2 choses :
@ -82,7 +82,7 @@ Ici, MySQL va servir à 2 choses :
*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`
Une fois l'installation terminée, il est nécessaire d'activer le module `ido-mysql` d'icinga2:
Une fois l'installation terminée, il est nécessaire d'activer le module `ido-mysql` d'icinga2 :
~~~
# icinga2 feature enable ido-mysql
@ -97,7 +97,7 @@ 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:
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 :
~~~
# icingacli setup token create
@ -107,13 +107,13 @@ La prochaine étape de l'assistant vous demande quelles fonctions activer. Il es
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ée.
`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.
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.
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`.
Et voilà! Votre WebUI devrait être en place et vous devriez pouvoir vous connecter au <http://example.org/icingaweb2.>
Et voilà! Votre WebUI devrait être en place et vous devriez pouvoir vous connecter au <http://example.org/icingaweb2/>
## Installation d'un client
@ -125,7 +125,7 @@ Attention! La seule commande `icinga2 node <paramètre>` que l'on devrait exécu
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 aussi dépréciées.
On commence donc par installer `icinga2`:
On commence donc par installer `icinga2` :
~~~
# wget -O - http://packages.icinga.com/icinga.key | apt-key add -
@ -134,13 +134,13 @@ On commence donc par installer `icinga2`:
# apt install icinga2
~~~
Une fois que cela est fait, on lance l'assistant de configuration:
Une fois que cela est fait, on lance l'assistant de configuration :
~~~
# icinga2 node wizard
~~~
L'assistant nous pose plusieurs questions. On y répond de la manière suivante:
L'assistant nous pose plusieurs questions. On y répond de la manière suivante :
~~~
Please specify if this is a satellite setup ('n' installs a master setup) [Y/n]: y
@ -190,7 +190,7 @@ Accept commands from master? [y/N]: n
icinga2 pki ticket --cn '<nom du client>'
~~~
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:
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,7 +217,7 @@ Nous allons donc ajouter nos tests sur le master dans `zones.d`, le dossier pré
# mkdir /etc/icinga2/zones.d/icinga2-client1
~~~
Dans ce dossier, on crée un fichier nommé `hosts.conf` qui va nous servir à définir un nouvel objet de type `Host`. Cet objet va nous permettre par la suite de lier d'autres types d'objets à notre nouveau client:
Dans ce dossier, on crée un fichier nommé `hosts.conf` qui va nous servir à définir un nouvel objet de type `Host`. Cet objet va nous permettre par la suite de lier d'autres types d'objets à notre nouveau client :
~~~
object Host "icinga2-client1" {
@ -227,23 +227,25 @@ object Host "icinga2-client1" {
}
~~~
On peut maintenant ajouter de nouveaux tests dans `services.conf`, des objets de type `Service`:
On peut maintenant ajouter de nouveaux tests dans `services.conf`, des objets de type `Service` :
~~~
object Service "disk" {
host_name = "icinga2-sclient1"
import "generic-service"
host_name = "icinga2-sclient1"
check_command = "disk"
}
object Service "ssh" {
host_name = "icinga2-sclient1"
import "generic-service"
host_name = "icinga2-sclient1"
check_command = "ssh"
}
~~~
Pour que la synchronisation se fasse entre le master et le client, on redémarre `icinga2` sur le master:
Pour que la synchronisation se fasse entre le master et le client, on redémarre `icinga2` sur le master :
~~~
# service icinga2 reload
@ -251,7 +253,16 @@ Pour que la synchronisation se fasse entre le master et le client, on redémarre
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`.
## Fichiers de configuration
## Plomberie
### Dossiers par défaut d'icinga2
* `/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
### Fichiers de configuration
Les fichiers de configuration se trouvent dans `/etc/icinga2`. Tous les fichiers de configuration utilisent la même syntaxe. Il existe d'ailleurs un plugin vim pour cette dernière:
@ -264,27 +275,27 @@ La configuration d'icinga2 se base principalement sur des objets de types diffé
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.
### init.conf
#### init.conf
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`
### icinga2.conf
#### 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.
### constants.conf
#### 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`).
### zones.conf
#### zones.conf
Ce fichier sert à définir les relations entre le master et les clients, comme démontré dans l'exemple de configuration plus haut.
### features-available
#### features-available
Les fichiers dans ce dossier sont des plugins qui peuvent être activés avec les commandes suivantes:
Les fichiers dans ce dossier sont des plugins qui peuvent être activés avec les commandes suivantes :
~~~
# icinga2 feature enable <nom du plugin>
@ -293,26 +304,41 @@ Les fichiers dans ce dossier sont des plugins qui peuvent être activés avec le
Une fois activés, il sont symlinkés dans `/features-enabled`, un peu comme pour Apache.
### pki
#### pki
Ce dossier regroupe les fichiers du Public Key Infrastructure (PKI), qui servent de base d'authentification entre les clients et le master. Dans le cas du master, certains fichiers sont des duplicatas de fichiers dans `/var/lib/icinga2/ca/`.
### scripts
#### scripts
Ce dossier regroupe les différents scripts qui sont lancés lors d'un événement. Par exemple, c'est ici que l'on ajouterais de nouveaux scripts à être lancé pour des objets de type `EventCommand`.
### conf.d
#### 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, 8 à 17h, etc.).
### repository.d et zones.d
#### repository.d et zones.d
`repository.d` regroupe les configurations des clients lors d'une synchronisation de type locale. À l'inverse, pour une configuration de type cluster, les fichiers se retrouveraient plutôt dans le dossier `zones.d`.
## Plomberie
### Utilisation de NRPE
### Dossiers par défaut d'icinga2
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.
* `/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
Premièrement, il faut 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
~~~
object Service "nrpe-swap" {
import "generic-service"
host_name = "remote-nrpe-host"
check_command = "nrpe"
vars.nrpe_command = "check_swap"
}
~~~