Présentation
Après avoir travaillé sur l’accès aux ressources avec Vauban, il était temps de s'occuper d'une autre brique indispensable dans un SI : le monitoring. 📡
Parce que oui, c'est bien cette petite technologie qui vous prévient quand un problème arrive… idéalement avant que quelqu'un ne vous appelle pour vous dire que « ça marche plus ». 😄
Pour cette nouvelle brique, j'ai choisi de m'appuyer principalement sur Zabbix et GLPI.
Mais pourquoi GLPI dans une architecture de supervision ?
Parce que GLPI ne va pas uniquement servir de système de ticketing. Il va également devenir notre inventaire de référence.
capture d'écran de l'inventaire GLPI
📦 Automatiser l'intégration des machines
L'objectif est simple : éviter de devoir déclarer manuellement chaque nouvelle VM dans Zabbix.
Lorsqu'une VM rejoint l'infrastructure :
🖥️ Le GLPI Agent remonte automatiquement son inventaire dans GLPI.
Capture d'interface GLPI - Inventaire machine
⚙️ Un script développé pour HIVE vérifie ensuite régulièrement l'inventaire GLPI. Le script ne provisionne pas aveuglément toutes les machines présentes dans GLPI : il cible les VM de l'infrastructure HIVE disposant de l'environnement nécessaire à leur supervision.
🔄 Toutes les 5 minutes, il récupère les machines concernées et utilise l'API Zabbix pour créer ou mettre à jour les hôtes.
Hotes Zabbix
📡 Il suffit alors que la VM dispose de Zabbix Agent 2 et que l'hôte soit correctement provisionné dans Zabbix pour qu'elle soit supervisée.
Résultat :
Flux d'approvisionnement
Pas besoin de recréer manuellement l'hôte dans Zabbix à chaque déploiement.
🚨 Et quand quelque chose casse ?
C'est là que l'intégration devient vraiment intéressante.
Zabbix surveille les VM de l'infrastructure HIVE à l'aide des templates Linux et Windows fournis avec Zabbix.
Lorsqu'un problème de sévérité High ou supérieure est détecté, une action Zabbix déclenche un Media Type Webhook dédié à GLPI.
🔗 Le webhook communique avec l'API REST de GLPI.
🎫 Un ticket est automatiquement créé avec les informations de l'événement Zabbix.
Flux de création d'un ticket dans GLPI via API
Et lorsque le problème disparaît ?
🔄 Zabbix passe l'événement en OK.
Flux de résolution automatique d'un ticket
Le webhook retrouve alors le ticket correspondant grâce à l'ID de l'événement et ajoute automatiquement la résolution.
On obtient donc une chaîne complète :
Détection → Ticket → Résolution
…sans intervention humaine.
exemple de ticket
🧩 Une API ? Mais quelle est donc cette insulte ?
Derrière cette automatisation se trouvent simplement des API.
Une API permet à deux applications de communiquer entre elles : une application envoie une requête, l'autre la traite et renvoie une réponse.
C'est ce mécanisme qui permet ici à GLPI et Zabbix de travailler ensemble.
Et forcément, ça n'a pas été parfaitement fluide dès le départ.
Entre les deux générations d'API disponibles dans GLPI, les différentes configurations du webhook et surtout un Media Type que j'avais oublié d'associer correctement à l'utilisateur utilisé par Zabbix…
Le trigger fonctionnait.
L'incident était bien détecté.
Mais le ticket ne partait pas.
Le genre de problème où tu passes un bon moment à chercher un bug dans ton script avant de réaliser que tu as simplement oublié une case dans la configuration. 😅
Dans mon cas, le problème ne venait donc pas du script, mais de la configuration du compte utilisateur utilisé par le Media Type.
📚 Construire à partir de l'existant
Cette intégration n'est pas sortie de nulle part.
La base d'implémentation provient d'un TP fourni par Mickaël MATHIEU, dans le cadre d'un cours sur la supervision à CESI .
J'ai ensuite adapté cette base à l'architecture HIVE, notamment pour automatiser l'intégration de l'inventaire GLPI dans Zabbix et mettre en place la chaîne de ticketing.
Et aujourd'hui, le résultat est une petite chaîne d'automatisation assez simple, mais qui évite une quantité non négligeable d'actions manuelles :
📦 GLPI → inventaire 📡 Zabbix → supervision 🚨 Zabbix → détection 🎫 GLPI → ticketing 🔄 Zabbix + GLPI → résolution automatique
L'objectif n'était donc pas simplement de « mettre Zabbix ».
L'idée était surtout de faire en sorte que les différentes briques de HIVE puissent travailler ensemble.
Et finalement, un bon monitoring, ce n'est pas seulement savoir qu'un serveur est en panne.
C'est aussi faire en sorte que le reste du SI sache quoi faire quand il tombe. 🐝