Refactor how to icinga
This commit is contained in:
parent
69ae773953
commit
7380b8708a
|
|
@ -11,13 +11,13 @@ 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. 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é :
|
||||
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.
|
||||
* Noeud client : Il est en bas de la hierarchie, connecté a un satellite ou un master. Il agit comme un agent.
|
||||
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
|
@ -296,7 +296,7 @@ apply Service "ssh" {
|
|||
|
||||
### Cas B - Configuration en pont d'éxécution de commandes
|
||||
|
||||
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/`).
|
||||
Dans ce cas présent, toute la configuration va rester sur la machine `icinga2-master`. (et donc dans le dossier `/etc/icinga2/zone.d/icinga2-master/`).
|
||||
|
||||
Ainsi, on peut définir dans un fichier `icinga2-client2.conf`
|
||||
|
||||
|
|
@ -328,9 +328,9 @@ object Service "ssh" {
|
|||
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.
|
||||
|
||||
|
||||
### Cas C (bonnus) - Cas du monitoring d'une machine distante sans icinga2
|
||||
### Cas C (bonnus) - Monitoring d'une machine distante sans icinga2
|
||||
|
||||
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.
|
||||
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 zone qui aura la charge de la surveillance de la machine.
|
||||
|
||||
~~~
|
||||
object Host "no-icinga2-host" {
|
||||
|
|
@ -416,7 +416,9 @@ apply Service "ssh-nrpe-load" {
|
|||
}
|
||||
~~~
|
||||
|
||||
## Envoi de notifications
|
||||
## Plus loin dans la configuration
|
||||
|
||||
### Envoi de notifications
|
||||
|
||||
Contrôler le bon fonctionnement de services, c'est bien. Alerter en cas de défaillance c'est mieux !
|
||||
|
||||
|
|
@ -445,10 +447,38 @@ object User "foo" {
|
|||
}
|
||||
~~~
|
||||
|
||||
### Timeperiods
|
||||
|
||||
## Clustering
|
||||
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"
|
||||
}
|
||||
}
|
||||
~~~
|
||||
|
||||
|
||||
### Haute disponibilité
|
||||
|
||||
Dans certaines situations, on va vouloir mettre plusieurs instances icinga2 (ou `endpoint`) 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 capable de gérer la répartition entre chaque membres 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`
|
||||
|
||||
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.
|
||||
|
||||
*ToDo*
|
||||
|
||||
## Plomberie
|
||||
|
||||
|
|
@ -525,25 +555,6 @@ 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"
|
||||
}
|
||||
}
|
||||
~~~
|
||||
|
||||
### 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.
|
||||
|
|
|
|||
Loading…
Reference in a new issue