Relecture.
This commit is contained in:
parent
9383ff8fc1
commit
b0849bbcfe
|
|
@ -5,7 +5,7 @@ title: Howto Icinga
|
|||
|
||||
* Documentation : <https://docs.icinga.com/>
|
||||
|
||||
[Icinga](https://www.icinga.com/) est un logiciel libre de surveillance système et réseau d'équipements. Au départ (en 2009), c'est un fork de [Nagios](https://www.nagios.com/) avec pour objectifs davantage d'évolutivité et une interface web plus moderne. La version 1 d'Icinga a une configuration compatible avec Nagios, ce qui n'est pas le cas de la version 2 qui a été complètement ré-écrite.
|
||||
[Icinga](https://www.icinga.com/) est un logiciel libre de surveillance système et réseau d'équipements. Au départ (en 2009), c'est un fork de [Nagios](https://www.nagios.com/) avec pour objectifs davantage d'évolutivité et une interface web plus moderne. La version 1 d'Icinga a une configuration compatible avec Nagios, ce qui n'est pas le cas de la version 2 qui a été complètement ré-écrite.
|
||||
|
||||
Après avoir utilisé Nagios pendant plus de 10 ans, nous utilisons désormais Icinga.
|
||||
|
||||
|
|
@ -63,7 +63,7 @@ Icinga peut avoir différents rôles :
|
|||
* nœud **satellite** : serveur dans une zone différente rattaché au nœud master
|
||||
* nœud **client** : serveur chargé de lancer des commandes locales (semblable à un serveur *nrpe*)
|
||||
|
||||
On peut donc découper la configuration Icinga en différentes zones : la zone principale avec le(s) nœud(s) master et des zones secondaires pour les nœuds satellite. Cette notion de zone permet par exemple d'avoir des nœuds des nœuds répartis dans plusieurs pays. Si l'on utilise un nœud client, il aura généralement sa propre zone.
|
||||
On peut donc découper la configuration Icinga en différentes zones : la zone principale avec le(s) nœud(s) master et des zones secondaires pour les nœuds satellite. Cette notion de zone permet par exemple d'avoir des nœuds des nœuds répartis dans plusieurs pays. Si l'on utilise un nœud client, il aura généralement sa propre zone.
|
||||
|
||||
|
||||
## Configuration
|
||||
|
|
@ -92,7 +92,7 @@ On peut donc découper la configuration Icinga en différentes zones : la zone p
|
|||
|
||||
La configuration d'Icinga se base sur des objets de types différents : l'objet **Host** définit une machine surveillée alors que l'objet **Service** définit un service rattaché à une machine. Voir [description détaillée de tous les objets](http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/object-types).
|
||||
|
||||
Le nom des fichiers contenant les objets n'est pas important, mais une bonne pratique est de séparer ses objets dans des fichiers du type `/etc/icinga2/zones.d/<ZONE>/hosts.conf` et `/etc/icinga2/zones.d/<ZONE>/services.conf` (si il n'y a qu'une zone, on peut l'appeler _master_).
|
||||
Le nom des fichiers contenant les objets n'est pas important, mais une bonne pratique est de séparer ses objets dans des fichiers du type `/etc/icinga2/zones.d/<ZONE>/hosts.conf` et `/etc/icinga2/zones.d/<ZONE>/services.conf` (s’il n'y a qu'une zone, on peut l'appeler _master_).
|
||||
|
||||
|
||||
## Configuration nœud master
|
||||
|
|
@ -141,7 +141,7 @@ Une fois l'installation terminée, il est nécessaire d'activer le module **ido-
|
|||
# systemctl restart icinga2
|
||||
~~~
|
||||
|
||||
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**.
|
||||
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
|
||||
|
|
@ -149,9 +149,9 @@ Il est possible de lancer des commandes (planifier un check, downtimer une machi
|
|||
# service icinga2 restart
|
||||
~~~
|
||||
|
||||
> *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.
|
||||
> *Note* : Il est aussi possible de contrôler icinga2 directement via son API. Cela est pratique notamment 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 de l'interface web, il faut aller sur <http://monitoring.example.com/icingaweb2/setup> : un token sera demandé qui peut être créé avec la commande `icingacli setup token create`.
|
||||
Pour continuer l'installation de l'interface web, il faut aller sur <http://monitoring.example.com/icingaweb2/setup>, un token sera demandé qui peut être créé avec la commande `icingacli setup token create`.
|
||||
|
||||
La prochaine étape de l'assistant demande quelles fonctions activer : il faut au moins activer le module **Monitoring** sinon l'interface web perd son intérêt !
|
||||
|
||||
|
|
@ -159,7 +159,7 @@ L'assistant lance ensuite une série de tests. Il est important de s'assurer que
|
|||
|
||||
Pour le paramétrage de l'authentification à l'interface web, on peut utiliser la base de données utilisé par le module IDO ou avoir d'autre backend (LDAP, etc.).
|
||||
|
||||
L'assistant va ensuite avoir besoin des paramètres d'accès à la base de données, on pourra réutiliser les paramètres utilisé pour IDO via le fichier `/etc/icinga2/features-available/ido-mysql.conf`.
|
||||
L'assistant va ensuite avoir besoin des paramètres d'accès à la base de données, on pourra réutiliser les paramètres utilisés pour IDO via le fichier `/etc/icinga2/features-available/ido-mysql.conf`.
|
||||
|
||||
L'interface web est désormais accessible via <http://monitoring.example.org/icingaweb2/>
|
||||
|
||||
|
|
@ -259,7 +259,7 @@ C'est la méthode la plus simple, similaire à NRPE : le nœud master souhaitant
|
|||
|
||||
<https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring#distributed-monitoring-bottom-up>
|
||||
|
||||
_Attention, cette méthode est dépréciée depuis la sortie de la versions 2.6 et devrait être [retirée dans une future version](https://github.com/Icinga/icinga2/issues/4799)_
|
||||
_Attention, cette méthode est dépréciée depuis la sortie de la version 2.6 et devrait être [retirée dans une future version](https://github.com/Icinga/icinga2/issues/4799)_
|
||||
|
||||
Avec cette méthode, les équipements sont configurés pour se surveiller eux-mêmes et remonter les résultats des checks. La configuration réside sur les machines locales et est synchronisée vers le nœud master.
|
||||
|
||||
|
|
@ -315,17 +315,17 @@ Pour que la synchronisation se fasse entre le master et le client, on redémarre
|
|||
# systemctl reload icinga2
|
||||
~~~
|
||||
|
||||
> *Note* : Si, pour une raison ou une autre, la configuration venait à être invalide lors du reload, celui-ci va être avorté. Mais Icinga va continuer de fonctionner avec l'ancienne configuration valide chargée avant. En effet, il contrôle la configuration avant de demander au daemon de s'arréter. Pour controler la syntaxe de la configuration, on peut d'ailleurs utiliser la commande `icinga2 daemon --validate`
|
||||
> *Note* : Si, pour une raison ou une autre, la configuration venait à être invalide lors du reload, celui-ci va être avorté. Mais Icinga va continuer de fonctionner avec l'ancienne configuration valide chargée avant. En effet, il contrôle la configuration avant de demander au daemon de s'arrêter. Pour contrôler la syntaxe de la configuration, on peut d'ailleurs utiliser la commande `icinga2 daemon --validate`
|
||||
|
||||
Si tout s'est passé correctement, vous devriez voir apparaître une nouvelle machine dans l'inteface web, accompagné de deux nouveaux services : *disk* et *ssh*.
|
||||
Si tout s'est passé correctement, vous devriez voir apparaître une nouvelle machine dans l'interface web, accompagné de deux nouveaux services : *disk* et *ssh*.
|
||||
|
||||
A noter que cette méthode de configuration est assez fastidieuse étant donné que l'on doit déclarer chaques services pour chaques machines. Ainsi, on tendra a préviligier l'utilisation de gabarits que l'on va ensuite appliquer sur les machines en fonctions de règles. Ces règles peuvent être basées sur :
|
||||
À noter que cette méthode de configuration est assez fastidieuse étant donné que l'on doit déclarer chaque services pour chaque machines. Ainsi, on tendra à privilégier l'utilisation de gabarits que l'on va ensuite appliquer sur les machines en fonctions de règles. Ces règles peuvent être basées sur :
|
||||
|
||||
* Des conventions de nommage des machines (i.e. foo-mail -> correspond à \*-mail -> Application de services propres à un serveur mail (SMTP, IMAP, mailq...))
|
||||
* Des conventions de nommage des machines (i.e. foo-mail -> correspond à \*-mail -> Application de services propres à un serveur mail (SMTP, IMAP, mailq…))
|
||||
* L'appartenance à des groupes
|
||||
* La présence d'attributs personalisés sur l'hôte
|
||||
* La présence d'attributs personnalisés sur l'hôte
|
||||
|
||||
Ainsi, à place de définir 1000 services ssh pour 1000 machine linux, on va définir une fois le service ssh et l'appliquer aux 1000 machines. Dans l'exemple suivant, on va ainsi appliquer le service ssh aux machines dont on connait l'addresse et dont l'attribut vars.os a pour valeur "linux".
|
||||
Ainsi, à place de définir 1000 services ssh pour 1000 machine linux, on va définir une fois le service ssh et l'appliquer aux 1000 machines. Dans l'exemple suivant, on va ainsi appliquer le service ssh aux machines dont on connait l'adresse et dont l'attribut vars.os a pour valeur "linux".
|
||||
|
||||
~~~
|
||||
apply Service "ssh" {
|
||||
|
|
@ -338,7 +338,7 @@ apply Service "ssh" {
|
|||
|
||||
#### Cas B - Configuration en pont d'éxécution de commandes
|
||||
|
||||
Dans ce cas, toute la configuration va rester sur lae nœud master (et donc dans le dossier `/etc/icinga2/zone.d/master/`). C'est le master qui va planifier l'exécution des checks.
|
||||
Dans ce cas, toute la configuration va rester sur le nœud master (et donc dans le dossier `/etc/icinga2/zone.d/master/`). C'est le master qui va planifier l'exécution des checks.
|
||||
|
||||
Ainsi, on peut définir dans un fichier `icinga2-client2.conf` :
|
||||
|
||||
|
|
@ -367,10 +367,10 @@ object Service "ssh" {
|
|||
}
|
||||
~~~
|
||||
|
||||
La définition de l'hôte et des services est quasi identique au 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.
|
||||
La définition de l'hôte et des services est quasi identique au cas précédent. Cependant, il faut ajouter l'attribut **command_endpoint** aux objets de type *Service* pour definir l'*Endpoint* qui doit être commandé pour exécuter la commande.
|
||||
|
||||
|
||||
### Surveiller un équipement sans Icinga (NRPE, SSH etc.)
|
||||
### Surveiller un équipement sans Icinga (NRPE, SSH, etc.)
|
||||
|
||||
Comme annoncé plus haut, il est aussi possible de surveiller une machine qui n'aurait pas Icinga par d'autres moyens comme NRPE ou SSH. La commande de l'exécution des checks devra alors être prise en charge par un nœud du cluster Icinga. Idéalement, 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.
|
||||
|
||||
|
|
@ -385,7 +385,7 @@ object Host "no-icinga2-host" {
|
|||
|
||||
#### Utilisation de NRPE
|
||||
|
||||
Lors d'une migration de *Nagios* vers *Icinga*, il peut être intéréssant de supporter tout les checks fait par NRPE pour fluidifier la transition vers la nouvelle plateforme.
|
||||
Lors d'une migration de *Nagios* vers *Icinga*, il peut être intéressant de supporter tous les checks fait par NRPE pour fluidifier la transition vers la nouvelle plateforme.
|
||||
|
||||
Pour cela, il faut d'abord récupérer le client **NRPE** :
|
||||
|
||||
|
|
@ -393,7 +393,7 @@ 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 *no-icinga2-host* décrite plus haut 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 paramétrer 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" {
|
||||
|
|
@ -415,7 +415,7 @@ object Service "swap" {
|
|||
|
||||
#### Utilisation de SSH
|
||||
|
||||
Dans certaines situations, l'utilisation de NRPE ou Icinga n'est pas possible (restrictions firewall, NAT...). Dans ces cas là, on peut aussi exécuter des commandes via une connexion SSH.
|
||||
Dans certaines situations, l'utilisation de NRPE ou Icinga n'est pas possible (restrictions firewall, NAT…). Dans ces cas-là, on peut aussi exécuter des commandes via une connexion SSH.
|
||||
|
||||
Quelques pré-requis avant :
|
||||
|
||||
|
|
@ -470,7 +470,7 @@ apply Service "ssh-nrpe-load" {
|
|||
|
||||
### 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 :
|
||||
Une bonne pratique est de créer une zone globale. Elle va ainsi permettre de pousser des fichiers de configuration sur tous les nœuds 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" {
|
||||
|
|
@ -496,7 +496,7 @@ apply Notification "mail" to Service {
|
|||
}
|
||||
~~~
|
||||
|
||||
L'objet **Notification** 'mail' est définit pour envoyer une notification par couriel à l'utilisateur 'foo' lorsqu'un service est en état *Critical* ou *Unknown* sur la période *9to5* fournit dans la configuration par défaut.
|
||||
L'objet **Notification** 'mail' est définit pour envoyer une notification par courriel à l'utilisateur 'foo' lorsqu'un service est en état *Critical* ou *Unknown* sur la période *9to5* fournit dans la configuration par défaut.
|
||||
|
||||
~~~
|
||||
object User "foo" {
|
||||
|
|
@ -533,7 +533,7 @@ Une autre bonne pratique est de rajouter des checks pour s'assurer du bon foncti
|
|||
* 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.
|
||||
Idéalement, il faut donc utiliser **cluster** pour des zones de plus d'une machine, 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* :
|
||||
|
||||
|
|
@ -552,22 +552,22 @@ apply Service "cluster-health" {
|
|||
|
||||
### Haute disponibilité
|
||||
|
||||
Dans certaines situations, on va vouloir mettre plusieurs instances Icinga dans une même zone à fin de les faire travailler ensemble et ainsi répartir la charge et avoir une tolérance de panne. Les modules d'Icinga sont capables de gérer la répartition entre chaque membres actifs d'une même zone.
|
||||
Dans certaines situations, on va vouloir mettre plusieurs instances Icinga dans une même zone à fin de les faire travailler ensemble et ainsi répartir la charge et avoir une tolérance de panne. Les modules d'Icinga sont capables de gérer la répartition entre chaque membre actifs d'une même zone.
|
||||
|
||||
Modules avec des fonctions de haute disponibilité :
|
||||
|
||||
* checker : Il va répartir l'exécution des checks entre chaque machines de la zone
|
||||
* notification : De même, il peut répartir l'envoi des notifications entre chaque machines. C'est aussi désactivable avec le paramètre *enable_ha* - A ce moment là chaque noeuds avec la fonctionalité de notification active envera une notification
|
||||
* ido-{mysql,postgresql} : Là, les noeuds de la zone vont s'accorder pour qu'une seule instance écrive dans la base de données MySQL. Si l'instance en charge d'écrire est down, une autre prendra la relève. Désactivable avec le paramettre *enable_ha*
|
||||
* checker : Il va répartir l'exécution des checks entre chaque machine de la zone
|
||||
* notification : De même, il peut répartir l'envoi des notifications entre chaque machine. C'est aussi désactivable avec le paramètre *enable_ha* - A ce moment-là chaque nœuds avec la fonctionnalité de notification active enverra une notification
|
||||
* ido-{mysql,postgresql} : Là, les nœuds de la zone vont s'accorder pour qu'une seule instance écrive dans la base de données MySQL. Si l'instance en charge d'écrire est down, une autre prendra la relève. Désactivable avec le paramètre *enable_ha*
|
||||
|
||||
Pour ajouter un nouveau noeud une *zone* master, il suffit de l'installer normalement comme expliqué plus haut, puis d'ajuster le fichier `zone.conf` pour faire en sorte que les deux noeuds appartiennent bien à la même zone.
|
||||
Pour ajouter un nouveau nœud une *zone* master, il suffit de l'installer normalement comme expliqué plus haut, puis d'ajuster le fichier `zone.conf` pour faire en sorte que les deux nœuds appartiennent bien à la même zone.
|
||||
|
||||
|
||||
### Gestion de la PKI - Génération manuelle des certificats
|
||||
|
||||
Dans certains cas, on peut être amené à générer manuellement le certificat TLS pour l'authentification d'un nouveau noeud.
|
||||
Dans certains cas, on peut être amené à générer manuellement le certificat TLS pour l'authentification d'un nouveau nœud.
|
||||
|
||||
La commande suivante sert à générer une CSR, pour une machine "icinga2-client2". Elle peut être directement lancée sur la machine désignée ou depuis le master du cluster (si la machine monitorée n'as pas encore été provisionée par exemple).
|
||||
La commande suivante sert à générer une CSR, pour une machine "icinga2-client2". Elle peut être directement lancée sur la machine désignée ou depuis le master du cluster (si la machine monitorée n'a pas encore été provisionnée par exemple).
|
||||
|
||||
~~~
|
||||
# icinga2 pki new-cert --cn icinga2-client2 \
|
||||
|
|
@ -581,13 +581,13 @@ En suite, depuis le master, on génère le certificat avec la CSR.
|
|||
# icinga2 pki sign-csr --csr icinga2-client2.csr --cert icinga2-client2
|
||||
~~~
|
||||
|
||||
Il ne reste plus qu'a rappatrier les fichiers `/etc/icinga2/pki/icinga2-client2.*` sur la machine désignée.
|
||||
Il ne reste plus qu'a rapatrier les fichiers `/etc/icinga2/pki/icinga2-client2.*` sur la machine désignée.
|
||||
|
||||
## FAQ
|
||||
|
||||
### Que veut-dire « Icinga » ?
|
||||
|
||||
C'est un mot zulu signifiant « il recherche » ou « il examine ».
|
||||
C'est un mot zulu signifiant « il recherche » ou « il examine ».
|
||||
|
||||
### plugin Vim pour la syntaxe de la configuration d'Icinga
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue