Tracing: Was es ist, Prinzipien und Datenerfassung

Was ist Tracing in der Überwachung

Tracing ist eine Methode der verteilten Beobachtung, bei der jede eingehende Anfrage durch alle Dienste und Komponenten des Systems verfolgt wird. Im Gegensatz zu Metriken, die aggregierte Werte anzeigen (durchschnittliche Antwortzeit, Fehleranzahl), bewahrt Tracing den vollständigen Kontext einer einzelnen spezifischen Anfrage.

Jeder Verarbeitungsschritt — ein Datenbankaufruf, eine HTTP-Anfrage an einen anderen Mikrodienst, die Ausführung einer Hintergrundaufgabe — wird als separate Einheit mit Zeitstempel, Status und Attributen erfasst. Laut Google Dapper (ursprüngliche Veröffentlichung 2010) ermöglicht Tracing die Lokalisierung von Verzögerungen in verteilten Systemen mit der Genauigkeit eines einzelnen Aufrufs.

Tracing ist besonders wichtig für mobile Anwendungen, bei denen das Backend aus Dutzenden von Mikrodiensten besteht. Eine Benutzeraktion — wie das Einloggen in ein Konto — kann über ein API-Gateway, einen Authentifizierungsdienst, eine Datenbank und einen Push-Dienst laufen. Ohne Tracing ist es nahezu unmöglich zu bestimmen, welche Komponente die Antwort verlangsamt.

Spans und Traces: grundlegende Datenstruktur

Die grundlegende Einheit des Tracings ist ein Span. Jeder Span repräsentiert eine logische Operation: eine HTTP-Anfrage, eine SQL-Abfrage, einen gRPC-Aufruf, eine JSON-Serialisierung. Ein Span enthält eine eindeutige ID, eine Eltern-ID, den Operationsnamen, Startzeit, Dauer, Status und eine Reihe von Attributen.

Span-Hierarchie in einem Trace

Alle Spans, die zu einer einzelnen Stamm-Anfrage gehören, werden zu einem Trace gruppiert. Der Root-Span repräsentiert den Einstiegspunkt — eine HTTP-Anfrage vom mobilen Client zur API. Kind-Spans bilden einen Baum, wobei jeder Span über das Feld parent_span_id auf seinen Eltern verweist.

Die Dauer eines Traces entspricht der Summe der Dauern der eindeutigen Zeitsegmente aller Spans. Wenn zwei Kind-Spans parallel ausgeführt werden, wird ihre Zeit nicht summiert — dies ist entscheidend für die korrekte Analyse von Verzögerungen, die durch parallele Mikrodienstaufrufe verursacht werden.

Span-Attribute und Ereignisse

Jeder Span kann Attribute enthalten — Schlüssel-Wert-Paare mit Metainformationen: Anfrage-URL, Benutzer-ID, API-Version, Hostname. Attribute werden zum Filtern und Gruppieren von Traces verwendet. Neben Attributen unterstützen Spans Ereignisse — Zeitstempel mit Textbeschreibungen wie „Cache-Fehler“ oder „Verbindungswiederholung“.

Wie Distributed Tracing funktioniert

Distributed Tracing löst das Problem der Verknüpfung von Spans, die in verschiedenen Prozessen und auf verschiedenen Maschinen erstellt werden. Der Mechanismus basiert auf der Kontextweitergabe: Wenn Dienst A Dienst B aufruft, wird der ausgehenden Anfrage ein Header mit der aktuellen Trace-ID und der Eltern-Span-ID hinzugefügt.

Standardprotokolle für die Kontextweitergabe sind W3C Trace Context (traceparent- und tracestate-Header) und Zipkin B3 (X-B3-TraceId-, X-B3-SpanId-Header). W3C Trace Context wurde 2021 vom W3C-Konsortium als Standard verabschiedet und von allen großen Telemetrieanbietern unterstützt.

Beim Empfang der Anfrage extrahiert Dienst B die trace_id aus dem Header und erstellt einen Kind-Span mit dieser trace_id. Nach Abschluss der Anfrage werden so alle Spans aus verschiedenen Diensten auf der Kollektorseite zu einem einzigen Trace zusammengeführt. Dies erfordert, dass jeder Dienst mit derselben Tracing-Bibliothek instrumentiert ist.

Kontextweitergabe in Mikrodiensten

In der mobilen Entwicklung umfasst die Kontextweitergabe nicht nur das Backend, sondern auch die Client-Server-Interaktion. Eine mobile Anwendung kann in jedem API-Request einen trace_id im Header senden, wodurch eine Client-Aktion mit der Serververarbeitung verknüpft werden kann. Das OpenTelemetry SDK für iOS und Android unterstützt die automatische Erstellung und Weitergabe des Trace-Kontexts über HTTP-Clients.

import io.opentelemetry.api.trace.Span
import io.opentelemetry.api.trace.Tracer
import io.opentelemetry.context.Context

class TracingInterceptor : Interceptor {
    private val tracer: Tracer = OpenTelemetry.getTracer("mobile-app")

    override fun intercept(chain: Interceptor.Chain): Response {
        val span = tracer.spanBuilder("HTTP POST /api/login")
            .setParent(Context.current())
            .startSpan()

        return chain.proceed(chain.request())
            .also { span.end() }
    }
}

Der vorgestellte Kotlin-Interceptor erstellt für jede HTTP-Anfrage an den Server einen Span. Der Elternkontext wird vom aufrufenden Code über Context.current() weitergegeben, was eine Verknüpfung des clientseitigen Tracings mit dem serverseitigen Tracing ermöglicht.

