Logs, Metriken und Traces: welches Signal welche Frage beantwortet

Worum es geht

Beobachtbarkeit (Observability) ruht auf drei Signalarten, die OpenTelemetry einheitlich definiert. Ein Log ist ein zeitgestempelter Datensatz über ein Ereignis mit beliebigen Feldern; das Datenmodell von OpenTelemetry sieht darin unter anderem die Felder TraceId und SpanId vor, damit ein Logeintrag der Anfrage zugeordnet werden kann, in der er entstand. Eine Metrik ist eine numerische Zeitreihe; die Dokumentation unterscheidet Instrumente wie Counter (steigt nur, wie ein Kilometerzähler), UpDownCounter (steigt und fällt, etwa eine Warteschlangenlänge), Gauge (aktueller Wert beim Ablesen) und Histogram (Verteilung, etwa von Antwortzeiten). Ein Trace stellt eine Anfrage als Baum von Spans dar – jeder mit Start, Dauer, Attributen und Elternspan –, und die Context Propagation trägt die Trace-Kennung über Header an nachgelagerte Dienste weiter.

Warum es wichtig ist

Jedes Signal beantwortet eine andere Frage, und keines ersetzt die anderen. Metriken sind billig zu speichern und abzufragen und taugen für Alarme: «Fehlerrate über zwei Prozent seit fünf Minuten.» Sie sagen aber nicht, welche Anfrage betroffen war. Traces zeigen für eine Anfrage, wo die Zeit blieb – die Datenbank, ein externer Dienst, ein serieller Aufruf, der parallel sein könnte. Logs enthalten den Wortlaut des Fehlers und die Werte, die dazu führten. Erst die gemeinsame Kennung macht aus drei Werkzeugen eine Untersuchung: vom Alarm zur Beispielanfrage zum Logeintrag.

So wird es angewendet

• Mit der Frage beginnen, nicht mit dem Werkzeug: Für «ist der Dienst gesund?» reichen wenige Metriken (Anfragen, Fehler, Dauer, Sättigung); für «warum ist diese Anfrage langsam?» braucht es Traces; für «was stand in der Eingabe?» Logs.
• Zuerst die Grenzen instrumentieren – eingehende HTTP-Anfragen, ausgehende Aufrufe, Datenbankzugriffe; Bibliotheken liefern das meist automatisch.
• Metrik-Labels auf wenige Werte begrenzen (Endpunkt, Statusklasse), nie Nutzer- oder Objektkennungen: Jede Kombination ist eine eigene Zeitreihe.
• Die Trace-Kennung in jeden Logdatensatz schreiben und an nachgelagerte Dienste weitergeben; ohne Weitergabe endet der Trace an der ersten Dienstgrenze.
• Traces bei hohem Aufkommen stichprobenartig aufbewahren: Wird am Anfang entschieden, ist die Stichprobe billig; wird nach Abschluss entschieden, lassen sich fehlerhafte und langsame Anfragen vollständig behalten.
• Aufbewahrung je Signal festlegen: Metriken lange und verdichtet, Logs kürzer, Traces am kürzesten.

Stolpersteine

Logs mit hoher Frequenz als Ersatz für Metriken («jede Anfrage eine Zeile, dann zählen wir») skalieren nicht und kosten bei jeder Abfrage. Ein Histogramm, das nur Mittelwerte exportiert, verliert die Ausreisser, die Nutzerinnen spüren. Traces ohne Attribute (Statuscode, Zeilenzahl, Cache-Treffer) beantworten nur das «wo», nicht das «warum». Alles zu sammeln, ohne eine Frage zu haben, erzeugt Kosten, keine Erkenntnis.