
Foto von Trac Vu auf Unsplash
Ich habe aufgehört, Logs zu durchwühlen
M. Zakyuddin Munziri
@zakiego
Ursprünglich auf English geschrieben.
Lange Zeit bedeutete Debugging, zuerst Logs zu öffnen. Das fühlte sich wie das Richtige an. Alarme gingen los, Logs waren da, also las ich sie. Mit der Zeit wurde mir klar, dass ich die meiste Energie nicht damit verbrachte, Bugs zu beheben. Ich verbrachte sie mit Suchen.
Also habe ich aufgehört, Logs zu durchwühlen.
Jetzt beginne ich beim Fehler selbst, sende ihn an einen KI-Agenten, der unsere Observability-Datenbank lesen kann, und lasse ihn suchen. Der Unterschied ist nicht subtil. Die Ursache (Root Cause) zeigt sich schneller. Weniger Sackgassen. Weniger Stress.
Hier geht es nicht um magische KI. Es geht darum, den Startpunkt des Debuggings zu ändern.
Das Problem: Logs sind Fragmente, nicht die Geschichte
Logs sind Fragmente. Eine Zeile hier. Ein Stacktrace dort. Ein Zeitstempel, der fast zu einem anderen passt.
Observability-Tools geben Sichtbarkeit, aber sie geben standardmäßig keine Struktur. Ingenieure müssen immer noch alles in ihren Köpfen zusammenfügen. Dieses Zusammenfügen ist teuer.
Der alte Ablauf sah so aus:
- ein Alarm geht los
- Logs öffnen
- nach Request-ID suchen
- zwischen Services springen
- Code öffnen
- eine Hypothese bilden
- wiederholen
Die meiste Zeit fließt in die Navigation, nicht ins Nachdenken. Debugging wird zu einem Aufmerksamkeitsproblem.
Der Wechsel: Hör auf zu lesen, fang an zu korrelieren
Anstatt mit Logs zu beginnen, beginne ich jetzt mit dem Fehler.
Wenn ein Fehler auftritt, sende ich den Fehler-Payload plus minimalen Kontext an einen KI-Assistenten. Dieser Assistent hat Lesezugriff auf unsere Observability-Datenbank. Logs, Traces und historische Fehlerdaten sind alle dort.
Der Job der KI ist einfach. Korreliere alles, was mit diesem Fehler zusammenhängen könnte.
Mein Job bleibt derselbe. Entscheiden, was als nächstes zu tun ist.
Diese eine Änderung entfernt viel Lärm. Ich scrolle nicht mehr durch Logs in der Hoffnung, dass etwas auffällt. Ich überprüfe Beweise, die bereits gruppiert und verbunden sind.
Was die KI tatsächlich tut
Es ist keine Magie im Spiel. Die Schritte sind mechanisch.
Zuerst parst die KI den Fehler-Payload und extrahiert Schlüsselfelder wie Zeitstempel, Service-Name, Fehlertyp und Request-Identifikatoren.
Als Nächstes fragt sie die Observability-Datenbank nach ähnlichen Fehlern ab. Gleiche Signatur, gleicher Service, ähnliche Payloads, nahe Zeitfenster.
Dann korreliert sie Traces über Services hinweg, um zu sehen, wo Ausfälle sich häufen. Sie sucht nach wiederholten Pfaden, nicht nach einmaligem Lärm.
Danach prüft sie kürzliche Deploys oder Commits, die die betroffenen Codepfade berührt haben.
Der Output ist ein kurzer Bericht mit Beweisen. Traces, die sich wiederholen. Logs, die zusammenpassen. Codepfade, die sich kürzlich geändert haben.
Das gibt mir nicht den Fix. Es gibt mir den richtigen Ort zum Suchen.
Leitplanken: Zugriff ohne Bloßstellung
Dieser Teil ist wichtiger als die KI selbst.
Die KI hat nur Lesezugriff. Kein Schreiben. Keine Mutationen. Keine Nebenwirkungen.
Der Privatsphäre-Modus ist aktiviert. Daten werden nicht für das Training verwendet. Sie werden nur für die Inferenz in dieser Sitzung verwendet.
Der Zugriff ist beschränkt (scoped). Nur die für das Debugging benötigten Felder werden offengelegt. Kein breiter Datenbankzugriff. Keine unnötigen Payloads.
Jede Abfrage und jedes Ergebnis ist auditierbar.
Das Ziel ist nicht, der KI mehr Macht zu geben. Das Ziel ist es, ihr genug Kontext zu geben, um nützlich zu sein, ohne neues Risiko zu schaffen.
Was sich für mich geändert hat
Ein paar Dinge wurden nach dem Wechsel des Workflows sehr offensichtlich.
Die Zeit bis zur Ursache fiel signifikant. Wir überspringen die Phase des Herumirrens.
Pull Requests wurden kleiner und fokussierter. Fixes zielen auf das eigentliche Problem statt auf Vermutungen drumherum.
Falsche Untersuchungen gingen zurück. Weniger Situationen, in denen Stunden verbracht werden, nur um festzustellen, dass es nicht zusammenhängt.
Alarme fühlen sich ruhiger an. Wenn etwas kaputt geht, ist der erste Schritt strukturiert, nicht reaktiv.
Was sich nicht geändert hat
Ingenieure treffen immer noch die Entscheidungen.
Die KI versteht den Produktkontext nicht. Sie kennt keine Geschäftsprioritäten oder Rollout-Strategien.
Urteilsvermögen ist immer noch erforderlich. Wie riskant der Fix ist. Ob zurückgerollt werden soll. Ob ein Hotfix nötig ist oder gewartet werden kann.
KI verengt den Suchraum. Menschen besitzen immer noch das Ergebnis.
Ein Workflow, den Sie kopieren können
- Ein Alarm geht los
- Erfassen Sie den Fehler-Payload und minimalen Kontext
- Senden Sie ihn an einen KI-Assistenten mit beschränktem Lesezugriff
- Überprüfen Sie die Beweise, die er zurückgibt
- Validieren Sie die Hypothese
- Implementieren Sie den Fix
- Beobachten Sie
Kein blindes Log-Tauchen.
Wo das als nächstes hingehen könnte
Eine Idee, die ich im Hinterkopf behalte, ist, diesen Workflow einen Schritt weiter zu treiben.
Wenn ein Alarm losgeht, könnte ein Agent automatisch die Beweise sammeln, den Fehler über Services hinweg verfolgen, die relevanten Codepfade inspizieren und einen Fix vorschlagen.
Nicht um ihn selbst zu mergen. Nur um einen Pull Request zu öffnen.
Der Pull Request würde enthalten:
- die vermutete Ursache
- die unterstützenden Traces und Logs
- die Codeänderung
- die Tests, die den Fix rechtfertigen
An diesem Punkt gräbt oder tippt der Ingenieur standardmäßig nicht mehr. Der Job wird zum Reviewen, Risiko beurteilen und Entscheiden, ob die Änderung ausgeliefert werden soll.
Das ist ein Workflow, den ich tatsächlich warten möchte.
Schlusswort: Warum das tatsächlich wichtig ist
Es geht nicht darum, Ingenieure zu ersetzen. Es geht darum, unnötige Arbeit zu entfernen.
Logs sind Rohmaterial. Sie sind nicht die Antwort. Geschwindigkeit kommt vom schnellen Zusammenfügen von Kontext, nicht vom schnelleren Lesen.
Wenn Sie Systeme im großen Maßstab betreiben und immer noch mit dem Öffnen von Logs debuggen, versuchen Sie, die Reihenfolge umzudrehen. Starten Sie mit dem Fehler. Lassen Sie Maschinen suchen. Nutzen Sie Ihre Aufmerksamkeit dort, wo sie tatsächlich zählt.