Implementierung von Tracing mit OpenTelemetry

OpenTelemetry ist der De-facto-Standard für die Erfassung von Trace-Daten. Es bietet eine einheitliche API zum Generieren von Spans, automatische Instrumentierung gängiger Bibliotheken und einen flexiblen Mechanismus zum Exportieren von Daten in verschiedene Backends: Jaeger, Zipkin, Grafana Tempo, Datadog, New Relic.

Automatische Instrumentierung

OpenTelemetry unterstützt die automatische Erstellung von Spans für gängige Frameworks: Spring Boot, Ktor, Flask, Express, gRPC. Der Entwickler muss lediglich eine Abhängigkeit zum Projekt hinzufügen, und die Bibliothek fängt automatisch eingehende und ausgehende Anfragen ab. Die Auto-Instrumentierung für Java verwendet einen Javaagent, der den Bytecode im laufenden Betrieb ändert, ohne den Quellcode zu verändern.

Für mobile Plattformen bietet OpenTelemetry ein Swift SDK und ein Kotlin SDK. Diese erstellen automatisch Spans für Netzwerkanfragen (URLSession, OkHttp), Datenbankoperationen (CoreData, Room) und Hintergrundaufgaben. Der Entwickler kann benutzerdefinierte Spans für die Geschäftslogik hinzufügen.

Datenexport

Gesammelte Spans werden über das OTLP-Protokoll (OpenTelemetry Protocol) an einen Kollektor gesendet. Der Kollektor kann Daten puffern, filtern und an ein oder mehrere Speichersysteme weiterleiten. Laut OpenTelemetry-Dokumentation beträgt die typische Latenz von der Spans-Erzeugung bis zur Anzeige in einem Dashboard 2–5 Sekunden bei Verwendung des gRPC-Exports.

import OpenTelemetryApi
import OpenTelemetrySdk
import URLSessionInstrumentation

let instrumentation = URLSessionInstrumentation()
instrumentation.enable()

let tracer = OpenTelemetry.instance.tracerFactory
    .get("mobile-monitoring")

let span = tracer.spanBuilder("fetch-user-profile")
    .setAttribute(key: "user.id", value: userId)
    .startSpan()
span.end()

Der Swift-Code aktiviert die automatische Instrumentierung der Netzwerkebene und erstellt einen benutzerdefinierten Span für den Abruf des Benutzerprofils. Das Attribut user.id ermöglicht später das Filtern von Traces nach einem bestimmten Benutzer.

Trace-Sampling-Strategien

In hochbelasteten Systemen ist es unmöglich, jede Anfrage zu tracen — dies erzeugt eine unakzeptable Belastung für Speicher und Netzwerk. Sampling löst dieses Problem, indem nur ein Teil der Traces gespeichert wird. Die Wahl der Strategie wirkt sich direkt auf die Datenvollständigkeit und die Infrastrukturkosten aus.

Head-basiertes Sampling

Die Entscheidung zum Speichern eines Traces wird zum Zeitpunkt seiner Erstellung getroffen — im Root-Span. Der einfachste und gebräuchlichste Ansatz: Ein fester Prozentsatz der Anfragen (z. B. 5 %) wird gespeichert, der Rest verworfen. Der Nachteil ist, dass nicht garantiert werden kann, dass seltene Fehler erfasst werden. Der Probability Sampler in OpenTelemetry unterstützt die Wahrscheinlichkeitseinstellung von 0,0 bis 1,0.

Tail-basiertes Sampling

Die Entscheidung wird bis zum Abschluss aller Spans eines Traces aufgeschoben. Ein Analysator bewertet, ob der Trace Fehler, Zeitüberschreitungen oder interessante Attribute enthält, und speichert ihn erst dann. Dieser Ansatz erfordert die Pufferung aller Spans im Kollektor, was den Speicherverbrauch erhöht. Laut Grafana Labs ist tail-basiertes Sampling in Systemen mit seltenen, aber kritischen Fehlern 40–60 % effizienter im Verhältnis von „Kosten pro nutzbringenden Daten“.

Unterschied zwischen Tracing und Logging

Logging zeichnet einzelne Ereignisse mit Schweregraden (Info, Warn, Error) auf, verknüpft sie jedoch nicht im Kontext einer einzelnen Anfrage. Tracing hingegen erstellt einen strukturierten Baum von Operationen, die zu einer Ende-zu-Ende-Anfrage gehören. In der Praxis schließen sich diese beiden Ansätze nicht aus, sondern ergänzen sich.

Logs sind effektiv für die detaillierte Analyse eines bestimmten Fehlers: Ein Entwickler sieht die genaue Nachricht, den Stacktrace und die Variablenwerte. Tracing beantwortet die Frage „Warum dauert die Anfrage 5 Sekunden?“ — es zeigt, welcher Mikrodienst oder Aufruf die meiste Zeit in Anspruch genommen hat. Laut Honeycomb (2024) finden Teams, die Tracing zusammen mit Logging verwenden, die Ursache von Vorfällen 2,3-mal schneller.

Der moderne Ansatz — Observability — vereint Tracing, Metriken und Logs in einem einzigen System. OpenTelemetry unterstützt die Korrelation zwischen diesen drei Signalen: Jeder Span kann Links zu zugehörigen Logs enthalten, und Metriken können mit einer trace_id versehen werden, um zu bestimmten Traces zu navigieren.