Sessions, Traces & Spans in der LLM-Observability: Eine davon ist keine Strukturebene

Sessions, Traces & Spans in der LLM-Observability: Eine davon ist keine Strukturebene

Die Terms-Seite von Datadog, der Google-Treffer #1 für LLM-Observability Sessions Traces Spans, definiert zwei dieser drei Wörter. Nicht drei. Das fehlende bildet gen_ai.conversation.id ab, und der Grund dafür: Die OpenTelemetry-Spec hat es nie zu einer Strukturebene gemacht. Wenn Sie zuerst die Grundlagen von Observability brauchen, starten Sie hier. Dieser Beitrag setzt dort an, wo jener endet: beim Datenmodell.

Die wichtigsten Punkte

• Spans verschachteln sich in Traces, Traces gruppieren sich zu Sessions. Die Verschachtelung verläuft von innen nach außen: Span, dann Trace, dann Session.
• Ein Span ist eine zeitlich gemessene Operation. Ein Trace ist ein kompletter End-to-End-Request. Eine Session ist eine Multi-Turn-Konversation.
• Die GenAI-Conventions von OpenTelemetry definieren Spans und das Attribut gen_ai.conversation.id. Eine Session-Ebene definieren sie nicht.
• Trace- und Span-IDs werden automatisch über den Context propagiert. Die Session-ID nicht. Sie setzen sie selbst, bei jedem Turn.

Sessions vs. Traces vs. Spans auf einen Blick

In der LLM-Observability ist ein Span eine zeitlich gemessene Operation (ein Model Call, ein Retrieval-Schritt), ein Trace ist der Baum aus Spans, den ein Request erzeugt, und eine Session gruppiert viele Traces derselben Konversation. Die Verschachtelung verläuft nach innen: Spans in Traces, Traces in Sessions. Die dritte Gruppierung ist genau die, die nicht das ist, was sie zu sein scheint.

Die Zahlen zu Anzahl und Lebensdauer sind typische Bereiche, wie man sie in einem RAG-Chatbot oder einer Agent-Loop erwartet, keine Messungen aus einem kontrollierten Test. Ihre Werte werden abweichen. Was nicht abweicht: Die Session-Zeile ist diejenige, die in der Spec keine Strukturebene ist, und der Abschnitt „Sessions: Die Ebene, die Ihr Tool vermutlich erfunden hat" belegt das.

Was ist ein Span, und was ist ein Span-Kind?

Ein Span ist eine zeitlich gemessene Operation mit einem Namen, einem Startzeitstempel, einem Endzeitstempel, einem Statuscode und einem Beutel aus Schlüssel-Wert-Attributen. Beim LLM-Tracing stecken die nützlichen Daten in den Attributen: gen_ai.usage.input_tokens, gen_ai.usage.output_tokens und gen_ai.request.model verraten, was die Operation gekostet hat und welches Modell sie ausgeführt hat.

Ein Span ist eine Operation, kein Funktionsaufruf

Jeder Span trägt einen Zeiger auf die Parent-Span-ID (beim Root Span leer), der den Baum aufbaut. Der Attribut-Beutel ist offen: Sie hängen an, welchen Kontext Sie brauchen. Die OpenTelemetry GenAI Span Conventions (Status: Development) verlangen gen_ai.operation.name und gen_ai.provider.name auf jedem GenAI-Span und empfehlen die oben genannten Token-Usage-Attribute.

Eine praktische Regel von der Terms-Seite von Datadog: LLM-, Workflow- und Agent-Spans dürfen als Root Span dienen; Tool-, Task-, Embedding- und Retrieval-Spans nicht. Das ist Datadogs Regel, keine universelle, aber Datadog ist der einzige Anbieter, der sie explizit nennt, und sie bewahrt Sie davor, einen Trace aufzubauen, der bei einem Tool Call ohne Parent beginnt.

Span-Arten: dieselbe Idee, fünf Vokabulare

Jedes Tool braucht eine Möglichkeit zu sagen „dieser Span ist ein Model Call" im Unterschied zu „dieser Span ist ein Retrieval". Nur beim Wort dafür gibt es keine Einigkeit:

Die OpenInference-Spec listet zehn Arten. Datadog listet sieben. OTel wählt einen dritten Weg: Die GenAI-Attribut-Registry veröffentlicht 15 fest definierte Werte für gen_ai.operation.name (chat, create_agent, create_memory, create_memory_store, delete_memory, delete_memory_store, embeddings, execute_tool, generate_content, invoke_agent, invoke_workflow, plan, retrieval, search_memory, text_completion) und legt fest: Wenn einer davon zutrifft, MUSS dieser Wert verwendet werden; ein eigener Wert DARF nur verwendet werden, wenn keiner passt. Es handelt sich also um ein halboffenes Enum, nicht um das Fehlen eines solchen. Drei Listen, drei Längen, keine Abstimmung untereinander. Wenn Sie gerade ein Tool auswählen, ist diese Vokabular-Lücke wichtiger als die Feature-Liste, denn danach richten sich Ihre Dashboards und Alert-Filter.

Was ist ein Trace, und warum zählt die Baumstruktur?

Ein Trace ist der Baum aus Spans, den ein einzelner Request erzeugt. Ein Root Span sitzt oben; alle anderen Spans hängen über Parent-Span-ID-Kanten darunter. Die Baumform ist der ganze Punkt: Ein flaches Log sagt Ihnen, dass etwas langsam war, aber der Baum sagt Ihnen, welcher Schritt langsam war und welcher Schritt die fehlerhafte Ausgabe erzeugt hat.

chat_request (root)                         2,340ms
├── retrieval                                 410ms
│   └── rerank                                 85ms
├── chat gpt-4o                             1,720ms
└── tool_call: search_calendar                190ms

Lesen Sie diesen Baum, ist die Diagnose sofort klar: 74 % der Latenz steckten im Model Call, nicht im Retrieval. Ein flaches Log mit fünf Zeitstempeln liefert Ihnen dieselbe Gesamtzeit, aber keinerlei Zuordnung.

Eine Agent-Loop macht diesen Baum tiefer und breiter als ein einfacher RAG-Request. Jeder Tool Call erzeugt seinen eigenen Teilbaum; ein Agent-Turn mit fünf Schritten kann leicht 30+ Spans unter einem Root erzeugen. Das ist normal, und es ist der Grund, warum die Frage zur Span-Granularität unten überhaupt existiert.

Auch die Unterscheidung zwischen Tracing und Logging zählt hier: Logging zeichnet Ereignisse auf, Tracing zeichnet Kausalität auf. Wenn Sie noch abwägen, was Sie loggen und was Sie tracen sollen, zieht unser Beitrag Best Practices für LLM-Logging genau diese Linie.

Sessions: Die Ebene, die Ihr Tool vermutlich erfunden hat

