18
0
Fork 0

Refactor how to icinga2

This commit is contained in:
Ludovic Poujol 2017-06-05 18:35:36 +02:00
parent dc3d81cb2f
commit 757b54742e
1 changed files with 93 additions and 83 deletions

View File

@ -11,7 +11,7 @@ Icinga est un fork bien établi de Nagios. Dans cette documentation, nous allons
## Structure de l'infrastructure de monitoring
Il existe plusieurs manières de déployer Icinga2 pour surveiller un ensemble de machines. Icinga est assez flexible et permet de contruire des architectures distribuées ou centralisées en fonction des besoins. Pour mieux s'y retrouver, on peut donner des noms aux machines (ou noeuds) qui hébergent une instance de icinga2 en fonction de leur utilité :
Il existe plusieurs manières de déployer Icinga2 pour surveiller un ensemble de machines. Il peut fonctionner de manière centralisée ou distribuée. Icinga est assez flexible et permet de contruire des architectures en fonction des besoins. Pour mieux s'y retrouver, on peut catégoriser les instances icinga2 en fonction de leur utilité :
* Noeud master : Il est en haut de la hierarchie. C'est la machine centrale du cluster.
* Noeud satellite : C'est un fils d'un master ou d'un autre satellite.
@ -19,8 +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 appartenant à 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 aussi la notion de `zones` qui permet de décrire les portions de configuration à déployer sur les autres membres du cluster.
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 aussi la notion de `zones` qui permet de décrire les portions de configuration à déployer sur les autres membres du cluster.
Pour configurer le cluster il existe 3 méthodes différentes, toutes les trois s'appuyant sur la présence de l'agent icinga2 sur les machines du cluster.
@ -48,7 +47,7 @@ Plus [d'infos dans la documentation officielle (en anglais)](https://docs.icinga
## 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.
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", un avec (icinga2-client1, 192.0.2.10) qui va recevoir la configuration du master.
### Installation du master
@ -237,8 +236,9 @@ Dans ce dossier, on crée un fichier nommé `hosts.conf` qui va nous servir à d
~~~
object Host "icinga2-client1" {
check_command = "hostalive"
import "generic-host"
check_command = "hostalive"
address = "192.0.2.10"
}
~~~
@ -318,6 +318,93 @@ object User "foo" {
}
~~~
## Cas du monitoring d'une machine distante sans icinga2
Comme annoncé plus haut, il est possible de surveiller une machine qui n'aurait pas icinga2 d'installé par d'autres moyens comme NRPE ou SSH pour vérrifier le bon fonctionnement des services d'une machine. L'exécution du check 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 zonne qui aura la charge de la surveillance de la machine.
~~~
object Host "other-host" {
import "generic-host"
check_command = "hostalive"
address = "192.0.2.10"
}
~~~
### 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.
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 `other-host` décrite plus haut qui exécutera la commande `check_swap` par NRPE.
~~~
object Service "swap" {
import "generic-service"
host_name = "other-host"
check_command = "nrpe"
vars.nrpe_command = "check_swap"
}
~~~
### Utilisation de SSH
Dans certaines situations, l'utilisation de NRPE, ou icinga2 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 :
* L'utilisateur du daemon icinga2 doit avoir une clé ssh pour s'authentifier. Celle-ci doit être autorisée par l'hôte distant.
* Le daemon doit avoir l'empreinte du serveur ssh dans son known_hosts. (Sinon, il refusera de se connecter)
* Les scripts/plugins/commandes à exécuter doivent être présents sur la machine et exécutables par l'utilisateur utilisé par icinga2
Avec ces pré-requis, il suffit alors de définir une commande de check important l'objet `by_ssh` fournit avec icinga2. Ensuite, il suffit d'utiliser cette commande lors de la définition des services
~~~
object CheckCommand "by_ssh_swap" {
import "by_ssh"
vars.by_ssh_command = "/usr/lib/nagios/plugins/check_swap -w $by_ssh_swap_warn$ -c $by_ssh_swap_crit$"
vars.by_ssh_swap_warn = "75%"
vars.by_ssh_swap_crit = "50%"
}
object Service "swap" {
import "generic-service"
host_name = "other-host"
check_command = "by_ssh_swap"
vars.by_ssh_logname = "icinga"
}
~~~
*Cool fact* : on peut même faire du NRPE par SSH (dans le cas d'une machine en NAT ou avec un firewall assez restrictif). Exemple :
~~~
object CheckCommand "nrpe_via_ssh" {
import "by_ssh"
vars.by_ssh_command = "/usr/lib/nagios/plugins/check_nrpe -H $host.vars.internalIP$ $service.vars.nrpe_command$"
vars.by_ssh_logname = "monitoring"
}
apply Service "ssh-nrpe-load" {
import "generic-service"
check_command = "nrpe_via_ssh"
vars.nrpe_command = "-c check_load"
vars.notification_period = "worktime"
assign where host.vars.service_base && host.check_command == "nrpe_via_ssh"
}
~~~
## Plomberie
@ -413,85 +500,8 @@ object TimePeriod "HO" {
}
~~~
### Gestion de la PKI - Génération manuelle des certificats
### 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.
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 `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"
}
~~~
### Utilisation de SSH
Dans certaines situations, l'utilisation de NRPE, ou icinga2 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 :
* L'utilisateur du daemon icinga2 doit avoir une clé ssh pour s'authentifier. Celle-ci doit être autorisée par l'hôte distant.
* Le daemon doit avoir l'empreinte du serveur ssh dans son known_hosts. (Sinon, il refusera de se connecter)
* Les scripts/plugins/commandes à exécuter doivent être présents sur la machine et exécutables par l'utilisateur utilisé par icinga2
Avec ces pré-requis, il suffit alors de définir une commande de check important l'objet `by_ssh` fournit avec icinga2. Ensuite, il suffit d'utiliser cette commande lors de la définition des services
~~~
object CheckCommand "by_ssh_swap" {
import "by_ssh"
vars.by_ssh_command = "/usr/lib/nagios/plugins/check_swap -w $by_ssh_swap_warn$ -c $by_ssh_swap_crit$"
vars.by_ssh_swap_warn = "75%"
vars.by_ssh_swap_crit = "50%"
}
object Service "swap" {
import "generic-service"
host_name = "remote-ssh-host"
check_command = "by_ssh_swap"
vars.by_ssh_logname = "icinga"
}
~~~
*Cool fact* : on peut donc faire du NRPE par SSH (dans le cas d'une machine en NAT ou avec un firewall assez restrictif). Exemple :
~~~
object CheckCommand "nrpe_via_ssh" {
import "by_ssh"
vars.by_ssh_command = "/usr/lib/nagios/plugins/check_nrpe -H $host.vars.internalIP$ $service.vars.nrpe_command$"
vars.by_ssh_logname = "monitoring"
}
apply Service "ssh-nrpe-load" {
import "generic-service"
check_command = "nrpe_via_ssh"
vars.nrpe_command = "-c check_load"
vars.notification_period = "worktime"
assign where host.vars.service_base && host.check_command == "nrpe_via_ssh"
}
~~~
### 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.
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).