Ajouts sur icinga
This commit is contained in:
parent
9d304c4558
commit
0f378774cd
|
|
@ -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 (aka 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. 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é :
|
||||
|
||||
* 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,15 +19,16 @@ Il existe plusieurs manières de déployer Icinga2 pour surveiller un ensemble d
|
|||
|
||||
|
||||
|
||||
A noter que cette hiérarchie s'applique en premier lieux à des `zones`, les noeuds étant membres d'une seule zone. Habituellement une zone contient un seul noeud et porte le même nom que celui-ci par convention. Mais pour un master ou des satellites, on peut être amené à placer plusieurs noeuds dans une même zone pour les faire travailler ensemble en mode haute disponibilité et répartition de charge. La notion de `zones` est très importante en mode cluster, car c'est elles qui sont directement configués, les machines récupérant la configuration de la `zone` qui leur a été attribuée.
|
||||
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.
|
||||
|
||||
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 SNMP, SSH, NRPE pour exécuter de manière distante un check.
|
||||
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)
|
||||
|
||||
**Attention, cette méthode est dépréciée depuis la sortie de la versions 2.6**
|
||||
**Attention, cette méthode est dépréciée depuis la sortie de la versions 2.6 et devrait être [retiré dans une future version](https://github.com/Icinga/icinga2/issues/4799)**
|
||||
|
||||
Dans ce mode de configuration, les machines locales sont configurées pour se surveiller elles-mêmes et remonter les résultats des checks. La configuration réside sur les machines locales et est synchronisée vers le serveur central.
|
||||
|
||||
|
|
@ -54,7 +55,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" (icinga2-client1, 192.0.2.10) qui va recevoir la configuration du master.
|
||||
|
||||
### Installation du master
|
||||
|
||||
|
|
@ -277,7 +278,7 @@ Pour que la synchronisation se fasse entre le master et le client, on redémarre
|
|||
|
||||
*Note* : Pour controler la syntaxe de la configuration, on peut utiliser la commande `service icinga2 checkconfig` ou `icinga2 daemon --validate`
|
||||
|
||||
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`.
|
||||
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`.
|
||||
|
||||
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 :
|
||||
|
||||
|
|
@ -285,7 +286,7 @@ A noter que cette méthode de configuration est assez fastidieuse étant donné
|
|||
* L'appartenance à des groupes
|
||||
* La présence d'attributs personalisé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 personalisé de `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'addresse et dont l'attribut `vars.os` a pour valeur "linux".
|
||||
|
||||
~~~
|
||||
apply Service "ssh" {
|
||||
|
|
@ -296,6 +297,34 @@ 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 !
|
||||
|
||||
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"
|
||||
}
|
||||
~~~
|
||||
|
||||
|
||||
## Plomberie
|
||||
|
||||
|
|
@ -425,7 +454,7 @@ object Service "swap" {
|
|||
}
|
||||
~~~
|
||||
|
||||
*Cool fact* : on peut donc faire du NRPE par SSH (dans le cas d'une machine en NAT). Exemple :
|
||||
*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" {
|
||||
|
|
@ -446,3 +475,24 @@ apply Service "ssh-nrpe-load" {
|
|||
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).
|
||||
|
||||
~~~
|
||||
# icinga2 pki new-cert --cn icinga2-client2 \
|
||||
--key icinga2-client2.key \
|
||||
--csr icinga2-client2.csr
|
||||
~~~
|
||||
|
||||
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.
|
||||
|
|
|
|||
Loading…
Reference in a new issue