Nein. Eine Session ist keine Strukturebene in den OpenTelemetry-GenAI-Conventions. Die Spec definiert Spans und das Attribut gen_ai.conversation.id (bedingt erforderlich, „when available", Status: Development), beschrieben als eindeutiger Bezeichner einer Konversation oder eines Threads zur Korrelation von Nachrichten. Die Anbieter bauen darauf ihr eigenes Session-Objekt. Niemand sonst auf dieser SERP benennt den Spec-Status so offen, deshalb hier in aller Klarheit.

Die Konsequenz ist der Satz, für den dieser ganze Beitrag existiert:

Eine Session ist ein Gruppierungsschlüssel, kein Parent Span. Sie wird nicht so propagiert wie eine Trace-ID; Sie setzen sie selbst, bei jedem Turn.

Verpassen Sie einen Turn, fällt dieser Turn aus der Session heraus. Dafür gibt es keine automatische Context-Propagation.

Wann beginnt und endet eine Session?

Anbieterdefiniert. Manche Tools öffnen eine Session beim ersten Trace mit einer neuen Conversation-ID und schließen sie per Inaktivitäts-Timeout (Langfuse nutzt standardmäßig ein konfigurierbares Zeitfenster). Andere verlangen einen expliziten Close-Aufruf. Die Spec sagt nichts zum Lebenszyklus, weil die Spec eine Session nicht als Objekt modelliert.

Was bleibt über Turns hinweg erhalten, und was nicht?

Das Kontextfenster des Modells ist nicht die Session. Die Session ist ein Gruppierungsschlüssel über unabhängige Traces. Jeder Turn bekommt seinen eigenen Trace, seinen eigenen Root Span, seine eigenen Token-Zahlen. Was erhalten bleibt, ist das Conversation-ID-Attribut, das Sie an jeden Root Span geheftet haben. Was nicht erhalten bleibt: Latenz, Token-Verbrauch, Span-Struktur. Das ist pro Trace.

Was misst eine Metrik auf Session-Ebene?

Dinge, die ein einzelner Trace nicht messen kann: Lösungsrate (hat die Konversation das Problem des Nutzers gelöst?), Turns bis zur Antwort (wie viele Traces, bevor der Nutzer bekam, was er brauchte?) und abgebrochene Konversationen (Sessions ohne Schlusssignal). Evals auf Live-Traces auf Session-Ebene auszuführen, ist der Weg, wie Sie Multi-Turn-Ausfälle erwischen, die Turn für Turn betrachtet völlig in Ordnung aussehen.

Der Code, anbieterneutral

Dieser Ausschnitt nutzt nur stabile OTel-Primitive. Kein Vendor-SDK. Er erzeugt einen Root Span für einen Turn, einen Child Span für das Retrieval, einen Child Span für den Model Call und setzt gen_ai.conversation.id, sodass drei Turns in einer Session landen:

from opentelemetry import trace

tracer = trace.get_tracer("my-llm-app")

SESSION_ID = "conv-8f3a2c"  # same value on every turn

def handle_turn(user_message: str):
    with tracer.start_as_current_span("chat_request") as root:
        # You set this. It does not propagate automatically.
        root.set_attribute("gen_ai.conversation.id", SESSION_ID)

        with tracer.start_as_current_span("retrieval") as ret:
            ret.set_attribute("gen_ai.operation.name", "retrieval")
            docs = retrieve(user_message)

        with tracer.start_as_current_span("chat gpt-4o") as llm:
            llm.set_attribute("gen_ai.operation.name", "chat")
            llm.set_attribute("gen_ai.provider.name", "openai")
            llm.set_attribute("gen_ai.request.model", "gpt-4o")
            response = call_model(user_message, docs)
            llm.set_attribute("gen_ai.usage.input_tokens", 1_204)
            llm.set_attribute("gen_ai.usage.output_tokens", 312)

    return response

Rufen Sie handle_turn dreimal mit derselben SESSION_ID auf, und alle drei Traces gruppieren sich in jedem Backend, das das Attribut liest, unter einer Session. Ändern Sie die ID, haben Sie eine neue Session gestartet. Das ist der gesamte Mechanismus.

Wir haben die Docs von fünf Anbietern nebeneinandergelegt. Sie sind sich nicht einig.

Am 30.07.2026 haben wir die aktuellen Datenmodell-Docs von Langfuse, LangSmith, OpenInference / Phoenix und Datadog nebeneinander gelesen, dazu die OpenTelemetry GenAI Span Spec. Vier der fünf nennen dasselbe Objekt unterschiedlich. Nur eine behandelt eine Session als erstklassiges Objekt statt als Attribut. Die Terms-Seite von Datadog, der Google-Treffer #1 für diese Anfrage, definiert eine Session überhaupt nicht.

Eine Quellenanmerkung zur ersten Zeile: session.id von OpenInference steht nicht in der oben verlinkten Traces-Spec, die die zehn Span-Arten abdeckt. Sie ist in der benachbarten Datei OpenInference Semantic Conventions als eindeutiger Bezeichner einer Session definiert. Zwei Dateien, eine Spec.

Den Anbietervergleich haben wir nicht erfunden; FutureAGI veröffentlicht ebenfalls eine Tabelle OTel gegen Anbieter. Unsere zwei Ergänzungen sind die Session-Zeile (FutureAGI überspringt sie) und die Gleiches-Wort-andere-Bedeutung-Falle: Die „Observation" von Langfuse und der „Run" von LangSmith sind dasselbe Objekt wie ein Span, während die Span-Arten von Datadog und OpenInference unterschiedliche Vokabulare für dieselbe Idee sind.

Langfuse nennt es Observation, LangSmith nennt es Run, Datadog nennt es Span. Dasselbe Objekt, drei Dashboards, die beim Umstieg kaputtgehen.

Das ist unsere Lesart der Migrationskosten, keine Anbieteraussage. Aber es ist der Grund, warum gespeicherte Filter, Eval-Konfigurationen und Alert-Regeln, die auf „Observation" oder „Run" laufen, an dem Tag nicht mehr funktionieren, an dem Sie das Tool wechseln. Sie benennen kein Feld um. Sie benennen eine Ebene um. Wenn Sie genau zwischen diesen beiden Tools abwägen, geht unser Langfuse-vs.-LangSmith-Vergleich tiefer auf die Unterschiede ein.

Leser haben möglicherweise auch Opik, PostHog, Sentry oder Weights & Biases im Stack; Google ordnet alle vier dem Thema llm tracing zu, und jedes bildet diese Konzepte leicht anders ab. Bei der Auswahl des richtigen? Unser Observability-Plattform-Überblick deckt das Feld ab.

Eine Anmerkung zur Aktualität: Die GenAI-Conventions sind in ein eigenes Repository umgezogen, heraus aus dem Haupt-Repo semantic-conventions. Der alte Pfad opentelemetry.io/docs/specs/semconv/gen-ai/ enthält nur noch einen Verweis.

Welche ID gehört wohin?

Eine Trace-ID identifiziert einen Request und wird automatisch über den Context propagiert. Eine Span-ID identifiziert eine Operation innerhalb dieses Traces, ebenfalls automatisch. Eine Correlation-ID (oder Request-ID) stammt aus Ihrer Web-Schicht, bevor das Tracing beginnt, und sie ist diejenige, die am häufigsten mit der Trace-ID verwechselt wird. Die Session-ID ist die Außenseiterin: Ihre Aufgabe, manuell, bei jedem Turn.

Die praktische Regel: Hängen Sie gen_ai.conversation.id als Span-Attribut an den Root Span jedes Turns und stempeln Sie die User-ID dazu. Überspringen Sie einen Turn, verlieren Ihre Metriken auf Session-Ebene diesen Turn, ohne dass es jemand merkt.

Eine Warnung zur Kardinalität: User-IDs und Session-IDs sind Werte mit hoher Kardinalität. Das wirkt sich auf die Indexierungskosten Ihres Backends aus, und das ist das Thema des nächsten Abschnitts.

Wie granular sollte ein Span sein?

Zwei Fehlermodi, beide verbreitet:

Zu viele Spans. Ein Span pro Funktionsaufruf beschert Ihnen einen Trace mit 400 Spans, den niemand lesen kann, und eine Span-Rechnung, die niemand freigegeben hat. Gehostete Backends (Datadog, Langfuse Cloud) bepreisen nach Span-Volumen. Eine gesprächige Agent-Loop, die jede String-Verkettung instrumentiert, brennt einen Free Tier an einem Nachmittag durch.

Zu wenige Spans. Ein Span für „die ganze Chain" sagt Ihnen, dass es langsam war, aber nicht wo. Am Ende bauen Sie wieder Print-Statements ein, genau das, was Tracing eigentlich ersetzen sollte.

Die Daumenregel (und es ist eine Daumenregel, keine Messung): Spannen Sie die Grenzen, an denen eine Entscheidung oder ein externer Aufruf stattfindet.

• Retrieval-Schritt: spannen.
• Rerank-Aufruf: spannen.
• Jeder Model Call: spannen.
• Jeder Tool Call: spannen.
• Jeder Guardrail-Check: spannen.
• Reine In-Prozess-Transformationen (String-Formatierung, JSON-Parsing, Prompt-Zusammenbau): Attribute an den Parent Span, keine eigenen Spans.

Zu Kardinalität, Sampling und Retention:

• Attribute mit hoher Kardinalität (User-IDs, volle Prompts) treiben die Speicherkosten. Samplen oder kürzen Sie sie.
• Die meisten Backends lassen Sampling auf Trace-Ebene zu. Behalten Sie 100 % der Fehler-Traces; samplen Sie den Happy Path.
• Retention-Fenster variieren: 7 Tage im Free Tier, 30–90 Tage in Bezahlplänen. Entscheiden Sie, bevor Sie die Daten brauchen.

Für das eigentliche Kostenmodell hinter Span-Volumen und Span-Preisen siehe unseren LLM-Kosten-Monitoring-Leitfaden. Wir bauen es hier nicht nach.

Wie Techsy das handhabt

Bei Agent-Projekten für Kunden standardisieren wir auf drei Regeln:

1. Ein Trace pro Turn. Führen Sie nie zwei User-Turns zu einem Trace zusammen, auch wenn der Agent intern loopt.
2. Eine Session-ID auf jedem Root Span, gesetzt im Anwendungscode, nie mit automatischer Propagation angenommen.
3. Span-Arten auf eine kleine feste Menge beschränken (Retrieval, Inference, Tool, Guardrail), damit Dashboards einen Anbieterwechsel überleben.

Die dritte Regel ist die, die Teams auslassen, und die, die eine Migration rettet. Wenn Ihr Span-Vokabular an das Enum eines Anbieters gebunden ist, geht an dem Tag, an dem Sie wechseln, jeder Alert und jede gespeicherte Ansicht kaputt.

Wenn Sie ein Agent-System bauen und eine zweite Meinung zur Tracing-Architektur möchten, sichern Sie sich eine kostenlose Beratung.

Häufig gestellte Fragen

Was ist ein Span im verteilten Tracing?

Ein Span ist eine zeitlich gemessene Arbeitseinheit: Er hat einen Namen, eine Startzeit, eine Endzeit, einen Status und einen Satz Attribute. Spans sind über Parent-Span-ID-Referenzen miteinander verknüpft und bilden einen Baum. In LLM-Anwendungen umschließt ein Span typischerweise einen Model Call, ein Retrieval oder einen Tool-Aufruf.

Was ist ein Span in Datadog?

In Datadogs LLM-Observability ist ein Span dieselbe zeitlich gemessene Operation, aber Datadog ergänzt eine Span-Kind-Taxonomie: LLM, Workflow, Agent, Tool, Task, Embedding und Retrieval. Nur die Arten LLM, Workflow und Agent dürfen als Root Span dienen. Die Taxonomie ist Datadog-spezifisch; sie ist nicht Teil des OpenTelemetry-Standards.

Was sind die vier Säulen der Observability?

Die vier Säulen sind Logs, Metrics, Traces und (je nach Lesart) Profiles oder Events. Traces sind die Säule, in der dieser Beitrag lebt. Der LLM-Fall bringt eine Besonderheit mit: Token-Verbrauch und Modellidentität sind Attribute auf Trace-Spans, keine separaten Metrik-Streams, was zwei Säulen zu einer einzigen Abfrage verschmilzt.

Was sind die vier goldenen Signale der Observability?

Latenz, Traffic, Fehler und Sättigung. Für LLM-Systeme bedeutet Latenz: Time-to-First-Token und gesamte Generierungszeit; Traffic bedeutet Requests pro Sekunde pro Modell; Fehler bedeuten fehlgeschlagene Spans (Statuscode ERROR); Sättigung bedeutet Erschöpfung des Token-Budgets oder Queue-Tiefe. Die Signale sind dieselben; die Einheiten unterscheiden sich.

Ist eine Session Teil der OpenTelemetry-Spezifikation?

Nicht als Strukturebene. Die OTel GenAI Span Conventions definieren gen_ai.conversation.id als bedingt erforderliches Attribut („when available") zur Korrelation von Nachrichten in einer Konversation oder einem Thread. Es sitzt auf Spans. Anbieter wie Langfuse und LangSmith bauen darauf ihre eigenen Session- oder Thread-Objekte.

Was ist der Unterschied zwischen Trace-ID, Span-ID und Correlation-ID?

Eine Trace-ID identifiziert einen Request und wird automatisch über alle nachgelagerten Dienste propagiert. Eine Span-ID identifiziert eine Operation innerhalb dieses Traces. Eine Correlation-ID (oder Request-ID) wird von Ihrer Web-Schicht erzeugt, bevor das Tracing beginnt, und ist der Wert, den man am häufigsten für die Trace-ID hält. Sie überschneiden sich im Geltungsbereich, entstehen aber unterschiedlich.

Wie viele Spans sollte ein Trace haben?

Es gibt keine feste Antwort, aber typische Bereiche liegen bei 3–30 für einen RAG-Request und 10–50+ für eine Agent-Loop mit mehreren Tool Calls. Die Daumenregel: Spannen Sie externe Aufrufe und Entscheidungspunkte, keine In-Prozess-Transformationen. Wenn Ihr Trace 100 Spans überschreitet, instrumentieren Sie vermutlich zu viel.

Sind Langfuse-„Observations" dasselbe wie Spans?

Ja. Eine Langfuse-Observation ist dasselbe Objekt wie ein OTel-Span: eine zeitlich gemessene Operation mit Attributen. Langfuse teilt Observations in drei Typen (generation, span, event), wo OTel gen_ai.operation.name verwendet. Wenn Sie Tools evaluieren, die Ihre Traces lesen, deckt unser LLM-Evaluierungstools-Ranking ab, welche beide Vokabulare akzeptieren.

Wie fasst man eine Multi-Turn-Chatbot-Konversation zu einer Session zusammen?

Setzen Sie denselben Konversations-Bezeichner auf den Root Span jedes Turns. In OTel-Terminologie ist das gen_ai.conversation.id. In Langfuse übergeben Sie eine session_id beim Erzeugen von Traces. In LangSmith setzen Sie die Metadaten session_id oder thread_id. Verpassen Sie einen Turn, fällt dieser Turn aus der Gruppierung heraus.

Brauche ich Sessions, wenn ich nur Single-Turn-Requests verarbeite?

Wahrscheinlich nicht. Sessions existieren, um mehrere Traces zu einer Konversation zu korrelieren. Wenn jeder Request unabhängig ist (eine Klassifizierungs-API, ein One-Shot-Summarizer), reichen Metriken auf Trace-Ebene. Fügen Sie Sessions hinzu, wenn Sie Metriken über Turns hinweg brauchen: Lösungsrate, Turns bis zur Antwort oder Kosten auf Konversationsebene. Unser LLM-Evaluierungsleitfaden behandelt, wann sich Evals auf Session-Ebene lohnen.

Die Kurzfassung

Spans verschachteln sich in Traces, Traces gruppieren sich zu Sessions. Die Verschachtelung ist real, aber die Spec strukturiert nur zwei der drei Ebenen. gen_ai.conversation.id ist ein Attribut, das Sie selbst setzen, kein Parent Span, der propagiert wird. Und der Anbieter, den Sie heute wählen, benennt diese Objekte anders als der, zu dem Sie in 18 Monaten wechseln, also halten Sie Ihr Span-Vokabular klein und portabel.

Wenn Sie eine Plattform auswählen, starten Sie mit unserem Observability-Plattform-Vergleich. Wenn Sie Evals auf Ihren Traces aufbauen, setzt der LLM-Evaluierungsleitfaden genau hier an.