typo
This commit is contained in:
parent
1d136c531d
commit
c5211c32e8
|
|
@ -19,9 +19,9 @@ 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.
|
||||
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 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`
|
||||
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*
|
||||
|
||||
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.
|
||||
|
||||
|
|
@ -41,18 +41,18 @@ Plus [d'infos dans la documentation officielle (en anglais)](https://docs.icinga
|
|||
|
||||
### Pont d'exécution de commandes (top down command endpoint)
|
||||
|
||||
Avec la méthode du pont d'exécution de commandes, l'ensemble des configurations sont sur le serveur central et y restent. Il n'y a pas de synchronisation de configuration avec les machines locales. Quand le serveur central souhaite effectuer un test sur une machine locale, il la lance directement sur cette dernière au travers de l'agent local icinga2. Le seul pré-requis est que les objets de type `CheckCommand` définissant les commandes à exécuter doivent être présent localement (i.e. là où la commande est exécutée). Le principe est similaire à NRPE.
|
||||
Avec la méthode du pont d'exécution de commandes, l'ensemble des configurations sont sur le serveur central et y restent. Il n'y a pas de synchronisation de configuration avec les machines locales. Quand le serveur central souhaite effectuer un test sur une machine locale, il la lance directement sur cette dernière au travers de l'agent local icinga2. Le seul pré-requis est que les objets de type **CheckCommand** définissant les commandes à exécuter doivent être présent localement (i.e. là où la commande est exécutée). Le principe est similaire à NRPE.
|
||||
|
||||
Plus [d'infos dans la documentation officielle (en anglais)](https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring#distributed-monitoring-top-down-command-endpoint).
|
||||
|
||||
## Installation
|
||||
|
||||
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 :
|
||||
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
|
||||
|
||||
L'installation d'`icinga2` est relativement simple. Cependant, la documentation disponible en ligne conseille d'utiliser les paquetages officiels disponible sur les dépôts proposés par les développeurs.
|
||||
L'installation d'icinga2 est relativement simple. Cependant, la documentation disponible en ligne conseille d'utiliser les paquetages officiels disponible sur les dépôts proposés par les développeurs.
|
||||
|
||||
~~~
|
||||
# wget -O - http://packages.icinga.com/icinga.key | apt-key add -
|
||||
|
|
@ -123,16 +123,16 @@ Tous les fichiers de configuration utilisent la même syntaxe. Il existe d'aille
|
|||
# apt -t jessie-backports install vim-icinga2
|
||||
~~~
|
||||
|
||||
La configuration d'icinga2 se base principalement sur des objets de types différents. Par exemple, l'objet `Host` définit une machine surveillée (indépendament de la présence de l'agent icinga2) alors que l'objet `Service` sert à définir un service rataché à une machine. On peut retrouver une description détaillée de tous les objets [ici (en anglais)](http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/object-types).
|
||||
La configuration d'icinga2 se base principalement sur des objets de types différents. Par exemple, l'objet *Host* définit une machine surveillée (indépendament de la présence de l'agent icinga2) alors que l'objet *Service* sert à définir un service rataché à une machine. On peut retrouver une description détaillée de tous les objets [ici (en anglais)](http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/object-types).
|
||||
|
||||
En général, le nom des fichiers contenant des objets n'est pas réellement important. Dans l'exemple plus haut, on aurait ainsi pu ajouter l'objet `Host` dans le fichier `/etc/icinga2/zones.d/icinga2-client1/foo_bar.conf` au lieu de `/etc/icinga2/zones.d/icinga2-client1/hosts.conf`. C'est cependant un bonne pratique de séparer clairement ses différents objets en fichiers nommés de manière claire.
|
||||
En général, le nom des fichiers contenant des objets n'est pas réellement important. Dans l'exemple plus haut, on aurait ainsi pu ajouter l'objet *Host* dans le fichier `/etc/icinga2/zones.d/icinga2-client1/foo_bar.conf` au lieu de `/etc/icinga2/zones.d/icinga2-client1/hosts.conf`. C'est cependant un bonne pratique de séparer clairement ses différents objets en fichiers nommés de manière claire.
|
||||
|
||||
|
||||
### Instance master
|
||||
|
||||
#### Icinga2
|
||||
|
||||
Pour configurer Icinga2 en master, il faut se servir de son assistant de configuration. Il se chargera de créer une CA pour l'authentification avec les autres instances `icinga2` du cluster et activer l'API. La commande qui suit lance un assistant d'installation. Mis à part la première option où il faut répondre `n`, les autres peuvent être laissées vides pour conserver les valeurs par défaut :
|
||||
Pour configurer Icinga2 en master, il faut se servir de son assistant de configuration. Il se chargera de créer une CA pour l'authentification avec les autres instances `icinga2` du cluster et activer l'API. La commande qui suit lance un assistant d'installation. Mis à part la première option où il faut répondre **n**, les autres peuvent être laissées vides pour conserver les valeurs par défaut :
|
||||
|
||||
~~~
|
||||
# icinga2 node wizard
|
||||
|
|
@ -165,22 +165,22 @@ Pour fonctionner, l'interface web a besoin d'un serveur web avec PHP et d'un ser
|
|||
Ici, MySQL va servir à 2 choses :
|
||||
|
||||
* Sauvegarder les utilisateurs & groupes de l'interface Web
|
||||
* Contenir les informations de configuration d'icinga2, le statut des hôtes et des services... qui sont mis à jour par le module `ido-mysql` d'icinga2
|
||||
* Contenir les informations de configuration d'icinga2, le statut des hôtes et des services... qui sont mis à jour par le module **ido-mysql** d'icinga2
|
||||
|
||||
~~~
|
||||
# apt install icingaweb2 icinga2-ido-mysql
|
||||
~~~
|
||||
|
||||
*Note* : Le paquetage `icinga2-ido-mysql` fournit un assistant d'installation pour configurer une base de données et un utilisateur MySQL automatiquement. Si on le souhaite, il est également possible de le faire manuellement. Il faut alors se charger de créer une base de données, un utilisateur ayant les accès à celle-ci et importer le schéma des tables. Les paramètres sont alors à écrire dans `/etc/icinga2/features-available/ido-mysql.conf` et le schéma des tables à importer est dans `/usr/share/icinga2-ido-mysql/schema/mysql.sql`
|
||||
*Note* : Le paquetage *icinga2-ido-mysql* fournit un assistant d'installation pour configurer une base de données et un utilisateur MySQL automatiquement. Si on le souhaite, il est également possible de le faire manuellement. Il faut alors se charger de créer une base de données, un utilisateur ayant les accès à celle-ci et importer le schéma des tables. Les paramètres sont alors à écrire dans `/etc/icinga2/features-available/ido-mysql.conf` et le schéma des tables à importer est dans `/usr/share/icinga2-ido-mysql/schema/mysql.sql`
|
||||
|
||||
Une fois l'installation terminée, il est nécessaire d'activer le module `ido-mysql` d'icinga2 :
|
||||
Une fois l'installation terminée, il est nécessaire d'activer le module *ido-mysql* d'icinga2 :
|
||||
|
||||
~~~
|
||||
# icinga2 feature enable ido-mysql
|
||||
# service icinga2 restart
|
||||
~~~
|
||||
|
||||
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
|
||||
|
|
@ -196,15 +196,15 @@ Pour continuer l'installation de l'interface wev, il faut aller la page suivante
|
|||
# icingacli setup token create
|
||||
~~~
|
||||
|
||||
La prochaine étape de l'assistant vous demande quelles fonctions activer. Il faut au moins activer `Monitoring` (sinon, l'interface web perd tout son intérêt!).
|
||||
La prochaine étape de l'assistant vous demande quelles fonctions activer. Il faut au moins activer le mondule **Monitoring** (sinon, l'interface web perd tout son intérêt!).
|
||||
|
||||
L'assistant lance ensuite une série de tests. Il est important de s'assurer que tous les tests sont OK. Il est normal que les tests PostgreSQL s'affichent en jaune, car on utilise MySQL.
|
||||
|
||||
`Icingaweb2` offre plusieurs backends d'authentification. Pour une grande organisation, il est préférable d'utiliser le backend LDAP. Mais pour quelques comptes, il est cependant plus simple d'utiliser le backend basé sur une base de données.
|
||||
*Icingaweb2* offre plusieurs backends d'authentification. Pour une grande organisation, il est préférable d'utiliser le backend LDAP. Mais pour quelques comptes, il est cependant plus simple d'utiliser le backend basé sur une base de données.
|
||||
|
||||
Si l'on choisit un backend base de données, il suffit de renter les informations d'authentification que l'on souhaite avoir. La WebUI va ensuite nous informer que la base de données n'existe pas encore et nous demander le mot de passe administrateur pour en créer une pour nous. Encore une fois, il est possible de faire cela directement en ligne de commande avec MySQL.
|
||||
|
||||
Après avoir finalisé les informations pour l'authentification, il vous faudra donner au WebUI l'accès à la base de données créée précédemment pour `icinga2`. Si vous avez utilisé l'assistant de configuration du paquetage `icinga2-ido-mysql`, vous pourrez retrouver directement les informations d'authentification à MySQL utilisé par icinga2 dans `/etc/icinga2/features-available/ido-mysql.conf`.
|
||||
Après avoir finalisé les informations pour l'authentification, il vous faudra donner au WebUI l'accès à la base de données créée précédemment pour *icinga2*. Si vous avez utilisé l'assistant de configuration du paquetage *icinga2-ido-mysql*, vous pourrez retrouver directement les informations d'authentification à MySQL utilisé par icinga2 dans `/etc/icinga2/features-available/ido-mysql.conf`.
|
||||
|
||||
Et voilà! Votre interface web devrait être en place et vous devriez pouvoir vous connecter au <http://example.org/icingaweb2/>
|
||||
|
||||
|
|
@ -213,7 +213,7 @@ Et voilà! Votre interface web devrait être en place et vous devriez pouvoir vo
|
|||
#### 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 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.
|
||||
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.
|
||||
|
||||
|
|
@ -280,8 +280,8 @@ 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 :
|
||||
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 :
|
||||
|
||||
~~~
|
||||
[...]
|
||||
|
|
@ -301,13 +301,13 @@ Et voilà ! En théorie, le master et le client peuvent se parler ! Comme nous n
|
|||
#### 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 :
|
||||
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 :
|
||||
|
||||
~~~
|
||||
# mkdir /etc/icinga2/zones.d/icinga2-client1
|
||||
~~~
|
||||
|
||||
Dans ce dossier, on crée un fichier nommé `hosts.conf` qui va nous servir à définir un nouvel objet de type `Host`. Cet objet va nous permettre par la suite de lier d'autres types d'objets à notre nouveau client :
|
||||
Dans ce dossier, on crée un fichier nommé *hosts.conf* qui va nous servir à définir un nouvel objet de type *Host*. Cet objet va nous permettre par la suite de lier d'autres types d'objets à notre nouveau client :
|
||||
|
||||
~~~
|
||||
object Host "icinga2-client1" {
|
||||
|
|
@ -318,7 +318,7 @@ object Host "icinga2-client1" {
|
|||
}
|
||||
~~~
|
||||
|
||||
On peut maintenant ajouter de nouveaux tests dans `services.conf`, des objets de type `Service` :
|
||||
On peut maintenant ajouter de nouveaux tests dans *services.conf*, des objets de type *Service* :
|
||||
|
||||
~~~
|
||||
object Service "disk" {
|
||||
|
|
@ -336,7 +336,7 @@ object Service "ssh" {
|
|||
}
|
||||
~~~
|
||||
|
||||
Pour que la synchronisation se fasse entre le master et le client, on redémarre `icinga2` sur le master :
|
||||
Pour que la synchronisation se fasse entre le master et le client, on redémarre icinga2 sur le master :
|
||||
|
||||
~~~
|
||||
# service icinga2 reload
|
||||
|
|
@ -346,7 +346,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 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'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 :
|
||||
|
||||
|
|
@ -354,7 +354,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 `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'addresse et dont l'attribut vars.os a pour valeur "linux".
|
||||
|
||||
~~~
|
||||
apply Service "ssh" {
|
||||
|
|
@ -367,7 +367,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/zone.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`
|
||||
|
||||
|
|
@ -396,12 +396,12 @@ 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.
|
||||
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 (bonus) - 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 zone 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" {
|
||||
|
|
@ -414,15 +414,15 @@ object Host "no-icinga2-host" {
|
|||
|
||||
##### 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.
|
||||
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` :
|
||||
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 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.
|
||||
|
||||
~~~
|
||||
object Service "swap" {
|
||||
|
|
@ -445,7 +445,7 @@ Quelques pré-requis avant :
|
|||
* 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
|
||||
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" {
|
||||
|
|
@ -507,7 +507,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 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" {
|
||||
|
|
@ -520,7 +520,7 @@ object User "foo" {
|
|||
|
||||
### 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.
|
||||
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" {
|
||||
|
|
@ -540,16 +540,16 @@ object TimePeriod "HO" {
|
|||
|
||||
### 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.
|
||||
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`
|
||||
* 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.
|
||||
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.
|
||||
|
||||
|
||||
## Plomberie
|
||||
|
|
|
|||
Loading…
Reference in a new issue