Dans notre précédent article, nous avons installé l’application de supervision Icinga – ainsi que l’interface graphique Icinga Web – sur un serveur dédié. Le moment est venu de passer aux choses sérieuses en utilisant notre installation flambant neuve pour surveiller l’état des hôtes et des services de notre réseau.
La supervision des machines distantes peut s’effectuer grosso modo de deux manières.
- à distance et sans rien installer sur la machine à distance, ce qui n’offre que des possibilités de contrôle très limitées (
ping
,ssh
,http
). - en installant un agent Icinga sur les serveurs, ce qui permet beaucoup plus de flexibilité dans la supervision.
Même si Icinga est fait pour tourner exclusivement sur les plateformes Linux et Unix, sachez que l’agent Icinga est compatible avec les différentes versions de Windows Server. Vous pouvez donc utiliser Icinga pour surveiller votre parc de serveurs Microsoft.
Configurer le pare-feu
L’agent Icinga communique avec le serveur de supervision via le port 5665. Avant toute chose, je vais donc songer à ouvrir ce port.
$ sudo firewall-cmd --permanent --add-port=5665/tcp $ sudo firewall-cmd --reload
Préparer le serveur pour les clients
La prochaine étape consiste à préparer le serveur pour les clients. Icinga fournit un assistant de configuration en ligne de commande pour cette tâche, qui peut être invoqué par la commande node wizard
.
$ sudo icinga2 node wizard Welcome to the Icinga 2 Setup Wizard! We will guide you through all required configuration details. Please specify if this is an agent/satellite setup ('n' installs a master setup) [Y/n]: n Starting the Master setup routine... Please specify the common name (CN) [sd-100246.dedibox.fr]: [Entrée] Reconfiguring Icinga... Checking for existing certificates for common name 'sd-100246.dedibox.fr'... ... Generating master configuration for Icinga 2. 'api' feature already enabled. Master zone name [master]: [Entrée] Default global zones: global-templates director-global Do you want to specify additional global zones? [y/N]: [Entrée] Please specify the API bind host/port (optional): Bind Host []: [Entrée] Bind Port []: [Entrée] Do you want to disable the inclusion of the conf.d directory [Y/n]: n Done. Now restart your Icinga 2 daemon to finish the installation! $ sudo systemctl restart icinga2
Quelques remarques sur les différentes options utilisées.
- Icinga permet la supervision distribuée dans des configurations relativement complexes et distingue entre
master
,satellite
etagent
. Dans l’exemple présenté ici, je me servirai uniquement des rôlesmaster
etagent
. En répondantn
(no) à la première question, je définis mon installation comme serveur de supervision « maitre ». - Pour la suite et jusqu’à l’avant-dernière question incluse, je confirme les paramètres proposés par défaut, comme le CN (
sd-100246.dedibox.fr
), le nom de la zone (master
), etc. - La dernière question concerne l’exclusion du répertoire de configuration
/etc/icinga2/conf.d
. Ce répertoire contient déjà une configuration par défaut, que nous avons d’ailleurs vue à l’oeuvre lors de la première connexion au tableau de bord. Si nous répondons par l’affirmative à cette question, toute cette configuration initiale est rejetée, ce qui nous oblige à repartir de zéro. J’ai expérimenté avec les deux approches, et pour ma part, j’ai trouvé qu’il était plus simple de partir de la configuration existante en l’adaptant à mes besoins. Quoi qu’il en soit, répondez parn
(no) pour ne pas exclure le contenu deconf.d
.
Peaufiner la configuration initiale
Dans la configuration proposée par défaut, le serveur Icinga surveille son propre état, ce qui se manifeste sous forme d’une série de tests comme disk
, icinga
, swap
, users
, ping4
, ping6
, procs
, load
ou ssh
qui s’affichent sur le tableau de bord.
Avant d’aller plus loin et intégrer d’autres machines, je vais modifier cette configuration initiale pour corriger l’affichage d’une erreur, mais surtout pour rendre les tests plus lisibles.
Pour commencer, je vais sauvegarder cette configuration existante pour pouvoir expérimenter plus sereinement et revenir en arrière si je me tire dans le pied.
$ sudo cp -R /etc/icinga2/conf.d/ /etc/icinga2/conf.d.orig
Adapter la configuration à l’IPv4
Comme nous l’avons vu à la fin de notre précédent article sur Icinga, le test ping6
échoue pour la simple et bonne raison que nous n’utilisons que l’IPv4 sur cette machine.
Ouvrez le fichier /etc/icinga2/conf.d/hosts.conf
et repérez la stance suivante.
/* Specify the address attributes for checks e.g. `ssh` or `http`. */ address = "127.0.0.1" address6 = "::1"
Supprimez la ligne qui commence par address6
et enregistrez les modifications.
Testez la validité de la configuration et repérez l’avertissement relatif à ping6
.
$ sudo icinga2 daemon -C ... information/cli: Icinga application loader (version: 2.12.0-1) ... information/cli: Loading configuration file(s). ... information/ConfigItem: Committing config item(s). ... information/ApiListener: My API identity: sd-100246.dedibox.fr ... warning/ApplyRule: Apply rule 'ping6' (in /etc/icinga2/conf.d/services.conf: 34:1-34:21) for type 'Service' does not match anywhere! ... information/ConfigItem: Instantiated 1 NotificationComponent.
Ouvrez /etc/icinga2/conf.d/services.conf
et repérez la stance qui définit le service ping6
.
apply Service "ping6" {
import "generic-service"
check_command = "ping6"
assign where host.address6
}
Supprimez cette stance, enregistrez les modifications, quittez le fichier et relancez un test de la configuration.
$ sudo icinga2 daemon -C
Tous les tests s’affichent en vert, je vais donc prendre en compte cette nouvelle configuration.
$ sudo systemctl reload icinga2
Le tableau de bord n’affiche plus la moindre erreur.
Activer le test pour Icinga Web
Le fichier hosts.conf
fournit une stance commentée qui permet de superviser l’application Icinga Web elle-même.
/* Uncomment if you've sucessfully installed Icinga Web 2. */
//vars.http_vhosts["Icinga Web 2"] = {
// http_uri = "/icingaweb2"
//}
Je décommente cette stance en renommant le service Icinga Web
.
/* Uncomment if you've sucessfully installed Icinga Web 2. */
vars.http_vhosts["Icinga Web"] = {
http_uri = "/icingaweb2"
}
Là encore, je teste la validité de la syntaxe.
$ sudo icinga2 daemon -C
Je prends en compte la nouvelle configuration.
$ sudo systemctl reload icinga2
Vous aurez compris que d’une manière générale, c’est toujours une bonne idée de procéder par petites modifications incrémentales en testant à chaque fois la validité de la configuration.
Au bout de trente secondes, je vois apparaître le nouveau service Icinga Web
dans la liste.
Améliorer la lisibilité des services de base
Le fichier conf.d/services.conf
contient toute une panoplie de services prédéfinis. Je vais éditer ces définitions pour arranger la lisibilité de l’affichage.
Dans la stance qui définit le test ping4
, je remplace le nom du service par Ping
.
apply Service "Ping" { import "generic-service" check_command = "ping4" assign where host.address }
Cette modification devra également être renseignée dans le fichier groups.conf
, qui regroupe un certain nombre de services.
object ServiceGroup "Ping" { display_name = "Ping Checks" assign where match("Ping*", service.name) }
Je retourne dans le fichier services.conf
et j’édite la stance qui définit le test relatif à la charge du système.
apply Service "System load" {
import "generic-service"
check_command = "load"
/* Used by the ScheduledDowntime apply rule in `downtimes.conf`. */
vars.backup_downtime = "02:00-03:00"
assign where host.name == NodeName
}
Toujours dans cette même logique, je remplace procs
par Running processes
, swap
par Swap usage
et users
par Logged users
.
apply Service "Running processes" { import "generic-service" check_command = "procs" assign where host.name == NodeName } apply Service "Swap usage" { import "generic-service" check_command = "swap" assign where host.name == NodeName } apply Service "Logged users" { import "generic-service" check_command = "users" assign where host.name == NodeName }
Un peu plus haut dans le fichier, ssh
deviendra SSH
.
apply Service "SSH" { import "generic-service" check_command = "ssh" assign where (host.address || host.address6) && host.vars.os == "Linux" }
Quant au service icinga
, on va le renommer en Icinga
.
apply Service "Icinga" { import "generic-service" check_command = "icinga" assign where host.name == NodeName }
J’enregistre les modifications apportées à services.conf
et j’ouvre hosts.conf
, où je vais également renommer quelques tests. Ainsi, http
devient HTTP
.
/* Define http vhost attributes for service apply rules in `services.conf`. */
vars.http_vhosts["HTTP"] = {
http_uri = "/"
}
Dans la section qui définit les tests des disques durs, je remplace disk
par Hard disk
.
/* Define disks and attributes for service apply rules in `services.conf`. */ vars.disks["Hard disk"] = { /* No parameters. */ }
En passant, je simplifie l’affichage de ce service en supprimant la stance suivante.
vars.disks["disk /"] = {
disk_partitions = "/"
}
Toutes ces petites améliorations peuvent vous paraître insignifiantes et simplement cosmétiques. Je vous laisse donc apprécier la lisibilité de l’ensemble après avoir pris en compte l’ensemble des modifications apportées.
Connecter un serveur public
Je choisis une première machine publique que je souhaite surveiller. Je commence par générer un ticket pour cette machine.
$ sudo icinga2 pki ticket --cn sd-107066.dedibox.fr d8b8485685edbfa29ecd9
Je garde cet affichage, j’ouvre un deuxième terminal et je me connecte à la machine sd-107066.dedibox.fr
, qui tourne également sous CentOS 7. Pour installer l’agent Icinga – identique au moteur de l’application qui tourne sur notre serveur de supervision – je dois passer par les mêmes étapes que sur le serveur Icinga.
- Configurer le dépôt du projet Icinga.
- Installer les paquets de base Icinga.
- Installer une panoplie de plugins Nagios.
- Activer et lancer le démon correspondant.
- Ouvrir le port 5665 puisque l’agent et le serveur maître doivent pouvoir communiquer dans les deux sens.
$ sudo yum install -y \ https://packages.icinga.com/epel/icinga-rpm-release-7-latest.noarch.rpm $ sudo yum install -y icinga2 icinga2-selinux $ sudo yum install -y \ nagios-plugins-{ping,ssh,http,disk,load,procs,swap,users} $ sudo systemctl enable icinga2 --now $ sudo firewall-cmd --permanent --add-port=5665/tcp $ sudo firewall-cmd --reload
Sur la machine client, j’utilise également la commande node wizard
pour connecter l’agent au serveur de supervision.
$ sudo icinga2 node wizard Welcome to the Icinga 2 Setup Wizard! We will guide you through all required configuration details. Please specify if this is an agent/satellite setup ('n' installs a master setup) [Y/n]: [Entrée] Starting the Agent/Satellite setup routine... Please specify the common name (CN) [sd-107066.dedibox.fr]: [Entrée] Please specify the parent endpoint(s) (master or satellite) where this node should connect to: Master/Satellite Common Name (CN from your master/satellite node): sd-100246.dedibox.fr Do you want to establish a connection to the parent node from this node? [Y/n]: [Entrée] Please specify the master/satellite connection information: Master/Satellite endpoint host (IP address or FQDN): sd-100246.dedibox.fr Master/Satellite endpoint port [5665]: [Entrée] Add more master/satellite endpoints? [y/N]: [Entrée] Parent certificate information: Version: 3 Subject: CN = sd-100246.dedibox.fr Issuer: CN = Icinga CA Valid From: Sep 28 08:10:54 2020 GMT Valid Until: Sep 25 08:10:54 2035 GMT Serial: 8d:93:d2:be:ea:33:32:08:eb:b3:b2:27:be:b4:46:94:fc:a7:4f:f7 Signature Algorithm: sha256WithRSAEncryption Subject Alt Names: sd-100246.dedibox.fr Fingerprint: DE 17 A5 4D 5C 6D F8 8F 0C 70 E3 64 A4 4E 63 07 73 66 F7 63 69 B0 5E 74 F7 04 F9 32 A4 47 77 65 Is this information correct? [y/N]: y Please specify the request ticket generated on your Icinga 2 master (optional). (Hint: # icinga2 pki ticket --cn 'sd-107066.dedibox.fr'): d8b8485685edbfa29ecd9 Please specify the API bind host/port (optional): Bind Host []: [Entrée] Bind Port []: [Entrée] Accept config from parent node? [y/N]: y Accept commands from parent node? [y/N]: y Reconfiguring Icinga... Disabling feature notification. Make sure to restart Icinga 2 for these changes to take effect. Enabling feature api. Make sure to restart Icinga 2 for these changes to take effect. Local zone name [sd-107066.dedibox.fr]: [Entrée] Parent zone name [master]: [Entrée] Default global zones: global-templates director-global Do you want to specify additional global zones? [y/N]: [Entrée] Do you want to disable the inclusion of the conf.d directory [Y/n]: [Entrée] Disabling the inclusion of the conf.d directory... Done. Now restart your Icinga 2 daemon to finish the installation! $ sudo systemctl restart icinga2
Notez qu’ici nous avons choisi de désactiver l’inclusion du répertoire
conf.d
. C’est normal, puisque toute la configuration d’Icinga se trouve sur le serveur de supervision.
Je n’ai plus rien à faire sur le client. Je me reconnecte au serveur et je crée un nouveau répertoire dans l’arborescence d’Icinga.
$ sudo mkdir -v /etc/icinga2/zones.d/master mkdir: created directory ‘/etc/icinga2/zones.d/master’
Dans ce répertoire, je crée un fichier que je nomme en fonction de mon hôte à surveiller.
// /etc/icinga2/zones.d/master/host-sd-107066.dedibox.fr.conf object Endpoint "sd-107066.dedibox.fr" { } object Zone "sd-107066.dedibox.fr" { endpoints = [ "sd-107066.dedibox.fr" ] parent = "master" } object Host "sd-107066.dedibox.fr" { import "generic-host" address = "163.172.81.8" vars.os = "Linux" vars.client_endpoint = name }
Notez que vous pouvez nommer ce fichier comme vous voulez, du moment qu’il se termine par
*.conf
. Pour ma part, je lui ai simplement donné un nom parlant.
Là encore, je vérifie si je n’ai pas fait d’erreurs de syntaxe.
$ sudo icinga2 daemon -C ... information/cli: Icinga application loader (version: 2.12.0-1) ... information/cli: Loading configuration file(s). ... information/ConfigItem: Committing config item(s). ... information/ApiListener: My API identity: sd-100246.dedibox.fr ... ... information/cli: Finished validating the configuration file(s).
Icinga ne m’affiche aucune erreur. Je peux donc sereinement prendre en compte la nouvelle configuration.
$ sudo systemctl reload icinga2
Je me connecte à l’interface d’Icinga et je vois mon nouvel hôte en attente (PENDING
) d’un premier test de connexion.
Définir quelques tests de base
Je vais demander à mon agent de supervision d’effectuer quelques tests assez basiques relatifs à l’état de santé de mon serveur. Toujours dans le répertoire /etc/icinga2/zones.d/master
, je vais créer un fichier service-load.conf
que je vais éditer comme ceci.
// /etc/icinga2/zones.d/master/service-load.conf
//
// System load check executed on client node
apply Service "System load" {
import "generic-service"
check_command = "load"
command_endpoint = host.vars.client_endpoint
assign where host.vars.client_endpoint
}
Je prends en charge la nouvelle configuration après avoir vérifié la syntaxe de mon fichier.
$ sudo icinga2 daemon -C $ sudo systemctl reload icinga2
J’attends un peu, et je vois apparaître ce test de charge en état d’attente, puis tout en haut dans la colonne de droite.
Partant de là, je vais ajouter quelques vérifications de base en suivant la même logique.
J’ajoute la supervision de l’état du disque dur du serveur.
// /etc/icinga2/zones.d/master/service-disk.conf
//
// System disk usage check executed on client node
apply Service "Hard disk" {
import "generic-service"
check_command = "disk"
command_endpoint = host.vars.client_endpoint
assign where host.vars.client_endpoint
}
Je souhaite en savoir un peu plus sur l’utilisation de la partition d’échange de la machine.
// /etc/icinga2/zones.d/master/service-swap.conf
//
// Swap memory usage check executed on client node
apply Service "Swap usage" {
import "generic-service"
check_command = "swap"
command_endpoint = host.vars.client_endpoint
assign where host.vars.client_endpoint
}
Voici une vue d’ensemble sur le nombre et l’état des processus du serveur.
// /etc/icinga2/zones.d/master/service-procs.conf
//
// Running system processes check executed on client node
apply Service "Running processes" {
import "generic-service"
check_command = "procs"
command_endpoint = host.vars.client_endpoint
assign where host.vars.client_endpoint
}
Je peux également être renseigné sur les utilisateurs actuellement connectés au système.
// /etc/icinga2/zones.d/master/service-users.conf
//
// Logged users check executed on client node
apply Service "Logged users" {
import "generic-service"
check_command = "users"
command_endpoint = host.vars.client_endpoint
assign where host.vars.client_endpoint
}
J’aurais pu très bien écrire toutes ces stances dans un seul gros fichier
services.conf
. Plutôt que de faire cela, j’aime bien répartir ma configuration dans des petits bouts de fichier individuels. Différents chemins mènent à Saint-Bauzille-de-Putois.
À chaque fois que je définis un ou plusieurs nouveaux tests, l’interface d’Icinga met un certain temps – entre 30 secondes et une minute – à les prendre en compte.
Connecter un serveur derrière un NAT
Nous venons de configurer une poignée de vérifications de base pour une machine avec une ouverture frontale sur Internet. À partir du moment où nous utilisons l’agent Icinga, nous pouvons également gérer la supervision d’une machine coincée derrière un routeur et normalement inaccessible depuis l’extérieur. Pour ce faire, il suffit qu’elle dispose d’une connexion à Internet pour contacter le serveur de supervision.
Dans l’exemple qui suit, je vais intégrer le routeur proxy.microlinux.lan
installé dans mon bureau dans la liste des machines à surveiller depuis mon serveur Icinga.
- J’installe l’agent Icinga et les plugins Nagios sur le client.
- J’ouvre le port 5665 sur le client.
- Je crée un ticket pour
proxy.microlinux.lan
sur le serveur. - Je connecte le client au serveur en transmettant le ticket au
node wizard
.
Une fois que la connexion entre l’agent et le serveur est établie, je crée un fichier host-proxy.microlinux.lan.conf
sur le serveur.
// /etc/icinga2/zones.d/master/host-proxy.microlinux.lan.conf
object Endpoint "proxy.microlinux.lan" {
}
object Zone "proxy.microlinux.lan" {
endpoints = [ "proxy.microlinux.lan" ]
parent = "master"
}
object Host "proxy.microlinux.lan" {
check_command = "dummy"
vars.dummy_state = 0 // UP
vars.dummy_text = "Everything OK."
vars.os = "Linux"
vars.client_endpoint = name
}
Étant donné que je ne peux pas envoyer de
ping
à mon routeur depuis l’extérieur, je passe par la configuration de ce que l’on appelle un dummy host (ou « hôte bidon »). J’ai trouvé cette astuce dans la documentation officielle d’Icinga, dans la section Host Check Alternatives.
Je vérifie la syntaxe, je recharge la configuration et j’affiche l’interface d’Icinga. Les vérifications en attente s’affichent sur le tableau de bord.
Tester SSH sur les machines publiques
Certains tests – comme par exemple le bon fonctionnement du service SSH – ne peuvent être effectués par le serveur de supervision que sur les machines publiques, pour des raisons évidentes. Comment faire alors pour intégrer le service sous certaines conditions, sans que celui-ci ne nous affiche une série d’erreurs pour les machines injoignables depuis Internet ?
Éditez un fichier service-ssh.conf
comme ceci.
// /etc/icinga2/zones.d/master/service-ssh.conf
//
// SSH service check executed on public clients
apply Service "SSH" {
check_command = "ssh"
command_endpoint = host.vars.client_endpoint
assign where host.address
}
Notez bien la ligne
assign where host.address
, qui signifie que le test ne sera exécuté que sur les hôtes dont l’adresse IP est définie dans la configuration. Les dummy hosts ne sont donc pas concernés.
J’ouvre conf.d/services.conf
et je supprime la configuration initiale du service SSH.
apply Service "SSH" {
import "generic-service"
check_command = "ssh"
assign where (host.address || host.address6) && host.vars.os == "Linux"
}
Une fois que j’ai pris en compte la nouvelle configuration, je m’aperçois effectivement que le service SSH est supervisé sur la machine publique sd-107066.dedibox.fr
, mais pas sur le routeur local proxy.microlinux.lan
.
Recevoir des notifications par mail
Vous n’allez probablement pas rester les yeux rivés sur le tableau de bord d’Icinga pour superviser votre parc de machines – à moins que vous ne soyez un grand opérateur avec votre propre datacenter et des gens payés pour faire ça à longueur de journée.
Si votre entreprise est de taille plus modeste, la solution la plus pragmatique consiste à mettre en place les notifications par mail en cas de problème. C’est relativement simple à mettre en oeuvre.
Ouvrez le fichier de configuration d’un de vos hôtes, repérez la stance object Host
et ajoutez trois lignes comme ceci.
// /etc/icinga2/zones.d/master/host-sd-107066.dedibox.fr.conf
object Endpoint "sd-107066.dedibox.fr" {
}
object Zone "sd-107066.dedibox.fr" {
endpoints = [ "sd-107066.dedibox.fr" ]
parent = "master"
}
object Host "sd-107066.dedibox.fr" {
import "generic-host"
address = "163.172.81.8"
vars.client_endpoint = name
vars.notification["mail"] = {
groups = [ "icingaadmins" ]
}
}
Enregistrez les modifications, ouvrez le fichier conf.d/users.conf
et renseignez l’adresse mail vers laquelle vous souhaitez envoyer les notifications.
object User "icingaadmin" { import "generic-user" display_name = "Icinga 2 Admin" groups = [ "icingaadmins" ] email = "info@microlinux.fr" } object UserGroup "icingaadmins" { display_name = "Icinga 2 Admin Group" }
Une fois que vous avez pris en compte les modifications, il n’y a plus grand-chose à faire. À partir du moment où Icinga détecte un service dans un état critique – ou lorsqu’il n’arrive plus à joindre un hôte distant – il vous envoie une notification qui ressemble à ceci.
Si jamais il ne s’agissait que d’une interruption de service momentanée, Icinga vous avertit également dès que les choses retournent à la normale.
Pour aller plus loin
L’installation et la prise en main d’un serveur de supervision avec Icinga n’est pas une opération triviale, comme vous avez pu le voir. J’ai fait de mon mieux pour vous faciliter la tâche de manière à ce que vous soyez capable de franchir le pas et configurer « quelque chose qui marche ».
L’installation que nous avons effectuée est relativement basique, mais elle est tout à fait utilisable en production. Considérez-la comme un point de départ pour vos futures configurations. Réfléchissez aux différents services et processus que vous souhaitez garder à l’oeil, et faites une recherche dans la multitude de plugins Nagios disponible.
Enfin, n’hésitez pas à éplucher la documentation officielle d’Icinga, qui vous impressionnera un peu moins à présent.
La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.
1 commentaire
Julien · 27 avril 2022 à 15 h 36 min
Bonjour,
Je voulais déjà vous remercier pour cet article qui m’a énormément aidé (puisque c’est à ce jour encore le plus compréhensible et fonctionnel en français), je voulais juste savoir à quoi sert Icinga Director et si c’est vraiment utile de l’installer (sachant que tout les sites recommandent de l’installer.
Merci d’avance
Les commentaires sont fermés.