Browse Source

How to icinga2 : typo

master
Ludovic Poujol 3 years ago
parent
commit
d59a7c5805
1 changed files with 23 additions and 23 deletions
  1. +23
    -23
      HowtoIcinga2.md

+ 23
- 23
HowtoIcinga2.md View File

@@ -19,19 +19,19 @@ Il existe plusieurs manières de déployer Icinga2 pour surveiller un ensemble d
* 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.

![Illustration des nom des rôles dans icinga2](howtoicinga2_distributed_roles.png)
![Illustration des noms des rôles dans icinga2](howtoicinga2_distributed_roles.png)

A noter que cette hierarchie 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ées, les machines récupérant la configuration de la `zone` qui leur a été attribuée
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

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'appuier 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 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**

Dans ce mode de configuration, les machines locales sont configurées pour se surveiller elles-même et remonter les résultats des checks. La configuration réside sur les machines locales et est synchronisée vers le serveur central.
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.

L'avantage de cette méthode est que les clients locaux peuvent écrire leurs configurations directement sans à avoir à passer par une gestion centralisée des tests et des configurations.

@@ -47,7 +47,7 @@ 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 une 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 localemement (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.

Cela implique cependant que les machines locales doivent accepter des commandes directement du serveur central.

@@ -77,7 +77,7 @@ Pour finaliser l'installation d'icinga2 en master, il faut se servir de son assi
# icinga2 node wizard
~~~

Après l'exécution de l'assitant, notre master est configuré dans une zone ayant le même nom que lui. On termine par un redémarrage complet du daemon pour activer les changements de la configuration.
Après l'exécution de l'assistant, notre master est configuré dans une zone ayant le même nom que lui. On termine par un redémarrage complet du daemon pour activer les changements de la configuration.

~~~
# service icinga2 restart
@@ -85,7 +85,7 @@ Après l'exécution de l'assitant, notre master est configuré dans une zone aya

### WebUI

Pour fonctionner, la WebUI a besoin d'un serveur web avec PHP et d'un serveur de base de donnée (MySQL ou PostgreSQL). Dans la suite de l'exemple, nous utiliseront [/HowtoApache]() et [/HowtoLAMP/MySQL]().
Pour fonctionner, la WebUI a besoin d'un serveur web avec PHP et d'un serveur de bases de données (MySQL ou PostgreSQL). Dans la suite de l'exemple, nous utiliseront [/HowtoApache]() et [/HowtoLAMP/MySQL]().

Ici, MySQL va servir à 2 choses :

@@ -97,7 +97,7 @@ Ici, MySQL va servir à 2 choses :
# apt install icingaweb2 icinga2-ido-mysql
~~~

*Note* : Le paquetage `icinga2-ido-mysql` fournit un assistant d'installation pour configurer une base de donnée 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ée, 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 :

@@ -128,9 +128,9 @@ L'assistant lance ensuite une série de tests. Il est important de s'assurer que

`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 choisi 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ée 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.
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ée créée précédemment pour `icinga2`. Si vous avez utilisé l'assitant 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 WebUI devrait être en place et vous devriez pouvoir vous connecter au <http://example.org/icingaweb2/>

@@ -203,12 +203,12 @@ Accept config from master? [y/N]: y
Accept commands from master? [y/N]: n
~~~

À noter qu'à l'étape où l'assistant demande le ticket généré sur le master, il faut exécuter la commande suivante sur le master et copier l'output dans l'assistant:
À noter qu'à l'étape où l'assistant demande le ticket généré sur le master, il faut exécuter la commande suivante sur le master et copier l'output dans l'assistant :

~~~
icinga2 pki ticket --cn '<nom du client>'
~~~
Après l'exécution de l'assitant, 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.
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 :

~~~
@@ -224,12 +224,12 @@ 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.
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

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
@@ -275,13 +275,13 @@ Pour que la synchronisation se fasse entre le master et le client, on redémarre

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`.

A noter que cette méthode de configuration est assez fastidieuse étant donné que l'on doit déclarer chaque services pour chaque 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 :
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 :

* Des conventions de nommage des machines (i.e. foo-mail -> correspond à \*-mail -> Application de services propres à un serveur mail (SMTP, IMAP, mailq...))
* 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 au machines dont on connais 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 personalisé de `os` a pour valeur "linux".

~~~
apply Service "ssh" {
@@ -303,13 +303,13 @@ apply Service "ssh" {

### Fichiers de configuration

Les fichiers de configuration se trouvent dans `/etc/icinga2`. Tous les fichiers de configuration utilisent la même syntaxe. Il existe d'ailleurs un plugin vim pour cette dernière:
Les fichiers de configuration se trouvent dans `/etc/icinga2`. Tous les fichiers de configuration utilisent la même syntaxe. Il existe d'ailleurs un plugin vim pour cette dernière :

~~~
# 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 (indépendament de la présence de l'agent icinga2) alors que l'objet `Service` sert à définir un service et il est rataché à une machine. On peut retrouver une description détaillée de tous les objets [ici](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 (indépendament de la présence de l'agent icinga2) alors que l'objet `Service` sert à définir un service et il est 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, l'emplacement 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.

@@ -343,7 +343,7 @@ Les fichiers dans ce dossier sont des plugins qui peuvent être activés avec le
# service icinga2 reload
~~~

Une fois activés, il sont symlinkés dans `/features-enabled`, un peu comme pour Apache.
Une fois activés, ils sont symlinkés dans `/features-enabled`, un peu comme pour Apache.

#### pki/

@@ -393,15 +393,15 @@ object Service "nrpe-swap" {

### Utilisation de SSH

Dans certaines situation, 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.
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ésent sur la machine et exécutable par l'utilisateur utilisé par icinga2
* 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. En suite, 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" {
@@ -421,7 +421,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). Exemple :

~~~
object CheckCommand "nrpe_via_ssh" {


Loading…
Cancel
Save