Refactor how to icinga
This commit is contained in:
parent
3cf3c1a999
commit
cfe5ef44c4
101
HowtoIcinga.md
101
HowtoIcinga.md
|
|
@ -19,11 +19,11 @@ Il existe plusieurs manières de déployer Icinga2 pour surveiller un ensemble d
|
|||
|
||||
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
C'est la notion de `zones` qui permet de décrire les portions de configuration à déployer sur les autres membres du cluster. La configuration contenue dans `/etc/icinga2/zone.d/foo` est poussé vers la zone `foo`
|
||||
|
||||
A noter qu'il est aussi possible de surveiller des services sans la présence de l'agent icinga2. Pour cela on pourra s'appuyer sur d'autres protocoles comme SNMP, SSH, NRPE pour exécuter de manière distante un check.
|
||||
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. A noter qu'il est aussi possible de surveiller des services sans la présence de l'agent icinga2. Pour cela on pourra s'appuyer sur d'autres protocoles comme SNMP, SSH, NRPE pour exécuter de manière distante un check.
|
||||
|
||||
### Configuration locale (bottom up config sync)
|
||||
|
||||
|
|
@ -47,7 +47,9 @@ 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", un avec (icinga2-client1, 192.0.2.10) qui va recevoir la configuration du master.
|
||||
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 :
|
||||
* 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
|
||||
|
||||
### Installation du master
|
||||
|
||||
|
|
@ -127,9 +129,10 @@ Et voilà! Votre interface web devrait être en place et vous devriez pouvoir vo
|
|||
|
||||
## Installation d'un client
|
||||
|
||||
### Configuration du lien master-client
|
||||
### Installation & configuration minimale
|
||||
|
||||
Par défaut, quand on installe icinga2 sur une machine, le daemon est lancé et icinga2 se met à surveiller l'hôte local. Pour cette documentation, nous allons monter une architecture de surveillance de type [configuration en cluster](#Configurationencluster). Cela va nous permettre de pouvoir centraliser la configuration à un seul endroit et de la gérer à travers git.
|
||||
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.
|
||||
|
||||
**Attention!** La seule commande `icinga2 node <paramètre>` que l'on devrait exécuter avec ce type de configuration est `icinga2 node wizard` au tout début du processus d'installation.
|
||||
|
||||
|
|
@ -191,7 +194,7 @@ Please specify the API bind host/port (optional):
|
|||
Bind Host []:
|
||||
Bind Port []:
|
||||
Accept config from master? [y/N]: y
|
||||
Accept commands from master? [y/N]: n
|
||||
Accept commands from master? [y/N]: y
|
||||
~~~
|
||||
|
||||
*Note* : Pour contrôler l'empreinte du certificat de la machine à laquelle on se connecte, on peut utiliser la commande suivante sur celle-ci :
|
||||
|
|
@ -205,6 +208,7 @@ openssl x509 -noout -in /etc/icinga2/pki/icinga2-master.crt -fingerprint -sha1
|
|||
~~~
|
||||
icinga2 pki ticket --cn '<nom du client>'
|
||||
~~~
|
||||
|
||||
Après l'exécution de l'assistant, l'instance icinga2 est réglée comme appartenant à sa propre `zone` (ayant le même nom que lui). Cette `zone` est fille du master renseigner lors de l'assistant.
|
||||
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 :
|
||||
|
||||
|
|
@ -223,7 +227,7 @@ object Zone "icinga2-client1" {
|
|||
|
||||
Et voilà ! En théorie, le master et le client peuvent se parler ! Comme nous n'avons pas encore configuré de test sur le nouveau client, il est normal qu'il n'apparaisse pas dans la WebUI.
|
||||
|
||||
### Ajout de tests sur le client depuis le master
|
||||
### Cas A - Client avec configuration centrale sur le master
|
||||
|
||||
Avec le type de configuration que l'on a choisi, les fichiers de configuration sont modifiés sur le master, qui les synchronise sur le(s) client(s).
|
||||
Nous allons donc ajouter nos tests sur le master dans `zones.d`, le dossier prévu à cet effet. On commence par y créer un nouveau dossier correspondant à la zone (donc le client appartenant à celle-ci) que l'on souhaite configurer :
|
||||
|
|
@ -290,37 +294,43 @@ apply Service "ssh" {
|
|||
}
|
||||
~~~
|
||||
|
||||
### Envoi de notifications
|
||||
Contrôler le bon fonctionnement de services, c'est bien. Alerter en cas de défaillance c'est mieux !
|
||||
### Cas B - Configuration en pont d'éxécution de commandes
|
||||
|
||||
On peut définir un objet notification qui sera appliqué a nos services pour envoyer des mails. Il utilisera le script d'envoi d'emails fournit avec icinga2
|
||||
Dans ce cas présent, toute la configuration va rester sur la machine `icinga2-master`. (et donc dans le dossier `/etc/icinga2/zonne.d/icinga2-master/`).
|
||||
|
||||
Ainsi, on peut définir dans un fichier `icinga2-client2.conf`
|
||||
|
||||
~~~
|
||||
apply Notification "mail" to Service {
|
||||
import "mail-service-notification"
|
||||
object Host "icinga2-client2" {
|
||||
import "generic-host"
|
||||
|
||||
users = ["foo"]
|
||||
states = [ Critical, Unknown ]
|
||||
period = "9to5"
|
||||
check_command = "hostalive"
|
||||
address = "192.0.2.20"
|
||||
}
|
||||
|
||||
assign where true
|
||||
object Service "disk" {
|
||||
import "generic-service"
|
||||
|
||||
command_endpoint = "icinga2-client2"
|
||||
host_name = "icinga2-sclient2"
|
||||
check_command = "disk"
|
||||
}
|
||||
|
||||
object Service "ssh" {
|
||||
import "generic-service"
|
||||
|
||||
command_endpoint = "icinga2-client2"
|
||||
host_name = "icinga2-sclient2"
|
||||
check_command = "ssh"
|
||||
}
|
||||
~~~
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
~~~
|
||||
object User "foo" {
|
||||
import "generic-user"
|
||||
|
||||
display_name = "Foo"
|
||||
email = "foo@example.net"
|
||||
}
|
||||
~~~
|
||||
### Cas C (bonnus) - Cas du monitoring d'une machine distante sans icinga2
|
||||
|
||||
## 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 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 zonne qui aura la charge de la surveillance de la machine.
|
||||
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 zonne qui aura la charge de la surveillance de la machine.
|
||||
|
||||
~~~
|
||||
object Host "no-icinga2-host" {
|
||||
|
|
@ -331,7 +341,7 @@ object Host "no-icinga2-host" {
|
|||
}
|
||||
~~~
|
||||
|
||||
### Utilisation de NRPE
|
||||
#### 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.
|
||||
|
||||
|
|
@ -354,7 +364,7 @@ object Service "swap" {
|
|||
}
|
||||
~~~
|
||||
|
||||
### Utilisation de SSH
|
||||
#### 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.
|
||||
|
||||
|
|
@ -406,8 +416,39 @@ apply Service "ssh-nrpe-load" {
|
|||
}
|
||||
~~~
|
||||
|
||||
## Envoi de notifications
|
||||
|
||||
Contrôler le bon fonctionnement de services, c'est bien. Alerter en cas de défaillance c'est mieux !
|
||||
|
||||
On peut définir un objet notification qui sera appliqué a nos services pour envoyer des mails. Il utilisera le script d'envoi d'emails fournit avec icinga2
|
||||
|
||||
~~~
|
||||
apply Notification "mail" to Service {
|
||||
import "mail-service-notification"
|
||||
|
||||
users = ["foo"]
|
||||
states = [ Critical, Unknown ]
|
||||
period = "9to5"
|
||||
|
||||
assign where true
|
||||
}
|
||||
~~~
|
||||
|
||||
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.
|
||||
|
||||
~~~
|
||||
object User "foo" {
|
||||
import "generic-user"
|
||||
|
||||
display_name = "Foo"
|
||||
email = "foo@example.net"
|
||||
}
|
||||
~~~
|
||||
|
||||
|
||||
## Clustering
|
||||
|
||||
*ToDo*
|
||||
|
||||
## Plomberie
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue