Die Woche in Kürze: zwei Commits in zwei Repositories, und in einem davon steckt mehr, als man auf den ersten Blick vermutet. Das Repository einer kleinen statischen Website hat wieder seine Datenaktualisierung bekommen, pünktlich und unspektakulär, wie erwartet. Lieber schreibe ich aber über den kleinen, feinen Eingriff in alertmanager-talk-bridge. Ein Commit, der einen echten Unterschied macht.
Wiederholungsversuche: wenn ein Alert einfach nicht ankommt
alertmanager-talk-bridge ist eine schlanke Brücke in Python zwischen Prometheus Alertmanager und Nextcloud Talk. Die Idee ist einfach. Löst Alertmanager einen Alert aus, weil ein Pod abstürzt, ein Node nicht erreichbar ist oder die Festplatte vollläuft, leitet die Bridge die Nachricht per Webhook in einen Nextcloud-Talk-Raum weiter. Kein zusätzliches Slack-Abo, kein PagerDuty, nur das eigene Nextcloud, das ohnehin schon läuft.
Bis zu dieser Korrektur gab es ein Problem: Die Bridge versuchte es genau einmal. Hatte Nextcloud Talk gerade einen schlechten Moment, etwa durch einen kurzen Neustart oder einen Aussetzer im Netzwerk, verschwand der Alert lautlos. Alertmanager hatte gesendet, die Bridge hatte empfangen, Nextcloud hatte nicht geantwortet, und niemand hat es bemerkt.
Bei Monitoring-Werkzeugen ist das besonders heikel. Ein Alert, der nicht ankommt, ist genauso gefährlich wie gar keiner. Man verlässt sich auf sein System, und das System schweigt, obwohl es längst brennt.
Die Korrektur dieser Woche ändert das Verhalten grundlegend. Die Bridge wiederholt fehlgeschlagene Zustellungen an Talk jetzt automatisch, und zwar mit exponentiellem Backoff und einigen Versuchen, bevor sie aufgibt. Der Haupt-Thread wird dabei nicht blockiert, und kein Fehler rutscht mehr unbemerkt durch. Der Eingriff in den Zustellungscode war überschaubar, vielleicht hundert Zeilen samt Tests. Erst er macht aber das Zuverlässigkeitsversprechen des ganzen Werkzeugs glaubwürdig.
Ich würde lügen, wenn ich behauptete, das von Anfang an eingeplant zu haben. Das Grundgerüst stand schnell, weil der Normalfall wirklich einfach ist: Webhook kommt herein, HTTP-POST geht hinaus. Wiederholungslogik ist aber immer der zweite Schritt, den man beim Schreiben überspringt und im Betrieb bereut. Diesmal habe ich ihn nachgeholt, bevor es jemandem im Produktiveinsatz aufgefallen wäre.
Der andere Commit: nichts Neues, und das ist gut so
Der zweite Commit der Woche: frische Daten für eine kleine statische Website, derselbe Handgriff wie letzte Woche und die Woche davor. Die Astro-Site holt beim Build externe Feed-Daten aus einer API und baut sie statisch ein. So gibt es keine Live-Anfragen im Browser und kein externes Skript, das die Ladezeit auffrisst. In regelmäßigen Abständen hole ich neue Daten, committe und deploye. Zwei Minuten Arbeit. Die Website läuft, ich muss nichts weiter anfassen.
Spannendes Engineering ist das nicht. Aber genau dafür habe ich sie gebaut: als System, das nach dem Start keinen ständigen Pflegeaufwand verursacht.
Wenn Sie über eine eigene Lösung für internes Monitoring oder Alarmierung in Ihrer Infrastruktur nachdenken und nicht wissen, ob sich ein eigenes Werkzeug für Ihren Kubernetes-Stack lohnt, sehen Sie sich gern meine Leistungsseite an. Manchmal ist der fehlende Baustein kleiner als gedacht.
Den Quellcode von alertmanager-talk-bridge finden Sie auf GitHub.