MàJ HowtoIcinga2
This commit is contained in:
parent
bcfe1a5fe3
commit
c2d922fd7a
147
HowtoIcinga2.md
147
HowtoIcinga2.md
|
|
@ -1,4 +1,4 @@
|
|||
**Cette page a été importée automatiquement de notre ancien wiki mais n'a pas encore été révisée.**
|
||||
**Cette page a été importée automatiquement de notre ancien wiki. Elle est en cours de révision**
|
||||
|
||||
## Introduction
|
||||
|
||||
|
|
@ -6,17 +6,17 @@ Icinga2 est un logiciel de monitoring réseau qui vise à surveiller des service
|
|||
|
||||
Icinga2 se veut un remplacement pour Icinga, un fork bien établit de Nagios. 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.
|
||||
|
||||
## Structure
|
||||
## Structure de l'infrastructure de monitoring
|
||||
|
||||
Il existe plusieurs manières de déployer Icinga2 pour surveiller un ensemble de machines. Icinga est assez flexible et permet de contruire des architectures distribuées ou centralisées en fonction des besoins. Pour mieux s'y retrouver, on peut donner des noms au noeuds en fonction de leur fonction :
|
||||
Il existe plusieurs manières de déployer Icinga2 pour surveiller un ensemble de machines. Icinga est assez flexible et permet de contruire des architectures distribuées ou centralisées en fonction des besoins. Pour mieux s'y retrouver, on peut donner des noms au noeuds en fonction de leur fonction :
|
||||
|
||||
* 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. Il sert à
|
||||
* 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.
|
||||
|
||||
|
||||
|
||||
A noter que cette hierarchie s'applique en premier lieux a des zones, les noeuds étant des éléments d'une zone. Habituellement une zone contient un seul noeud et porte le même nom que celui-ci. 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.
|
||||
A noter que cette hierarchie s'applique en premier lieux à des zones, les noeuds étant membre d'une 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.
|
||||
|
||||
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.
|
||||
|
||||
|
|
@ -26,11 +26,11 @@ A noter qu'il est aussi possible de surveiller des services sans la présence de
|
|||
|
||||
**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 envoyer au serveur central les résultats ponctuellement. La configuration réside sur les machines locales et est synchronisée avec le serveur central.
|
||||
Dans ce mode de configuration, les machines locales sont configurées pour se surveiller elles-même et envoyer au serveur central les résultats. 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.
|
||||
|
||||
Plus [d'infos ici](https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring#distributed-monitoring-bottom-up).
|
||||
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)
|
||||
|
||||
|
|
@ -38,22 +38,26 @@ Le principe de la configuration en cluster est semblable à celui de la configur
|
|||
|
||||
Cette méthode est idéale si l'on souhaite centraliser l'ensemble de notre configuration.
|
||||
|
||||
Plus [d'infos ici](https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring#distributed-monitoring-top-down-config-sync).
|
||||
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 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 (là où la commande est exécutée).
|
||||
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 (là où la commande est exécutée). Cela fonctionne sur le même principe que NRPE.
|
||||
|
||||
Cela implique cependant que les machines locales doivent accepter des commandes directement du serveur central
|
||||
|
||||
Plus [d'infos ici](https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring#distributed-monitoring-top-down-command-endpoint).
|
||||
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 du master
|
||||
## Installation
|
||||
|
||||
### Icinga2
|
||||
Dans la suite, on va détailler une installation classique avec un cluster en configuration centrale (top down configuration). 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 un "client" (icinga2-client1) qui va recevoir la configuration du master.
|
||||
|
||||
L'installation du core d'`icinga2` sur le master 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.
|
||||
### Installation du master
|
||||
|
||||
#### Icinga2
|
||||
|
||||
L'installation d'`icinga2` sur le master 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 -
|
||||
|
|
@ -68,7 +72,7 @@ Pour finaliser l'installation d'icinga2 en master, il faut se servir de son assi
|
|||
# icinga2 node wizard
|
||||
~~~
|
||||
|
||||
On termine par un redémarrage complet du daemon pour activer les changements de la configuration
|
||||
On termine par un redémarrage complet du daemon pour activer les changements de la configuration.
|
||||
|
||||
~~~
|
||||
# service icinga2 restart
|
||||
|
|
@ -81,14 +85,14 @@ Pour fonctionner, la WebUI a besoin d'un serveur web avec PHP et d'un serveur de
|
|||
Ici, MySQL va servir à 2 choses :
|
||||
|
||||
* Sauvegarder les utilisateurs & groupes de l'interface Web
|
||||
* Contenir les informations de configuration d'icinga2, au status 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 status des hôtes et des services... qui sont mis à jour par le module `ido-mysql` d'icinga2
|
||||
|
||||
~~~
|
||||
# apt update
|
||||
# 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. Les paramètres sont alors à écrire dans `/etc/icinga2/features-available/ido-mysql.conf`
|
||||
*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. 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 :
|
||||
|
||||
|
|
@ -111,7 +115,7 @@ Pour continuer l'installation du WebUI, on visite le <http://example.org/icingaw
|
|||
# icingacli setup token create
|
||||
~~~
|
||||
|
||||
La prochaine étape de l'assistant vous demande quelles fonctions activer. Il est recommandé de choisir `Doc` et `Monitoring`.
|
||||
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!).
|
||||
|
||||
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.
|
||||
|
||||
|
|
@ -119,7 +123,7 @@ L'assistant lance ensuite une série de tests. Il est important de s'assurer que
|
|||
|
||||
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 root 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é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`.
|
||||
|
||||
Et voilà! Votre WebUI devrait être en place et vous devriez pouvoir vous connecter au <http://example.org/icingaweb2/>
|
||||
|
||||
|
|
@ -131,7 +135,7 @@ Par défaut, quand on installe icinga2 sur une machine, le daemon est lancé et
|
|||
|
||||
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 aussi dépréciées.
|
||||
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 commence donc par installer `icinga2` :
|
||||
|
||||
|
|
@ -158,15 +162,15 @@ Please specify the master endpoint(s) this node should connect to:
|
|||
Master Common Name (CN from your master setup): icinga2-master
|
||||
Do you want to establish a connection to the master from this node? [Y/n]: y
|
||||
Please fill out the master connection information:
|
||||
Master endpoint host (Your master's IP address or FQDN): 192.168.4.229
|
||||
Master endpoint host (Your master's IP address or FQDN): 192.0.2.1
|
||||
Master endpoint port [5665]:
|
||||
Add more master endpoints? [y/N]: n
|
||||
Please specify the master connection for CSR auto-signing (defaults to master endpoint host):
|
||||
Host [192.168.4.229]:
|
||||
Host [192.0.2.1]:
|
||||
Port [5665]:
|
||||
information/base: Writing private key to '/etc/icinga2/pki/icinga2-client1.key'.
|
||||
information/base: Writing X509 certificate to '/etc/icinga2/pki/icinga2-client1.crt'.
|
||||
information/cli: Fetching public certificate from master (192.168.4.229, 5665):
|
||||
information/cli: Fetching public certificate from master (192.0.2.1, 5665):
|
||||
|
||||
Certificate information:
|
||||
|
||||
|
|
@ -174,14 +178,14 @@ Certificate information:
|
|||
Issuer: CN = Icinga CA
|
||||
Valid From: Aug 15 21:03:54 2016 GMT
|
||||
Valid Until: Aug 12 21:03:54 2031 GMT
|
||||
Fingerprint: D6 6F 56 55 3B 73 16 45 D5 08 F6 FB CE A6 2A 14 F5 24 05 11
|
||||
Fingerprint: 13 37 FF 42 00 A6 D6 DE DB EE F6 73 16 45 2A 14 F5 24 05 11
|
||||
|
||||
Is this information correct? [y/N]: y
|
||||
information/cli: Received trusted master certificate.
|
||||
|
||||
Please specify the request ticket generated on your Icinga 2 master.
|
||||
(Hint: # icinga2 pki ticket --cn 'icinga2-sclient1'): 4891c5c4c132908f2794d0ed347c9fbf204491aa
|
||||
information/cli: Requesting certificate with ticket '4891c5c4c132908f2794d0ed347c9fbf204491aa'.
|
||||
(Hint: # icinga2 pki ticket --cn 'icinga2-sclient1'): ed347c9f5c4c1a08f811bf2032944d01c48979a
|
||||
information/cli: Requesting certificate with ticket 'ed347c9f5c4c1a08f811bf2032944d01c48979a'.
|
||||
|
||||
information/cli: Writing signed certificate to file '/etc/icinga2/pki/icinga2-client1.crt'.
|
||||
information/cli: Writing CA certificate to file '/etc/icinga2/pki/ca.crt'.
|
||||
|
|
@ -217,7 +221,7 @@ Et voilà! En théorie, le master et le client peuvent se parler! Comme nous n'a
|
|||
|
||||
### 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 client.
|
||||
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 du nom du client que l'on souhaite configurer:
|
||||
|
||||
|
|
@ -262,6 +266,24 @@ 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 :
|
||||
|
||||
* Des conventions de nommage des machines
|
||||
* 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 au 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 l'os a pour valeur "linux".
|
||||
|
||||
~~~
|
||||
apply Service "ssh" {
|
||||
import "generic-service"
|
||||
|
||||
check_command = "ssh"
|
||||
assign where host.address && host.vars.os == "Linux"
|
||||
}
|
||||
~~~
|
||||
|
||||
|
||||
## Plomberie
|
||||
|
||||
### Dossiers par défaut d'icinga2
|
||||
|
|
@ -314,21 +336,26 @@ Les fichiers dans ce dossier sont des plugins qui peuvent être activés avec le
|
|||
|
||||
Une fois activés, il sont symlinkés dans `/features-enabled`, un peu comme pour Apache.
|
||||
|
||||
#### pki
|
||||
#### pki/
|
||||
|
||||
Ce dossier regroupe les fichiers du Public Key Infrastructure (PKI), qui servent de base d'authentification entre les clients et le master. Dans le cas du master, certains fichiers sont des duplicatas de fichiers dans `/var/lib/icinga2/ca/`.
|
||||
Ce dossier regroupe les fichiers du Public Key Infrastructure (PKI), qui servent de base d'authentification entre les clients et le master.
|
||||
Dans le cas du master, la clé privée de la CA se trouve dans `/var/lib/icinga2/ca/`
|
||||
|
||||
#### scripts
|
||||
#### scripts/
|
||||
|
||||
Ce dossier regroupe les différents scripts qui sont lancés lors d'un événement. Par exemple, c'est ici que l'on ajouterais de nouveaux scripts à être lancé pour des objets de type `EventCommand`.
|
||||
Ce dossier regroupe les différents scripts qui sont lancés lors d'événements. Par exemple, c'est ici que l'on ajouterais de nouveaux scripts à être lancé pour des objets de type `EventCommand`.
|
||||
|
||||
#### conf.d
|
||||
#### conf.d/
|
||||
|
||||
Ce dossier regroupe les configurations de services sur le master et les configuration plus globales, comme les définitions de users et de groupes, ou encore les différents modes de surveillance (24h/7, 8 à 17h, etc.).
|
||||
Ce dossier regroupe les configurations de services sur le master et les configuration plus globales, comme les définitions de users et de groupes, ou encore les différents modes de surveillance (24h/7, 8h à 17h, etc.).
|
||||
|
||||
#### repository.d et zones.d
|
||||
#### repository.d/
|
||||
|
||||
`repository.d` regroupe les configurations des clients lors d'une synchronisation de type locale. À l'inverse, pour une configuration de type cluster, les fichiers se retrouveraient plutôt dans le dossier `zones.d`.
|
||||
`repository.d` regroupe les configurations des clients lors d'une synchronisation de type locale.
|
||||
|
||||
#### zones.d/
|
||||
|
||||
Dans une configuration en mode cluster, ce dossier héberge sur le master la totalitée des configurations déployées dans des sous dossier. Chaque sous dossier contenant la configuration de la zonne ayant le même nom.
|
||||
|
||||
### Utilisation de NRPE
|
||||
|
||||
|
|
@ -352,3 +379,55 @@ object Service "nrpe-swap" {
|
|||
vars.nrpe_command = "check_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.
|
||||
|
||||
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
|
||||
|
||||
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
|
||||
|
||||
~~~
|
||||
object CheckCommand "by_ssh_swap" {
|
||||
import "by_ssh"
|
||||
|
||||
vars.by_ssh_command = "/usr/lib/nagios/plugins/check_swap -w $by_ssh_swap_warn$ -c $by_ssh_swap_crit$"
|
||||
vars.by_ssh_swap_warn = "75%"
|
||||
vars.by_ssh_swap_crit = "50%"
|
||||
}
|
||||
|
||||
object Service "swap" {
|
||||
import "generic-service"
|
||||
|
||||
host_name = "remote-ssh-host"
|
||||
check_command = "by_ssh_swap"
|
||||
vars.by_ssh_logname = "icinga"
|
||||
}
|
||||
~~~
|
||||
|
||||
Cool fact, on peut donc faire du NRPE par SSH (dans le cas d'une machine en NAT). Exemple :
|
||||
|
||||
~~~
|
||||
object CheckCommand "nrpe_via_ssh" {
|
||||
import "by_ssh"
|
||||
|
||||
vars.by_ssh_command = "/usr/lib/nagios/plugins/check_nrpe -H $host.vars.internalIP$ $service.vars.nrpe_command$"
|
||||
vars.by_ssh_logname = "monitoring"
|
||||
|
||||
}
|
||||
|
||||
apply Service "ssh-nrpe-load" {
|
||||
import "generic-service"
|
||||
|
||||
check_command = "nrpe_via_ssh"
|
||||
vars.nrpe_command = "-c check_load"
|
||||
vars.notification_period = "worktime"
|
||||
|
||||
assign where host.vars.service_base && host.check_command == "nrpe_via_ssh"
|
||||
}
|
||||
~~~
|
||||
|
|
|
|||
Loading…
Reference in a new issue