relecture part 3
This commit is contained in:
gcolpart
parent
d3dea2b4ce
commit
26257841a9
|
|
@ -95,7 +95,7 @@ La configuration d'Icinga se base sur des objets de types différents : l'objet
|
|||
Le nom des fichiers contenant les objets n'est pas important, mais une bonne pratique est de séparer ses objets dans des fichiers du type `/etc/icinga2/zones.d/<ZONE>/hosts.conf` et `/etc/icinga2/zones.d/<ZONE>/services.conf` (si il n'y a qu'une zone, on peut l'appeler _master_).
|
||||
|
||||
|
||||
### Configuration nœud master
|
||||
## Configuration nœud master
|
||||
|
||||
On utilise l'assistant de configuration : il se chargera d'activer l'API et de créer une autorité de certification pour l'authentification avec les éventuels autres nœuds.
|
||||
|
||||
|
|
@ -119,7 +119,7 @@ Now restart your Icinga 2 daemon to finish the installation!
|
|||
# systemctl restart icinga2
|
||||
~~~
|
||||
|
||||
### Configuration interface web
|
||||
## Configuration interface web
|
||||
|
||||
L'interface web a besoin d'un serveur web avec PHP : nous utilisons [Apache](HowtoApache) ; d'un accès à l'API Icinga et du module IDO qui va stocker les informations dans une base de données : nous utilisons [MySQL](HowtoMySQL).
|
||||
|
||||
|
|
@ -164,34 +164,14 @@ L'assistant va ensuite avoir besoin des paramètres d'accès à la base de donn
|
|||
L'interface web est désormais accessible via <http://monitoring.example.org/icingaweb2/>
|
||||
|
||||
|
||||
### Configuration client
|
||||
## Configuration client
|
||||
|
||||
Pour surveiller un équipement, il faut installer icinga2 (nœud client) ou s'appuyer sur d'autres protocoles (NRPE, SSH, SNMP).
|
||||
Pour surveiller un équipement, il faut installer Icinga (nœud client) ou s'appuyer sur d'autres protocoles (NRPE, SSH, SNMP).
|
||||
|
||||
#### mode top down command endpoint (exécution de commande)
|
||||
### Surveiller un équipement avec Icinga (nœud client)
|
||||
|
||||
<https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring#distributed-monitoring-top-down-command-endpoint>
|
||||
|
||||
C'est la méthode la plus simple, similaire à NRPE : le nœud master souhaitant effectuer un check, il lance une commande au travers de l'agent local icinga2 installé. 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).
|
||||
|
||||
#### mode bottom up config sync
|
||||
|
||||
<https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring#distributed-monitoring-bottom-up>
|
||||
|
||||
_Attention, cette méthode est dépréciée depuis la sortie de la versions 2.6 et devrait être [retirée dans une future version](https://github.com/Icinga/icinga2/issues/4799)_
|
||||
|
||||
Avec cette méthode, les équipements sont configurés pour se surveiller eux-mêmes et remonter les résultats des checks. La configuration réside sur les machines locales et est synchronisée vers le nœud master.
|
||||
|
||||
#### mode top down config sync
|
||||
|
||||
<https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring#distributed-monitoring-top-down-config-sync>
|
||||
|
||||
Le principe est semblable à la méthode précédente, la différence est que la configuration des machines locales est faite sur le serveur central. Lorsque l'on redémarre le daemon, le serveur central s'assure que les machines locales ont la bonne configuration. Plutôt d'aller « du bas vers le haut » on va donc « du haut vers le bas ». Cette méthode permet de centraliser l'ensemble de notre configuration.
|
||||
|
||||
#### Configuration de base
|
||||
|
||||
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 rattacher au master du cluster (TODO: on est dans quel mode ??)
|
||||
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.
|
||||
Quand on installe Icinga sur un équipement, le daemon est lancé et se met à surveiller l'hôte local.
|
||||
On va configurer de manière minimale pour juste le rattacher au nœud master et c'est le master qui va décider comment utiliser la machine.
|
||||
|
||||
On utilise l'assistant de configuration (_note_: les autres commandes `icinga2 node <paramètre>` sont dépréciées) :
|
||||
|
||||
|
|
@ -249,8 +229,7 @@ Accept commands from master? [y/N]: y
|
|||
# icinga2 pki ticket --cn '<nom du client>'
|
||||
~~~
|
||||
|
||||
Après l'exécution de l'assistant, l'instance Icinga est réglée comme appartenant à sa propre *zone*. 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 Icinga est réglée comme appartenant à sa propre *zone*. 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 :
|
||||
|
||||
~~~
|
||||
[...]
|
||||
|
|
@ -265,7 +244,32 @@ 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 ! On peut maintenant configurer les checks via le master.
|
||||
|
||||
> *Note* : ous n'avons pas encore configuré de test sur le client, il est normal qu'il n'apparaisse pas sur l'interface web.
|
||||
|
||||
|
||||
#### mode top down command endpoint (exécution de commande)
|
||||
|
||||
<https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring#distributed-monitoring-top-down-command-endpoint>
|
||||
|
||||
C'est la méthode la plus simple, similaire à NRPE : le nœud master souhaitant effectuer un check, il lance une commande au travers de l'agent local icinga2 installé. 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).
|
||||
|
||||
#### mode bottom up config sync (checks envoyés vers le master)
|
||||
|
||||
<https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring#distributed-monitoring-bottom-up>
|
||||
|
||||
_Attention, cette méthode est dépréciée depuis la sortie de la versions 2.6 et devrait être [retirée dans une future version](https://github.com/Icinga/icinga2/issues/4799)_
|
||||
|
||||
Avec cette méthode, les équipements sont configurés pour se surveiller eux-mêmes et remonter les résultats des checks. La configuration réside sur les machines locales et est synchronisée vers le nœud master.
|
||||
|
||||
#### mode top down config sync (checks envoyés vers le master)
|
||||
|
||||
<https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring#distributed-monitoring-top-down-config-sync>
|
||||
|
||||
Le principe est semblable à la méthode précédente, la différence est que la configuration des machines locales est faite sur le serveur central. Lorsque l'on redémarre le daemon, le serveur central s'assure que les machines locales ont la bonne configuration. Plutôt d'aller « du bas vers le haut » on va donc « du haut vers le bas ». Cette méthode permet de centraliser l'ensemble de notre configuration.
|
||||
|
||||
|
||||
|
||||
#### Cas A - Client avec configuration centrale sur le master
|
||||
|
||||
|
|
@ -366,7 +370,7 @@ object Service "ssh" {
|
|||
La définition de l'hôte et des services est quasi identique au 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 - Monitoring d'une machine distante sans Icinga
|
||||
### Surveiller un équipement sans Icinga (NRPE, SSH etc.)
|
||||
|
||||
Comme annoncé plus haut, il est aussi possible de surveiller une machine qui n'aurait pas Icinga par d'autres moyens comme NRPE ou SSH. La commande de l'exécution des checks devra alors être prise en charge par un nœud du cluster Icinga. Idéalement, 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.
|
||||
|
||||
|
|
@ -379,7 +383,7 @@ object Host "no-icinga2-host" {
|
|||
}
|
||||
~~~
|
||||
|
||||
##### Utilisation de NRPE
|
||||
#### Utilisation de NRPE
|
||||
|
||||
Lors d'une migration de *Nagios* vers *Icinga*, il peut être intéréssant de supporter tout les checks fait par NRPE pour fluidifier la transition vers la nouvelle plateforme.
|
||||
|
||||
|
|
@ -409,7 +413,7 @@ object Service "swap" {
|
|||
}
|
||||
~~~
|
||||
|
||||
##### Utilisation de SSH
|
||||
#### Utilisation de SSH
|
||||
|
||||
Dans certaines situations, l'utilisation de NRPE ou Icinga n'est pas possible (restrictions firewall, NAT...). Dans ces cas là, on peut aussi exécuter des commandes via une connexion SSH.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue