355 lines
18 KiB
Markdown
355 lines
18 KiB
Markdown
**Cette page a été importée automatiquement de notre ancien wiki mais n'a pas encore été révisée.**
|
|
|
|
## Introduction
|
|
|
|
Icinga2 est un logiciel de monitoring réseau qui vise à surveiller des services en place sur des serveurs.
|
|
|
|
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
|
|
|
|
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 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.
|
|
|
|
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...
|
|
|
|
### 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 envoyer au serveur central les résultats ponctuellement. La configuration réside sur les machines locales et est synchronisée avec 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).
|
|
|
|
### 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 ici](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).
|
|
|
|
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).
|
|
|
|
|
|
## Installation du master
|
|
|
|
### Icinga2
|
|
|
|
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.
|
|
|
|
~~~
|
|
# 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
|
|
# apt update
|
|
# apt install icinga2
|
|
~~~
|
|
|
|
Pour finaliser l'installation d'icinga2 en master, il faut se servir de son assistant de configuration. Il se chargera de créer une CA 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:
|
|
|
|
~~~
|
|
# icinga2 node wizard
|
|
~~~
|
|
|
|
On termine par un redémarrage complet du daemon pour activer les changements de la configuration
|
|
|
|
~~~
|
|
# service icinga2 restart
|
|
~~~
|
|
|
|
### WebUI
|
|
|
|
Pour fonctionner, la WebUI a besoin d'un serveur web avec PHP et d'un serveur de base de donnée. Dans les exemples qui suivent, 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, au 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`
|
|
|
|
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
|
|
~~~
|
|
|
|
Il est possible de lancer des commandes (planifier un check, downtimer une machine...) à partir du WebUI directement. Pour cela, il faut ajouter à l'utilisateur du serveur web au groupe `nagios`.
|
|
|
|
~~~
|
|
# addgroup --system www-data nagios
|
|
# icinga2 feature enable command
|
|
# service icinga2 restart
|
|
~~~
|
|
|
|
Pour continuer l'installation du WebUI, on visite le <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
|
|
~~~
|
|
|
|
La prochaine étape de l'assistant vous demande quelles fonctions activer. Il est recommandé de choisir `Doc` et `Monitoring`.
|
|
|
|
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. 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 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`.
|
|
|
|
Et voilà! Votre WebUI devrait être en place et vous devriez pouvoir vous connecter au <http://example.org/icingaweb2/>
|
|
|
|
## Installation d'un client
|
|
|
|
### Configuration du lien master-client
|
|
|
|
Par défaut, quand on installe icinga2 sur une machine, le daemon est lancé et icinga2 se met à surveiller l'hôte local. Pour cette documentation, nous allons monter une architecture de surveillance de type [#Configurationencluster "configuration en cluster"]. Cela va nous permettre de pouvoir centraliser la configuration à un seul endroit et de la gérer à travers Git.
|
|
|
|
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.
|
|
|
|
On commence donc par installer `icinga2` :
|
|
|
|
~~~
|
|
# 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
|
|
# apt update
|
|
# apt install icinga2
|
|
~~~
|
|
|
|
Une fois que cela est fait, on lance l'assistant de configuration :
|
|
|
|
~~~
|
|
# icinga2 node wizard
|
|
~~~
|
|
|
|
L'assistant nous pose plusieurs questions. On y répond de la manière suivante :
|
|
|
|
~~~
|
|
Please specify if this is a satellite setup ('n' installs a master setup) [Y/n]: y
|
|
Starting the Node setup routine...
|
|
Please specifiy the common name (CN) [icinga2-client1]:
|
|
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 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]:
|
|
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):
|
|
|
|
Certificate information:
|
|
|
|
Subject: CN = icinga2-master
|
|
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
|
|
|
|
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'.
|
|
|
|
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'.
|
|
Please specify the API bind host/port (optional):
|
|
Bind Host []:
|
|
Bind Port []:
|
|
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:
|
|
|
|
~~~
|
|
icinga2 pki ticket --cn '<nom du client>'
|
|
~~~
|
|
|
|
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 :
|
|
|
|
~~~
|
|
[...]
|
|
|
|
object Endpoint "icinga2-client1" {
|
|
host = "<adresse ip du client>"
|
|
}
|
|
|
|
object Zone "icinga2-client1" {
|
|
endpoints = [ "icinga2-sclient1" ]
|
|
parent = "master"
|
|
}
|
|
~~~
|
|
|
|
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 le 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 client.
|
|
|
|
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:
|
|
|
|
~~~
|
|
# mkdir /etc/icinga2/zones.d/icinga2-client1
|
|
~~~
|
|
|
|
Dans ce dossier, on crée un fichier nommé `hosts.conf` qui va nous servir à définir un nouvel objet de type `Host`. Cet objet va nous permettre par la suite de lier d'autres types d'objets à notre nouveau client :
|
|
|
|
~~~
|
|
object Host "icinga2-client1" {
|
|
check_command = "hostalive"
|
|
address = "<adresse ip du client>"
|
|
zone = "master"
|
|
}
|
|
~~~
|
|
|
|
On peut maintenant ajouter de nouveaux tests dans `services.conf`, des objets de type `Service` :
|
|
|
|
~~~
|
|
object Service "disk" {
|
|
import "generic-service"
|
|
|
|
host_name = "icinga2-sclient1"
|
|
check_command = "disk"
|
|
}
|
|
|
|
object Service "ssh" {
|
|
import "generic-service"
|
|
|
|
host_name = "icinga2-sclient1"
|
|
check_command = "ssh"
|
|
}
|
|
~~~
|
|
|
|
Pour que la synchronisation se fasse entre le master et le client, on redémarre `icinga2` sur le master :
|
|
|
|
~~~
|
|
# service icinga2 reload
|
|
~~~
|
|
|
|
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`.
|
|
|
|
|
|
## Plomberie
|
|
|
|
### Dossiers par défaut d'icinga2
|
|
|
|
* `/etc/icinga2` Dossier des fichiers de configuration
|
|
* `/usr/share/icinga2/include` Dossier des templates & commandes par défaut
|
|
* `/var/lib/icinga2` Dossier de "travail" d'`icinga2`, contient la CA, les logs cluster, la configuration chargée et/ou reçue, un fichier dump de l'état du cluster
|
|
|
|
### 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:
|
|
|
|
~~~
|
|
# 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).
|
|
|
|
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.
|
|
|
|
|
|
#### init.conf
|
|
|
|
Le premier fichier à être lu au démarrage du daemon. Il sert à définir sous quel groupe et quel user le daemon est lancé.
|
|
|
|
*Note* : Sous Debian 8, icinga2 fonctionne sous l'utilisateur et le groupe `nagios`
|
|
|
|
#### icinga2.conf
|
|
|
|
Le fichier de configuration principal. Il sert surtout à définir les fichiers de configuration qui seront lus, comme `/features-enabled/*` par exemple. Ce fichier est le second à être lu au démarrage du daemon.
|
|
|
|
*Note* : En configuration en cluster, une bonne pratique est de commenter l'inclusion du dossier `conf.d`
|
|
|
|
#### constants.conf
|
|
|
|
Ce fichier regroupe les constantes globales d'Icinga2. On y trouve entre autres le Salt pour la génération de tokens et le nom de domaine du master (`NodeName`).
|
|
|
|
#### zones.conf
|
|
|
|
Ce fichier sert à définir les relations entre le master et les clients, comme démontré dans l'exemple de configuration plus haut.
|
|
|
|
#### features-available
|
|
|
|
Les fichiers dans ce dossier sont des plugins qui peuvent être activés avec les commandes suivantes :
|
|
|
|
~~~
|
|
# icinga2 feature enable <nom du plugin>
|
|
# service icinga2 reload
|
|
~~~
|
|
|
|
Une fois activés, il sont symlinkés dans `/features-enabled`, un peu comme pour Apache.
|
|
|
|
#### 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/`.
|
|
|
|
#### 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`.
|
|
|
|
#### 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.).
|
|
|
|
#### repository.d et zones.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`.
|
|
|
|
### Utilisation de NRPE
|
|
|
|
Lors de la bascule 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.
|
|
|
|
Pour cela, il faut d'abord récupérer le client `NRPE` :
|
|
|
|
~~~
|
|
# apt install nagios-nrpe-plugin
|
|
~~~
|
|
|
|
En suite, il suffit juste de créer les services dans la configuration du master pour paramettrer les checks voulu. L'exemple suivant crée un service `swap` pour la machine `remote-nrpe-host` qui exécutera la commande `check_swap` par NRPE.
|
|
|
|
~~~
|
|
object Service "nrpe-swap" {
|
|
import "generic-service"
|
|
|
|
host_name = "remote-nrpe-host"
|
|
|
|
check_command = "nrpe"
|
|
vars.nrpe_command = "check_swap"
|
|
}
|
|
~~~
|