🌐 Aussi en: English · Deutsch · Español
🔍 Parfois, un projet perso naît d’un problème rencontré au travail, pas dans le homelab. C’est le cas ici : je me bats en ce moment professionnellement avec Graylog comme plateforme de gestion des logs, et il me fallait de vrais plugins de supervision pour lui – pour Icinga2 comme pour Zabbix. Quelqu’un a forcément déjà résolu ça, non ? Non ?? 😅
📉 La partie décevante : fouiller Google et GitHub
Mon premier réflexe a été le plus évident : trouver quelqu’un qui avait déjà construit tout ça, parce que réinventer la roue, c’est pour les naïfs. Les résultats étaient, pour rester poli, décevants. Ce qui existait était soit ultra-minimaliste (un check codé en dur, zéro seuil, l’équivalent en supervision d’un détecteur de fumée sans pile), soit franchement préhistorique – certains dépôts n’avaient pas vu de commit depuis jusqu’à dix ans. L’API REST de Graylog a pas mal évolué depuis la dernière fois qu’une main humaine a touché à ces plugins. Pas vraiment une base de supervision qui inspire confiance. 🦕
💡 L’idée légèrement déraisonnable
J’ai donc eu ce que j’appellerai généreusement une « idée glorieuse » : demander à Claude de monter Graylog, Icinga2 et Zabbix sur mon propre serveur avec Docker Compose, et de simplement… écrire les plugins de supervision de zéro, en testant tout en direct contre une vraie instance en fonctionnement, au lieu de copier-coller un article de blog vieux de dix ans en croisant les doigts. 🐳
J’ai demandé à ChatGPT la liste des checks et métriques les plus importants à surveiller sur Graylog – taux d’occupation du journal, santé du cluster d’indexation, état des inputs, débit, santé des nœuds, ce genre de choses. La vraie mission confiée à Claude était ensuite : implémenter les checks, tester les vrais appels d’API contre une instance en fonctionnement et corriger/valider le parsing JSON par rapport à ce que Graylog renvoie réellement, et non à ce qu’affirme une documentation vieille de trois versions majeures.
🧠 Là où les connaissances d’entraînement ont atteint leurs limites
Claude avait déjà une bonne dose de connaissances sur l’API REST de Graylog, acquises à l’entraînement – noms des endpoints, structure générale. Une partie tenait la route. Une autre pas du tout : quelques noms de champs JSON supposés n’existent tout simplement plus, et au moins un endpoint (un check d’état pour load balancer qui signale son état via le code de statut HTTP brut plutôt que via un corps JSON, parce que pourquoi faire simple) était discrètement faux dès le premier jour. Deviner de mémoire ne mène pas bien loin face à une API qui a eu trois ans pour dériver. 🎯
Ce qui a vraiment comblé l’écart : j’ai fourni à Claude un export OpenAPI complet tiré directement de ma propre instance Graylog. Il a ainsi pu vérifier chaque endpoint et chaque nom de champ supposés par rapport à la spécification réelle et actuelle – et comme je l’avais aussi laissé construire l’environnement de test Docker, il a pu aller encore plus loin et exécuter réellement les appels au lieu de se contenter de lire leur description, en simple touriste de l’API. Les deux vrais bugs trouvés de cette façon ne sont apparus qu’à l’exécution, pas à la lecture de la documentation. 🐛➡️✅
Rebondissement bonus : en cours de route, j’ai remarqué que tout le banc de test tournait discrètement sur Graylog 6.1, alors que la spécification OpenAPI que j’avais fournie concernait la 7.1.3. Le grand classique du « ça marche sur ma (mauvaise) machine ». Repéré en pleine relecture, environnement reconstruit avec la bonne version, et Claude prié de relancer toute la suite de tests de bout en bout, par pure paranoïa. Bonne nouvelle : les deux bugs trouvés étaient identiques sur les deux versions – rien de spécifique à une version, juste des hypothèses fausses depuis le début. Mieux vaut quand même avouer la confusion que faire comme si elle n’avait jamais eu lieu. 🙈
✅ Le résultat
Il en est sorti deux implémentations de checks séparées et vraiment natives – et non une seule rafistolée au chatterton autour de l’autre en considérant l’affaire réglée. Icinga2 reçoit un plugin classique façon Nagios (codes de sortie, OK/WARNING/CRITICAL, perfdata, la totale). Zabbix reçoit au contraire sa propre version idiomatique, où chaque check remonte une valeur brute et où les seuils proprement dits vivent dans des triggers Zabbix – parce que c’est ainsi que Zabbix veut être nourri, et non parce que le mode natif était l’option de facilité (ce n’était vraiment pas le cas – demandez-moi un jour ce que c’est que de parser le format JSON du Low-Level Discovery de Zabbix). Les deux ont aussi été testés contre une instance Icinga2/Zabbix réelle en fonctionnement, pas seulement contre Graylog isolément – y compris en regardant un vrai trigger Zabbix basculer pile au bon moment en état « problème », ce qui m’a procuré une satisfaction déraisonnable pour un samedi. 📡
Tout – plugins, instructions d’installation et documentation complète – est public :
github.com/aptupgrademe/graylog-checks
Si vous êtes coincé à superviser Graylog avec un script Nagios vieux de dix ans tiré d’un dépôt GitHub quelconque, j’espère que ceci vous épargnera les fouilles archéologiques. 🏺
