Supervision centralisée d'une infrastructure hétérogène avec Zabbix

Le contexte

Une infrastructure de sept machines, moitié Windows moitié Linux, sur laquelle je n'avais aucune visibilité autre que la console de l'hyperviseur. Aucun moyen de savoir qu'un disque se remplissait, qu'un service s'était arrêté ou qu'une machine avait redémarré pendant la nuit — sinon en s'en apercevant trop tard.

L'objectif

Passer d'une exploitation réactive à une exploitation informée : collecter en continu l'état des machines, définir les seuils qui distinguent un fonctionnement normal d'un incident, et présenter le résultat sous une forme exploitable au quotidien.

Avec une contrainte que je me suis fixée : l'installation des agents devait être automatisée. Installer sept agents à la main est faisable ; c'est justement pour cette raison que ça n'apprend rien.

Les choix techniques

Zabbix 7.0 LTS plutôt que la dernière version. Une version LTS est maintenue plusieurs années, ce qui correspond au cycle de vie réel d'une plateforme de supervision — on ne remplace pas son outil de surveillance tous les six mois.

Debian plutôt qu'une distribution Zabbix clé en main. Installer la pile complète — base de données, serveur web, moteur Zabbix, interface — c'est comprendre comment les composants s'articulent. Un appliance masque exactement ce que je voulais apprendre.

Une pile MariaDB + Nginx + PHP-FPM, dimensionnée pour la charge réelle : sept hôtes, quelques centaines d'éléments collectés.

Ce que j'ai réalisé

Le serveur

Debian 13 Trixie en installation minimale, adressage statique, IPv6 désactivé au niveau de la pile. Le serveur a été durci avant toute installation applicative :

• SSH déplacé sur un port non standard, connexion root interdite ;
• pare-feu UFW en refus par défaut, SSH restreint au réseau local ;
• fail2ban en backend systemd, configuré pour surveiller le port réel et non le port par défaut ;
• mises à jour de sécurité automatiques ;
• synchronisation horaire alignée sur le contrôleur de domaine.

Pourquoi durcir un serveur de lab ? Parce qu'un serveur de supervision connaît toute l'infrastructure. C'est la machine qui sait où sont les autres, ce qu'elles hébergent et comment elles se portent. Elle mérite d'être traitée comme une cible.

Puis la pile applicative : MariaDB avec sa base et son utilisateur dédié, import du schéma, Nginx et PHP-FPM, et le moteur Zabbix 7.0.

Le déploiement des agents — la partie automatisée

Plutôt que d'installer l'agent poste par poste, j'ai écrit un script PowerShell idempotent déposé sur le partage NETLOGON du contrôleur de domaine et déclenché par une stratégie de groupe au démarrage des machines.

Le script vérifie d'abord si l'agent est déjà présent — s'il l'est, il s'arrête là. Sinon il installe le paquet MSI en mode silencieux, en désactivant explicitement la création de règle de pare-feu par l'installeur.

Ce dernier point est délibéré : la règle de pare-feu est gérée par la stratégie de groupe, pas par l'installeur, et elle n'ouvre le port 10050 qu'à une seule adresse source — celle du serveur de supervision. Le port de l'agent n'est donc joignable que par la machine qui a une raison légitime de l'interroger.

Sept hôtes ont été raccordés et validés individuellement en interrogeant leur agent depuis le serveur : l'hyperviseur, le contrôleur de domaine, le serveur de fichiers, le serveur de sauvegarde, le serveur Zabbix lui-même et les deux postes clients.

La configuration

Modèles standards liés par famille de système, groupes d'hôtes séparant serveurs Linux, serveurs Windows et postes clients.

Rétention adaptée au support : l'historique détaillé ramené à 7 jours, les tendances agrégées conservées 180 jours, l'historique des déclencheurs à 90 jours. Sur un disque de 32 Go, la rétention par défaut d'un an aurait saturé le stockage — et c'est le seul réglage de Zabbix dont on s'aperçoit trop tard.

Faux positifs traités plutôt qu'ignorés : le modèle Windows par défaut remonte l'arrêt de services qui sont légitimement à l'arrêt. Le service AppXSvc a été exclu par macro sur le modèle, ce qui règle le cas sur toutes les machines Windows d'un coup. Trois interfaces réseau sans débit physique lisible ont été identifiées, expliquées et laissées en l'état, avec le raisonnement documenté.

Les tableaux de bord

Deux vues, parce qu'elles répondent à deux questions différentes.

« Lab – Exploitation » — qu'est-ce qui ne va pas maintenant ? Un widget Top des hôtes affichant en barres colorées la charge processeur, l'occupation mémoire et le remplissage des disques de chaque machine, avec un seuil d'alerte à 70 % en orange et un seuil critique à 80 % en rouge. À côté : les incidents en cours, la disponibilité des agents, l'horloge.

Détail technique rencontré : le widget Top des hôtes n'accepte pas les jokers dans les noms d'éléments. Les volumes système Linux et Windows ayant des noms différents, il a fallu créer une colonne par nomenclature — là où le widget Graphique accepte les motifs sans difficulté.

« Lab – Synthèse » — comment se comporte l'infrastructure dans la durée ? Répartition des problèmes par sévérité, inventaire de la plateforme, et trois graphiques multi-hôtes sur 24 heures — processeur, mémoire, disques — avec légende affichant minimum, moyenne et maximum.

Une palette chromatique fixe attribue une couleur à chaque machine et la conserve sur tous les graphiques. L'hyperviseur est toujours rouge, le contrôleur de domaine toujours bleu. On identifie une courbe sans lire la légende.

Pour le graphique des disques, seuls les volumes réellement critiques sont suivis — raisonnement en termes de criticité métier plutôt qu'exhaustivité : le disque d'un poste client n'a pas la même conséquence que celui du datastore de sauvegarde.

Le résultat

Sept hôtes supervisés, des centaines d'éléments collectés, deux tableaux de bord opérationnels et un déploiement d'agents entièrement automatisé — une nouvelle machine jointe au domaine est supervisée dès son premier démarrage, sans intervention.

Ce que j'en retiens

La supervision technique est la partie facile : les modèles standards font 90 % du travail. Le travail réel, c'est de décider ce qui mérite une alerte. Un outil qui alerte sur tout n'alerte sur rien — au bout de trois jours, plus personne ne regarde.

Le tri des faux positifs n'est pas du nettoyage cosmétique : c'est ce qui détermine si la plateforme sera utilisée ou abandonnée.