Logging ist kaputt

(loggingsucks.com)

37 Punkte von GN⁺ 2025-12-22 | Noch keine Kommentare. | Auf WhatsApp teilen

In modernen verteilten Systemen haben herkömmliche Logging-Ansätze eine strukturelle Grenze darin, die Wahrheit abzubilden
Logs sind weiterhin auf die Single-Server-Umgebung von 2005 ausgelegt und verlieren dadurch den Kontext von Requests, die über mehrere Services, Datenbanken und Caches laufen
Einfache Stringsuche versteht Struktur, Beziehungen und Korrelationen nicht und erschwert so die Ursachenanalyse
Die Lösung besteht darin, pro Request ein einzelnes „Wide Event“ (oder „Canonical Log Line“) mit dem gesamten Kontext zu hinterlassen
Dadurch werden Logs von reinem Text zu einem analysierbaren Datenbestand

Das grundlegende Problem von Logging

Bestehende Logs wurden unter der Annahme des monolithischen Server-Zeitalters entwickelt und spiegeln die heutige verteilte Service-Architektur nicht wider
- Ein einzelner Request durchläuft mehrere Services, DBs, Caches und Queues, doch Logs werden weiterhin aus Sicht eines einzelnen Servers geschrieben
Im Beispiel entstehen pro Request 13 Zeilen; bei 10.000 gleichzeitigen Nutzern sind das 130.000 Zeilen pro Sekunde, von denen die meisten bedeutungslos sind
Was man bei einem Problem braucht, ist Kontext, doch genau der fehlt in heutigen Logs

Wenn ein Nutzer meldet: „Die Zahlung funktioniert nicht“, ist es selbst bei einer Suche nach E-Mail oder user_id wegen der fehlenden einheitlichen Struktur schwer, brauchbare Ergebnisse zu bekommen
- Dieselbe Benutzer-ID wird in zig verschiedenen Formen protokolliert, etwa als user-123, user_id=user-123 oder {"userId":"user-123"}
Unterschiedliche Log-Formate zwischen Services machen das Nachverfolgen zusammenhängender Events unmöglich
Das Kernproblem ist, dass Logs auf das Schreiben (write) ausgelegt sind und nicht für Abfragen (query) optimiert wurden

Structured Logging: Protokollierung als Key-Value-Format (JSON) statt als String
Cardinality: Anzahl eindeutiger Werte eines Felds; bei user_id zum Beispiel sehr hoch
Dimensionality: Anzahl der Felder in einem Log-Event; je mehr Felder, desto größer die Analysemöglichkeiten
Wide Event / Canonical Log Line: Ein einzelnes Log-Event mit reichhaltigem Kontext pro Request
Die meisten Logging-Systeme begrenzen Daten mit hoher Kardinalität aus Kostengründen, obwohl sie in der Praxis für Debugging am nützlichsten sind

OpenTelemetry (OTel) ist ein Protokoll- und SDK-Set, das nur einen Standard für Datenerfassung und -übertragung bereitstellt
OTel übernimmt jedoch Folgendes nicht
1. Es entscheidet nicht, was geloggt werden soll
2. Es fügt keinen Business-Kontext (z. B. Abo-Stufe oder Warenkorbwert) automatisch hinzu
3. Es verändert nicht die Denkweise von Entwicklern beim Logging
Selbst bei Verwendung derselben Bibliothek unterscheidet sich die Debugging-Erfahrung drastisch zwischen bewusst mit Kontext angereicherter Instrumentierung und einfacher Instrumentierung
OTel ist lediglich die Transportleitung (plumbing), und was hindurchfließt, müssen Entwickler selbst festlegen

Statt Logging danach auszurichten, „was der Code tut“, sollte man erfassen, „was mit dem Request passiert ist“
Für jeden Request wird pro Service ein einzelnes umfangreiches Event erzeugt
- Es kann mehr als 50 Felder enthalten, darunter Request-, Nutzer-, Zahlungs-, Fehler- und Umgebungsinformationen
Das Beispiel-JSON enthält user_id, subscription_tier, service_version, error_code und damit den vollständigen Debugging-Kontext
So lässt sich mit einer einzigen Suche sofort analysieren, warum Zahlungen von Premium-Nutzern fehlschlagen

Wide Events werden nicht per einfacher Textsuche behandelt, sondern über strukturierte Datenabfragen
Auf Basis hochkardinaler und hochdimensionaler Daten wird Debugging auf dem Niveau von Echtzeitanalysen möglich
Beispiel: Eine Query wie „Aggregiere die Fehlerrate bei Zahlungen von Premium-Nutzern der letzten Stunde nach Fehlercode“ lässt sich sofort ausführen

Das Event wird über den gesamten Lebenszyklus eines Requests hinweg aufgebaut und am Ende genau einmal ausgegeben
- In der Middleware werden Basisfelder wie request_id, timestamp, method und path initialisiert
- Im Handler werden Nutzer-, Warenkorb-, Zahlungs- und Fehlerinformationen schrittweise ergänzt
Am Ende wird mit logger.info(event) ein einzelnes JSON-Event protokolliert

Wenn pro Request 50 oder mehr Felder geloggt werden, steigen die Kosten stark an, daher ist Sampling nötig
Einfaches zufälliges Sampling birgt das Risiko, Fehler zu übersehen
Vorgeschlagen wird eine Tail-Sampling-Strategie
1. Fehler (z. B. 500er) werden immer gespeichert
2. Langsame Requests (ab p99) werden immer gespeichert
3. Sitzungen von VIP-Nutzern oder mit bestimmten Flags werden immer gespeichert
4. Der Rest wird nur zu 1–5 % zufällig gesampelt
So lassen sich Kosten senken und zugleich kritische Events erhalten

Structured Logging ≠ Wide Event: Ein JSON-Format allein reicht nicht aus, entscheidend ist der Kontext
OpenTelemetry im Einsatz ≠ vollständige Observability: Standardisiert wird nur die Erfassung, was aufgezeichnet wird, bleibt Aufgabe der Entwickler
Nicht dasselbe wie Tracing: Tracing zeigt den Ablauf zwischen Services, Wide Events liefern Kontext innerhalb eines Services
Die Trennung „Logs für Debugging, Metriken für Dashboards“ ist unnötig — Wide Events decken beide Anwendungsfälle ab
Die Annahme, hochgradig kardinale Daten seien teuer, ist veraltet; moderne Datenbanken wie ClickHouse oder BigQuery verarbeiten sie effizient

Debugging wandelt sich von Archäologie zu Analytics
Statt zur Suche nach „fehlgeschlagener Nutzerzahlung“ die Logs von 50 Services mit grep zu durchsuchen,
entsteht ein analysegetriebener Ansatz auf Basis einer einzigen Query, etwa: „Zeige die Fehlerrate von Zahlungen bei Premium-Nutzern nach Fehlercode“
Das Ergebnis: Logs werden von einem Werkzeug, das die Unwahrheit sagt, zu einem Datenbestand, der die Wahrheit liefert