Observability

Das Problem

Logs zentral zu sammeln ist der einfache Teil. Danach steht man vor einem Strom, in dem derselbe Fehler tausendfach auftaucht und ein neuer untergeht. Wer daraus Tickets macht, macht sie von Hand und hört irgendwann auf. Wer es lässt, hat eine Suchmaske statt einer Übersicht.

Wie es das löst

Observability fragt Graylog nach einem Zeitplan ab, fasst Log-Ereignisse zu Vorfällen zusammen und aggregiert deren Schweregrad. Diese Cluster hält sie beidseitig mit GitLab-Issues im Gleichstand, unter einem Label-Lebenszyklus, der für alle Projekte derselbe ist. Ein React-SPA zeigt Übersicht, Kennzahlen, Verlauf und die Liste dessen, was Handeln verlangt.

Was es kann

Ein Zeitplan statt eines Dashboards, in das man schauen muss. Alle eingerichteten Anwendungen werden alle fünf Minuten abgefragt, die Tageszusammenfassung geht um 08:00 Uhr Europe/Zurich raus, um 08:10 Uhr schliessen stille Cluster von selbst.

Sieben verbindliche Label-Zuordnungen pro GitLab-Verbindung. Typ, offen und geschlossen, Priorität P0 bis P3. Integrationen dürfen projektspezifische Labels ergänzen, aber type::, priority:: und status:: sind zentral geführt. Aktualisiert wird als Delta, damit fremde Labels erhalten bleiben; das ungescopte blocked fasst der Abgleich nie an.

Eine Vorprüfung, die keine Schatten-Labels anlegen kann. Sie lädt alle für das Zielprojekt sichtbaren Labels, einschliesslich der vererbten Gruppenlabels, und prüft alle sieben Zuordnungen. Fehlt eines oder ist GitLab nicht erreichbar, bricht der schreibende Aufruf in der Vorprüfung ab.

Ausgehende Aufrufe nur in Produktion. Verkehr zu Graylog und GitLab verlangt eine Produktionsumgebung und einen exakt gesetzten Schalter. Die Prüfung sitzt an beiden Faraday-Grenzen, damit ein kopiertes Produktionstoken sie nicht umgeht. Der Trockenlauf einer Integration ist pro Durchlauf bindend und lässt sich durch keine globale Variable aushebeln.

Nachlauf über Zeitfenster, standardmässig trocken. Ein historischer Nachlauf arbeitet in Fünf-Minuten-Eimern und erzeugt zunächst nur Cluster, Beobachtungen und Issue-Vorschauen. Der echte Abgleich verlangt ein ausdrückliches viertes Argument.

Was es nicht tut

Es sammelt keine Logs. Graylog bleibt die Quelle; Observability ist die Triage darüber.

Es kennt keine Konfigurationsdateien und keine Tokens aus Umgebungsvariablen. Einzige Quelle sind die Datensätze für Integration, Graylog- und GitLab-Verbindung, mit ActiveRecord-verschlüsselten Tokens, die nie an den Client zurückgehen.

Es läuft heute als internes Produktionssystem bei uns selbst und hat keine externen Nutzer.