🌐 Auch auf: English · Français · Español
🔍 Manchmal beginnt ein Nebenprojekt mit einem Problem aus dem Job, nicht aus dem Homelab. So auch hier: Beruflich kämpfe ich gerade mit Graylog als Log-Management-Plattform und brauchte vernünftige Monitoring-Check-Plugins dafür – sowohl für Icinga2 als auch für Zabbix. Das hat doch sicher schon jemand gelöst, oder? Oder?? 😅
📉 Der ernüchternde Teil: Google und GitHub durchsuchen
Mein erster Schritt war der naheliegende: jemanden finden, der das schon gebaut hat – denn das Rad neu erfinden ist was für Leute mit zu viel Freizeit. Die Ergebnisse waren, freundlich formuliert, mau. Was es gab, war entweder extrem minimalistisch (ein hartcodierter Check, null Schwellwerte, das Monitoring-Gegenstück zu einem Rauchmelder ohne Batterie) oder schlicht uralt – manche Repos hatten bis zu zehn Jahre keinen Commit mehr gesehen. Die REST-API von Graylog hat sich ordentlich verändert, seit diese Plugins zuletzt von Menschenhand berührt wurden. Nicht gerade ein vertrauenerweckendes Fundament fürs Monitoring. 🦕
💡 Die leicht durchgeknallte Idee
Also hatte ich, was ich großzügig eine „glorreiche Idee“ nenne: Claude soll Graylog, Icinga2 und Zabbix per Docker Compose auf meinem eigenen Server hochziehen und die Check-Plugins einfach … von Grund auf neu bauen – und alles live gegen eine echte, laufende Instanz testen, statt aus einem zehn Jahre alten Blogbeitrag abzuschreiben und auf das Beste zu hoffen. 🐳
ChatGPT habe ich nach einer Liste der wichtigsten Checks und Metriken gefragt, die man bei Graylog überwachen sollte – Journal-Auslastung, Zustand des Indexer-Clusters, Status der Inputs, Durchsatz, Node-Zustand und so weiter. Der eigentliche Auftrag an Claude lautete dann: die Checks implementieren, die echten API-Aufrufe gegen eine laufende Instanz testen und das JSON-Parsing an dem korrigieren und validieren, was Graylog tatsächlich zurückgibt – nicht an dem, was eine Doku von vor drei Major-Versionen behauptet.
🧠 Wo das antrainierte Wissen aufhörte
Claude brachte aus dem Training schon einiges Wissen über die REST-API von Graylog mit – Endpunktnamen, die grobe Struktur. Manches davon hielt stand. Manches ganz und gar nicht: Ein paar angenommene JSON-Feldnamen gibt es schlicht nicht mehr, und mindestens ein Endpunkt (ein Loadbalancer-Statuscheck, der seinen Zustand über den rohen HTTP-Statuscode statt über einen JSON-Body meldet – warum sollte man es auch einfach machen) war von Anfang an stillschweigend falsch umgesetzt. Raten aus dem Gedächtnis bringt einen eben nur so weit – erst recht bei einer API, die drei Jahre Zeit hatte, davonzudriften. 🎯
Was die Lücke wirklich geschlossen hat: Ich habe Claude einen vollständigen OpenAPI-Export direkt aus meiner eigenen Graylog-Instanz gegeben. Damit konnte es jeden angenommenen Endpunkt und jeden Feldnamen mit der echten, aktuellen Spezifikation abgleichen – und weil ich es ja auch die Docker-Testumgebung hatte bauen lassen, konnte es noch einen Schritt weiter gehen und die Aufrufe tatsächlich ausführen, statt nur darüber zu lesen wie eine Art API-Tourist. Beide echten Bugs, die es so gefunden hat, zeigten sich erst zur Laufzeit, nicht beim Lesen der Doku. 🐛➡️✅
Bonus-Plot-Twist: Mittendrin fiel mir auf, dass der ganze Testaufbau stillschweigend gegen Graylog 6.1 lief, während die OpenAPI-Spezifikation, die ich übergeben hatte, für 7.1.3 war. Ein klassischer „Auf meiner (falschen) Maschine läuft’s“-Moment. Beim Review bemerkt, die Umgebung mit der richtigen Version neu aufbauen lassen und Claude aus purer Paranoia die komplette Testsuite noch einmal von vorne bis hinten durchlaufen lassen. Die gute Nachricht: Beide gefundenen Bugs waren in beiden Versionen identisch – nichts Versionsspezifisches, einfach von Anfang an falsche Annahmen. Trotzdem gebe ich die Verwechslung lieber zu, als still so zu tun, als wäre sie nie passiert. 🙈
✅ Das Ergebnis
Herausgekommen sind zwei getrennte, sauber native Check-Implementierungen – nicht eine, die mit Panzertape um die andere gewickelt wurde, und fertig. Icinga2 bekommt ein klassisches Plugin im Nagios-Stil (Exit-Codes, OK/WARNING/CRITICAL, Perfdata, das volle Programm). Zabbix bekommt dagegen eine eigene, idiomatische Version, bei der jeder Check einen Rohwert liefert und die eigentlichen Schwellwerte in Zabbix-Triggern liegen – weil Zabbix so gefüttert werden will, und nicht, weil der native Weg der bequeme war (das war er ganz und gar nicht – frag mich mal bei Gelegenheit nach dem Parsen von Zabbix‘ Low-Level-Discovery-JSON). Beide wurden auch gegen eine laufende Icinga2- bzw. Zabbix-Instanz getestet, nicht nur isoliert gegen Graylog – inklusive eines echten Zabbix-Triggers, der auf Kommando in den Zustand „Problem“ kippte, was für einen Samstag unangemessen viel Befriedigung ausgelöst hat. 📡
Alles – Plugins, Installationsanleitung und vollständige Dokumentation – ist öffentlich:
github.com/aptupgrademe/graylog-checks
Falls du Graylog gerade mit einem zehn Jahre alten Nagios-Skript aus irgendeinem GitHub-Repo überwachst: Hoffentlich erspart dir das hier die Archäologie. 🏺
