typo

HowtoIcinga.md

@@ -21,7 +21,7 @@ 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 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.
 
@@ -47,10 +47,10 @@ Plus [d'infos dans la documentation officielle (en anglais)](https://docs.icinga
 
 ## 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
+* *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.
 
@@ -123,9 +123,9 @@ 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
@@ -173,7 +173,7 @@ Ici, MySQL va servir à 2 choses :
 
 *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
@@ -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" {
@@ -549,7 +549,7 @@ Modules avec des fonctions de haute disponibilité :
 * 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