relecture part 1
This commit is contained in:
gcolpart
parent
517f0eb209
commit
d8d0361544
231
HowtoIcinga.md
231
HowtoIcinga.md
|
|
@ -5,62 +5,22 @@ title: Howto Icinga
|
|||
|
||||
* Documentation : <https://docs.icinga.com/>
|
||||
|
||||
[Icinga](https://www.icinga.com/) est un logiciel de monitoring réseau qui vise à surveiller des services en place sur des serveurs.
|
||||
[Icinga](https://www.icinga.com/) est un logiciel libre de surveillance système et réseau d'équipements. Au départ (en 2009), c'est un fork de [Nagios](https://www.nagios.com/) avec pour objectifs davantage d'évolutivité et une interface web plus moderne. La version 1 d'Icinga a une configuration compatible avec Nagios, ce qui n'est pas le cas de la version 2 qui a été complètement ré-écrite.
|
||||
|
||||
Icinga est un fork bien établi de Nagios. Dans cette documentation, nous allons couvrir Icinga2. Contrairement à Icinga, qui reprenait une partie du code de Nagios et qui avait un système de configuration compatible, Icinga2 a été complètement réécrit et n'est pas compatible avec Nagios/Icinga.
|
||||
Après avoir utilisé Nagios pendant plus de 10 ans, nous utilisons désormais Icinga.
|
||||
|
||||
## Structure de l'infrastructure de monitoring
|
||||
|
||||
Il existe plusieurs manières de déployer Icinga2 pour surveiller un ensemble de machines. Il peut fonctionner de manière centralisée ou distribuée. Icinga est assez flexible et permet de contruire des architectures en fonction des besoins. Pour mieux s'y retrouver, on peut catégoriser les instances 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
|
||||
* Noeud client : Il est en bas de la hierarchie, connecté a un satellite ou un master. Il agit comme un agent
|
||||
|
||||
|
||||
|
||||
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**
|
||||
|
||||
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.
|
||||
|
||||
### Configuration locale (bottom up config sync)
|
||||
|
||||
**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)**
|
||||
|
||||
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. Plus [d'infos dans la documentation officielle (en anglais)](https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring#distributed-monitoring-bottom-up).
|
||||
|
||||
### Configuration centrale (top down config sync)
|
||||
|
||||
Le principe de la configuration en cluster est semblable à celui de la configuration locale. La seule 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 est idéale si l'on souhaite centraliser l'ensemble de notre configuration.
|
||||
|
||||
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-config-sync).
|
||||
|
||||
### 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.
|
||||
|
||||
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).
|
||||
_Cette documentation concerne Icinga version 2._
|
||||
|
||||
## Installation
|
||||
|
||||
Dans la suite, on va détailler l'installation puis la configuration de plusieurs machines. Dans notre exemple on a quatre machines :
|
||||
|
||||
* *icinga2-master* (192.0.2.1) - Master de notre cluster. Il hébergera aussi l'interface web
|
||||
* *icinga2-client1* (192.0.2.10) - Client qui va recevoir la configuration du master
|
||||
* *icinga2-client2* (192.0.2.20) - Client qui va servir de pont d'éxécution de commandes
|
||||
* *no-icinga2-host* (192.0.2.30) - Machine surveillée sans instance icinga2 locale
|
||||
|
||||
L'installation d'icinga2 est relativement simple. C'est le même paquetage à utiliser quelque soit la fonction de la machine dans le cluster.
|
||||
|
||||
Autre détail, la documentation disponible en ligne conseille d'utiliser les paquetages officiels disponible sur les dépôts proposés par les développeurs. En effet la version présente dans les dépôts de débian est assez ancienne et ne couvre pas toutes les fonctionalité mentionées ici. (Une autre solution est d'utiliser la version présente dans les backports de jessie, mais tout les paquets relatifs à l'interface web y sont absent).
|
||||
Nous utilisons les paquets d'icinga.com car l'interface web n'est pas présente dans les paquets officiels Debian 8.
|
||||
|
||||
~~~
|
||||
# wget -O - http://packages.icinga.com/icinga.key | apt-key add -
|
||||
# echo 'deb http://packages.icinga.com/debian icinga-jessie main' >/etc/apt/sources.list.d/icinga.list
|
||||
# wget -O - http://packages.icinga.com/icinga.key | apt-key add -
|
||||
~~~
|
||||
|
||||
~~~
|
||||
# apt install icinga2
|
||||
|
||||
# icinga2 --version
|
||||
|
|
@ -95,48 +55,52 @@ Build information:
|
|||
Build host: smithers
|
||||
~~~
|
||||
|
||||
## Configuration
|
||||
## Architecture
|
||||
|
||||
La configuration d'icinga2 réside essentiellement dans `/etc/icinga2`
|
||||
Icinga peut avoir différents rôles :
|
||||
|
||||
* nœud **master** : serveur central
|
||||
* nœud **satellite** : pour le mode cluster, serveur rattaché au nœud master pour de la haute disponibilité
|
||||
* nœud **client** : serveur chargé de lancer des commandes locales (semblable à un serveur *nrpe*)
|
||||
|
||||
On peut également découper la configuration Icinga en différentes zones où seront regroupées des nœuds master et satellite. Cette notion de zone permet d'avoir des nœuds distants, par exemple répartis dans plusieurs pays. (TODO: est-ce qu'une zone est super-master avec un noeud master qui contient toute la conf ??). Si l'on utilise un nœud client, il aura généralement sa propre zone.
|
||||
|
||||
TODO : comprendre si le schéma a bien un intérêt... (il parle de satellite alors que facultatif ? et ne parle pas de zones ?)
|
||||
|
||||
|
||||
|
||||
## Configuration
|
||||
|
||||
~~~
|
||||
/etc/icinga2
|
||||
├── conf.d
|
||||
│ └── *.conf
|
||||
│ └── *.conf
|
||||
├── constants.conf
|
||||
├── features-available
|
||||
│ └── *.conf
|
||||
│ └── *.conf
|
||||
├── features-enabled
|
||||
│ └── *.conf
|
||||
│ └── *.conf
|
||||
├── icinga2.conf
|
||||
├── init.conf
|
||||
├── pki
|
||||
├── repository.d
|
||||
│ └── README
|
||||
│ └── README
|
||||
├── scripts
|
||||
│ ├── mail-host-notification.sh
|
||||
│ └── mail-service-notification.sh
|
||||
│ ├── mail-host-notification.sh
|
||||
│ └── mail-service-notification.sh
|
||||
├── zones.conf
|
||||
└── zones.d
|
||||
└── README
|
||||
~~~
|
||||
|
||||
Tous les fichiers de configuration utilisent la même syntaxe. Il existe d'ailleurs un plugin vim pour cette dernière :
|
||||
La configuration d'Icinga se base sur des objets de types différents : l'objet **Host** définit une machine surveillée alors que l'objet **Service** définit un service rattaché à une machine. Voir [description détaillée de tous les objets](http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/object-types).
|
||||
|
||||
~~~
|
||||
# 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).
|
||||
|
||||
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.
|
||||
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_).
|
||||
|
||||
|
||||
### Instance master
|
||||
### Configuration nœud 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 :
|
||||
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.
|
||||
|
||||
~~~
|
||||
# icinga2 node wizard
|
||||
|
|
@ -150,38 +114,34 @@ Please specify the common name (CN) [icinga2-master]:
|
|||
Checking for existing certificates for common name 'icinga2-master'...
|
||||
Certificates not yet generated. Running 'api setup' now.
|
||||
information/cli: Generating new CA.
|
||||
......
|
||||
[...]
|
||||
Done.
|
||||
|
||||
Now restart your Icinga 2 daemon to finish the installation!
|
||||
|
||||
# systemctl restart icinga2
|
||||
~~~
|
||||
|
||||
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.
|
||||
### Configuration interface web
|
||||
|
||||
~~~
|
||||
# service icinga2 restart
|
||||
~~~
|
||||
L'interface web a besoin d'un serveur web avec PHP et d'une base de données : nous utilisons [Apache](HowtoApache) et [MySQL](HowtoMySQL).
|
||||
|
||||
#### Interface web
|
||||
La base de données sert à :
|
||||
|
||||
Pour fonctionner, l'interface web 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 :
|
||||
|
||||
* 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
|
||||
* sauvegarder les utilisateurs et groupes de l'interface web
|
||||
* stocker les informations de configuration, le status des hôtes et services (mis à jour grâce au module _ido-mysql_)
|
||||
|
||||
~~~
|
||||
# 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 le faire manuellement, les paramètres sont stockés dans le fichier `/etc/icinga2/features-available/ido-mysql.conf` et le schéma des tables 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 :
|
||||
|
||||
~~~
|
||||
# icinga2 feature enable ido-mysql
|
||||
# service icinga2 restart
|
||||
# systemctl restart icinga2
|
||||
~~~
|
||||
|
||||
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**.
|
||||
|
|
@ -192,39 +152,56 @@ Il est possible de lancer des commandes (planifier un check, downtimer une machi
|
|||
# service icinga2 restart
|
||||
~~~
|
||||
|
||||
*Note* : Il est aussi possible de contrôler icinga2 directement via son API. Cela est pratique notament dans le cas où l'interface web n'est pas sur la même machine. Il faut à ce moment là créer un utilisateur API avec un couple login/pass et les renseigner dans la configuration de l'interface web.
|
||||
> *Note* : Il est aussi possible de contrôler icinga2 directement via son API. Cela est pratique notament dans le cas où l'interface web n'est pas sur la même machine. Il faut à ce moment là créer un utilisateur API avec un couple login/pass et les renseigner dans la configuration de l'interface web.
|
||||
|
||||
Pour continuer l'installation de l'interface wev, il faut aller la page suivante <http://example.org/icingaweb2/setup>. L'installeur va nous demander un token. On peut créer ce token avec la commande suivante :
|
||||
|
||||
~~~
|
||||
# icingacli setup token create
|
||||
Pour continuer l'installation de l'interface web, il faut aller sur <http://monitoring.example.com/icingaweb2/setup> : un tocken sera demandé qui peut être créé avec la commande `icingacli setup token create`.
|
||||
~~~
|
||||
|
||||
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!).
|
||||
La prochaine étape de l'assistant demande quelles fonctions activer : il faut au moins activer le module **Monitoring** sinon l'interface web perd = 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.
|
||||
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.
|
||||
Pour l'authentification, on peut utiliser un backend LDAP ou la base de données locale.
|
||||
|
||||
TODO : à comprendre...
|
||||
|
||||
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`.
|
||||
|
||||
Et voilà! Votre interface web devrait être en place et vous devriez pouvoir vous connecter au <http://example.org/icingaweb2/>
|
||||
L'interface web est désormais accessible via <http://monitoring.example.org/icingaweb2/>
|
||||
|
||||
### Configuration d'un client
|
||||
|
||||
### Configuration client
|
||||
|
||||
Pour surveiller un équipement, il faut installer icinga2 (nœud client) ou s'appuyer sur d'autres protocoles (NRPE, SSH, SNMP).
|
||||
|
||||
#### 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
|
||||
|
||||
<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 ratacher au master du cluster.
|
||||
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.
|
||||
|
||||
**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.
|
||||
|
||||
Malgré les apparences, les commandes `icinga2 node update-config` ou encore `icinga2 node add` s'appliquent à une configuration de type locale. De plus, ces commandes sont dépréciées.
|
||||
|
||||
|
||||
On lance l'assistant de configuration :
|
||||
On utilise l'assistant de configuration (_note_: les autres commandes `icinga2 node <paramètre>` sont dépréciées) :
|
||||
|
||||
~~~
|
||||
# icinga2 node wizard
|
||||
|
|
@ -272,19 +249,15 @@ Accept config from master? [y/N]: y
|
|||
Accept commands from master? [y/N]: y
|
||||
~~~
|
||||
|
||||
*Note* : Pour contrôler l'empreinte du certificat de la machine à laquelle on se connecte, on peut utiliser la commande suivante sur celle-ci :
|
||||
|
||||
~~~
|
||||
openssl x509 -noout -in /etc/icinga2/pki/icinga2-master.crt -fingerprint -sha1
|
||||
~~~
|
||||
> *Note* : Pour contrôler l'empreinte du certificat de la machine à laquelle on se connecte, on peut utiliser la commande `openssl x509 -noout -in /etc/icinga2/pki/icinga2-master.crt -fingerprint -sha1`
|
||||
|
||||
À 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>'
|
||||
# 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.
|
||||
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 :
|
||||
|
||||
~~~
|
||||
|
|
@ -304,7 +277,7 @@ 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
|
||||
|
||||
Dans ce premier cas, les fichiers de configuration sont présent et modifiés sur le master, qui les synchronise sur le(s) client(s).
|
||||
Dans ce premier cas, les fichiers de configuration sont présents et 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 :
|
||||
|
||||
~~~
|
||||
|
|
@ -340,15 +313,13 @@ 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 Icinga sur le master :
|
||||
|
||||
~~~
|
||||
# service icinga2 reload
|
||||
# systemcrl reload icinga2
|
||||
~~~
|
||||
|
||||
*Note* : Si, pour une raison ou une autre, la configuration venait à être invalide lors du reload, celui-ci va être avorté. Mais icinga2 va continuer de fonctionner avec l'ancienne configuration valide chargée avant. En effet, il contrôle la configuration avant de demander au daemon de s'arréter.
|
||||
|
||||
*Note* : Pour controler la syntaxe de la configuration, on peut utiliser la commande `service icinga2 checkconfig` ou `icinga2 daemon --validate`
|
||||
> *Note* : Si, pour une raison ou une autre, la configuration venait à être invalide lors du reload, celui-ci va être avorté. Mais Icinga va continuer de fonctionner avec l'ancienne configuration valide chargée avant. En effet, il contrôle la configuration avant de demander au daemon de s'arréter. Pour controler la syntaxe de la configuration, on peut d'ailleurs utiliser la commande `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*.
|
||||
|
||||
|
|
@ -371,9 +342,9 @@ apply Service "ssh" {
|
|||
|
||||
#### Cas B - Configuration en pont d'éxécution de commandes
|
||||
|
||||
Dans ce cas, toute la configuration va rester sur la machine *icinga2-master*. (et donc dans le dossier `/etc/icinga2/zone.d/icinga2-master/`). C'est le master qui va planifier l'exécution des checks.
|
||||
Dans ce cas, toute la configuration va rester sur lae nœud master (et donc dans le dossier `/etc/icinga2/zone.d/master/`). C'est le master qui va planifier l'exécution des checks.
|
||||
|
||||
Ainsi, on peut définir dans un fichier `icinga2-client2.conf`
|
||||
Ainsi, on peut définir dans un fichier `icinga2-client2.conf` :
|
||||
|
||||
~~~
|
||||
object Host "icinga2-client2" {
|
||||
|
|
@ -400,12 +371,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 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 icinga2
|
||||
#### Cas C - Monitoring d'une machine distante sans Icinga
|
||||
|
||||
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 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.
|
||||
|
||||
~~~
|
||||
object Host "no-icinga2-host" {
|
||||
|
|
@ -418,7 +389,7 @@ 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 *Icinga*, 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** :
|
||||
|
||||
|
|
@ -448,7 +419,7 @@ object Service "swap" {
|
|||
|
||||
##### Utilisation de 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.
|
||||
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.
|
||||
|
||||
Quelques pré-requis avant :
|
||||
|
||||
|
|
@ -476,7 +447,7 @@ object Service "swap" {
|
|||
}
|
||||
~~~
|
||||
|
||||
*Cool fact* : on peut même faire du NRPE par SSH (dans le cas d'une machine en NAT ou avec un firewall assez restrictif). Exemple :
|
||||
> *Cool fact* : on peut même 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" {
|
||||
|
|
@ -498,7 +469,8 @@ apply Service "ssh-nrpe-load" {
|
|||
}
|
||||
~~~
|
||||
|
||||
## Plus loin dans la configuration
|
||||
|
||||
## Configuration avancée
|
||||
|
||||
### Zone globale
|
||||
|
||||
|
|
@ -584,8 +556,7 @@ apply Service "cluster-health" {
|
|||
|
||||
### 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.
|
||||
les modules d'Icinga sont capable de gérer la répartition entre chaque membres actifs d'une même zone.
|
||||
Dans certaines situations, on va vouloir mettre plusieurs instances Icinga 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 capables de gérer la répartition entre chaque membres actifs d'une même zone.
|
||||
|
||||
Modules avec des fonctions de haute disponibilité :
|
||||
|
||||
|
|
@ -617,3 +588,17 @@ En suite, depuis le master, on génère le certificat avec la CSR.
|
|||
~~~
|
||||
|
||||
Il ne reste plus qu'a rappatrier les fichiers `/etc/icinga2/pki/icinga2-client2.*` sur la machine désignée.
|
||||
|
||||
## FAQ
|
||||
|
||||
### Que veut-dire « Icinga » ?
|
||||
|
||||
C'est un mot zulu signifiant « il recherche » ou « il examine ».
|
||||
|
||||
### plugin Vim pour la syntaxe de la configuration d'Icinga
|
||||
|
||||
Tous les fichiers de configuration utilisent la même syntaxe. Il existe un plugin vim pour cette dernière :
|
||||
|
||||
~~~
|
||||
# apt -t jessie-backports install vim-icinga2
|
||||
~~~
|
||||
|
|
|
|||
Loading…
Reference in a new issue