Sessioner, traces & spans i LLM-observabilitet: en av dem är ingen strukturell nivå

Sessioner, traces & spans i LLM-observabilitet: en av dem är ingen strukturell nivå

Datadogs terms-sida, ettan på Google för LLM observability sessions traces spans, definierar två av de tre orden. Inte tre. Det som saknas mappas mot gen_ai.conversation.id, och anledningen till att det saknas är att OpenTelemetry-specen aldrig gjorde det till en strukturell nivå. Om du behöver argumenten för observabilitet i sig börjar du här. Den här artikeln tar vid där den slutar: datamodellen.

Sammanfattning

• Spans nästlas inuti traces; traces grupperas i sessioner. Nästlingen går inifrån och ut: span, sedan trace, sedan session.
• En span är en tidsmätt operation. En trace är en end-to-end-förfrågan. En session är en konversation med flera turer.
• OpenTelemetrys GenAI-konventioner definierar spans och attributet gen_ai.conversation.id. De definierar ingen sessionsnivå.
• Trace- och span-ID:n propageras automatiskt genom kontexten. Det gör inte session-ID:t. Det sätter du själv, varje tur.

Sessioner vs traces vs spans i korthet

Inom LLM-observabilitet är en span en tidsmätt operation (ett modellanrop, ett sökningssteg), en trace är trädet av spans som en förfrågan producerar, och en session grupperar många traces från samma konversation. Nästlingen går inåt: spans inuti traces, traces inuti sessioner. Den tredje grupperingen är den som inte är vad den ser ut att vara.

De där siffrorna för antal och livslängd är typiska intervall för en RAG-chattbot eller en agentloop, inte mätvärden från ett kontrollerat test. Dina siffror kommer att skilja sig. Det som inte skiljer sig: sessionsraden är den som inte är en strukturell nivå i specen, och avsnittet "Sessioner: nivån som ditt verktyg troligen hittade på" bevisar det.

Vad är en span, och vad är en span-typ?

En span är en tidsmätt operation med ett namn, en starttidsstämpel, en sluttidsstämpel, en statuskod och en uppsättning nyckel-värde-attribut. I LLM-tracing är det i attributen den användbara datan finns: gen_ai.usage.input_tokens, gen_ai.usage.output_tokens och gen_ai.request.model berättar vad operationen kostade och vilken modell som körde den.

En span är en operation, inte ett funktionsanrop

Varje span bär på en pekare till föräldra-span-ID (tom på rot-spanen) som bygger trädet. Attributuppsättningen är öppen: du bifogar den kontext du behöver. OpenTelemetrys GenAI-span-konventioner (status: Development) kräver gen_ai.operation.name och gen_ai.provider.name på varje GenAI-span och rekommenderar tokenanvändningsattributen ovan.

En praktisk regel från Datadogs terms-sida: LLM-, Workflow- och Agent-spans kan fungera som en rot-span; Tool-, Task-, Embedding- och Retrieval-spans kan inte det. Det är Datadogs regel, inte en universell sådan, men de är den enda leverantören som uttrycker den, och den sparar dig från att bygga en trace som börjar på ett verktygsanrop utan förälder.

Span-typer: samma idé, fem ordförråd

Alla verktyg behöver ett sätt att säga "den här spanen är ett modellanrop" kontra "den här spanen är en sökning". De är bara inte överens om ordet:

OpenInference-specen listar tio typer. Datadog listar sju. OTel tar en tredje väg: dess GenAI-attributregister publicerar 15 välkända värden 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) och slår fast att om något av dem passar MÅSTE det värdet användas; ett eget värde FÅR bara användas när inget passar. Det är alltså en halvöppen enum, inte avsaknaden av en. Tre listor, tre längder, och ingen inbördes samstämmighet. Om du väljer verktyg spelar den här ordförrådsklyftan större roll än funktionslistan, för det är den dina dashboards och varningsfilter kommer att nycklas mot.

Vad är en trace, och varför spelar trädformen roll?

En trace är trädet av spans som en förfrågan producerar. En rot-span sitter överst; alla andra spans hänger under den via kanter med föräldra-span-ID. Trädformen är hela poängen: en platt logg berättar att något var långsamt, men trädet berättar vilket steg som var långsamt och vilket steg som producerade det dåliga resultatet.

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

Läs det trädet och diagnosen är omedelbar: 74 % av latensen satt i modellanropet, inte i sökningen. En platt logg med fem tidsstämplar ger dig samma total men ingen attribuering.

En agentloop gör trädet djupare och bredare än en vanlig RAG-förfrågan. Varje verktygsanrop skapar sitt eget delträd; en agenttur med fem steg kan lätt producera 30+ spans under en rot. Det är normalt, och det är anledningen till att frågan om span-granularitet nedan finns.

Skillnaden mellan tracing och loggning spelar roll här också: loggning registrerar händelser, tracing registrerar kausalitet. Om du fortfarande väger vad som ska loggas mot vad som ska tracas drar vår artikel om bästa praxis för LLM-loggning den gränsen.

Sessioner: nivån som ditt verktyg troligen hittade på

Nej. En session är inte en strukturell nivå i OpenTelemetrys GenAI-konventioner. Specen definierar spans och attributet gen_ai.conversation.id (villkorligt obligatoriskt, "när det finns tillgängligt", status: Development), beskrivet som den unika identifieraren för en konversation eller tråd som används för att korrelera meddelanden. Leverantörer bygger sedan sitt eget sessionsobjekt ovanpå det attributet. Ingen annan på den här SERP:en anger specens status rakt på sak, så här kommer den.

Konsekvensen är meningen som hela den här artikeln finns för att leverera:

En session är en grupperingsnyckel, inte en föräldra-span. Den propageras inte som ett trace-ID gör; du sätter den själv varje tur.

Missar du en tur faller den turen ur sessionen. Det finns ingen automatisk kontextpropagering för den.

När startar och slutar en session?

Leverantörsdefinierat. Vissa verktyg öppnar en session vid den första tracen med ett nytt konversations-ID och stänger den vid en inaktivitetstimeout (Langfuse använder som standard ett konfigurerbart fönster). Andra kräver ett explicit stängningsanrop. Specen säger ingenting om livscykeln eftersom specen inte modellerar en session som ett objekt.

Vad följer med mellan turer, och vad gör inte det?

Modellens kontextfönster är inte sessionen. Sessionen är en grupperingsnyckel över oberoende traces. Varje tur får sin egen trace, sin egen rot-span, sina egna tokenantal. Det som följer med är konversations-ID-attributet du stämplade på varje rot-span. Det som inte följer med: latens, tokenanvändning, span-struktur. De är per trace.

Vad mäter en metrik på sessionsnivå?

Saker som en enskild trace inte kan: lösningsgrad (löste konversationen användarens problem?), turer-till-svar (hur många traces innan användaren fick det den behövde?) och övergivna konversationer (sessioner utan stängningssignal). Att köra utvärderingar på live-traces på sessionsnivå är så du fångar fel över flera turer som ser bra ut tur för tur.

Koden, leverantörsoberoende

Det här kodexemplet använder bara stabila OTel-primitiver. Inget leverantörs-SDK. Det skapar en rot-span för en tur, en barn-span för sökning, en barn-span för modellanropet och sätter gen_ai.conversation.id så att tre turer hamnar i en session:

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

Anropa handle_turn tre gånger med samma SESSION_ID så grupperas alla tre traces under en session i valfri backend som läser attributet. Ändra ID:t och du har startat en ny session. Det är hela mekanismen.

Vi läste fem leverantörers dokumentation sida vid sida. De är inte överens.

Den 30 juli 2026 läste vi den aktuella datamodelldokumentationen för Langfuse, LangSmith, OpenInference / Phoenix och Datadog sida vid sida, plus OpenTelemetrys GenAI-span-spec. Fyra av fem kallar samma objekt något olika. Bara en behandlar en session som ett första klassens objekt snarare än ett attribut. Datadogs terms-sida, ettan på Google för den här sökningen, definierar inte en session alls.

En källnotering om den första raden: OpenInferences session.id finns inte i traces-specen som länkas ovan, som täcker de tio span-typerna. Den definieras i syskonfilen OpenInference semantic conventions som den unika identifieraren för en session. Två filer, en spec.

Vi uppfann inte jämförelsen mellan leverantörer; FutureAGI publicerar också en OTel-mot-leverantör-tabell. Våra två tillägg är sessionsraden (FutureAGI hoppar över den) och fällan med samma ord men olika betydelse: Langfuses "observation" och LangSmiths "run" är samma objekt som en span, medan Datadogs och OpenInferences span-typer är olika ordförråd för samma idé.

Langfuse kallar det observation, LangSmith kallar det run, Datadog kallar det span. Samma objekt, tre dashboards som går sönder när du migrerar.

Det är vår tolkning av migrationskostnaden, inte ett leverantörspåstående. Men det är anledningen till att sparade filter, eval-konfigurationer och varningsregler nycklade mot "observation" eller "run" slutar fungera den dag du byter verktyg. Du döper inte om ett fält. Du döper om en nivå. Om du väger de två specifika verktygen går vår jämförelse Langfuse vs LangSmith djupare på skillnaderna.

Läsare kanske också redan har Opik, PostHog, Sentry eller Weights & Biases i sin stack; Google kopplar alla fyra till llm tracing, och var och en mappar dessa koncept lite olika. Välja rätt? Vår rundgång av observabilitetsplattformar täcker fältet.

En aktualitetsnotering: GenAI-konventionerna har flyttat till ett eget repository, ut ur huvudrepot semantic-conventions. Den gamla sökvägen opentelemetry.io/docs/specs/semconv/gen-ai/ innehåller nu bara en pekare.

Vilket ID ska vart?

Ett trace-ID identifierar en förfrågan och propageras automatiskt genom kontexten. Ett span-ID identifierar en operation inom den tracen, också automatiskt. Ett korrelations-ID (eller request-ID) kommer från ditt webblager innan tracingen startar, och det är det folk oftast förväxlar med trace-ID:t. Session-ID:t är udden: det är du som sätter det, manuellt, varje tur.

Den praktiska regeln: bifoga gen_ai.conversation.id som ett span-attribut på rot-spanen för varje tur och stämpla användar-ID:t vid sidan av det. Hoppar du över en tur tappar dina metrikker på sessionsnivå den turen i tysthet.

En varning om kardinalitet: användar-ID:n och sessions-ID:n är värden med hög kardinalitet. Det spelar roll för din backends indexeringsnota, vilket är nästa avsnitts problem.

Hur granulär ska en span vara?

Två fellägen, båda vanliga:

För många spans. En span per funktionsanrop ger dig en 400-span-trace som ingen kan läsa och en per-span-nota som ingen godkänt. Hostade backends (Datadog, Langfuse Cloud) prissätter per span-volym. En pratig agentloop som instrumenterar varje strängkonkatenering bränner igenom en gratisnivå på en eftermiddag.

För få spans. En span för "hela kedjan" berättar att den var långsam men inte var. Du slutar med att lägga tillbaka print-satser, vilket är det tracing skulle ersätta.

Tumregeln (och det är en tumregel, inte en mätning): sätt spans på gränserna där ett beslut eller ett externt anrop sker.

• Sökningssteg: sätt en span.
• Rerank-anrop: sätt en span.
• Varje modellanrop: sätt en span.
• Varje verktygsanrop: sätt en span.
• Varje guardrail-kontroll: sätt en span.
• Rena in-process-transformeringar (strängformatering, JSON-parsning, prompt-montering): attribut på föräldra-spanen, inte egna spans.

Om kardinalitet, sampling och retention:

• Attribut med hög kardinalitet (användar-ID:n, fullständiga prompts) blåser upp lagringskostnaderna. Sampla eller trunkera dem.
• De flesta backends låter dig sampla på trace-nivå. Behåll 100 % av fel-traces; sampla den lyckliga vägen.
• Retention-fönster varierar: 7 dagar på gratisnivåer, 30–90 dagar på betalda. Bestäm innan du behöver datan.

För den faktiska kostnadsmodellen bakom span-volym och per-span-prissättning, se vår guide för LLM-kostnadsbevakning. Vi bygger inte om den här.

Hur Techsy angriper det här

För klientagentarbete standardiserar vi på tre regler:

1. En trace per tur. Slå aldrig ihop två användarturer till en trace, även om agenten loopar internt.
2. Ett sessions-ID stämplat på varje rot-span, satt i applikationskoden, aldrig antaget att propageras.
3. Span-typer hållna till en liten fast uppsättning (retrieval, inference, tool, guardrail) så att dashboards överlever ett leverantörsbyte.

Den tredje regeln är den team hoppar över, och det är den som räddar en migration. Om ditt span-ordförråd är bundet till en leverantörs enum går varje varning och sparad vy sönder den dag du byter.

Om du bygger ett agentsystem och vill ha en second opinion om tracing-arkitekturen, boka en gratis konsultation.

Vanliga frågor

Vad är en span i distribuerad tracing?

En span är en tidsmätt arbetsenhet: den har ett namn, en starttid, en sluttid, en status och en uppsättning attribut. Spans länkas till varandra genom föräldra-span-ID-referenser och bildar ett träd. I LLM-applikationer omsluter en span typiskt ett modellanrop, en sökning eller ett verktygsanrop.

Vad är en span i Datadog?

I Datadogs LLM Observability är en span samma tidsmätta operation, men Datadog lägger till en span-typ-taxonomi: LLM, Workflow, Agent, Tool, Task, Embedding och Retrieval. Bara typerna LLM, Workflow och Agent kan fungera som rot-span. Taxonomin är Datadog-specifik; den är inte en del av OpenTelemetry-standarden.

Vad är observabilitetens fyra pelare?

De fyra pelarna är loggar, metrik, traces och (beroende på vems ramverk) profiler eller händelser. Traces är pelaren som den här artikeln lever i. LLM-fallet lägger till en veckning: tokenanvändning och modellidentitet är attribut på trace-spans, inte separata metrikströmmar, vilket slår ihop vad som skulle vara två pelare till en fråga.

Vad är de fyra gyllene signalerna för observabilitet?

Latens, trafik, fel och mättnad. För LLM-system betyder latens time-to-first-token och total genereringstid; trafik betyder förfrågningar per sekund per modell; fel betyder misslyckade spans (statuskod ERROR); mättnad betyder att tokenbudgeten tar slut eller ködjup. Signalerna är desamma; enheterna skiljer sig.

Är en session en del av OpenTelemetry-specifikationen?

Inte som en strukturell nivå. OTel GenAI-span-konventionerna definierar gen_ai.conversation.id som ett villkorligt obligatoriskt attribut ("när det finns tillgängligt") för att korrelera meddelanden i en konversation eller tråd. Det sitter på spans. Leverantörer som Langfuse och LangSmith bygger sina egna sessions- eller trådobjekt ovanpå det.

Vad är skillnaden mellan ett trace-ID, ett span-ID och ett korrelations-ID?

Ett trace-ID identifierar en förfrågan och propageras automatiskt genom alla nedströms tjänster. Ett span-ID identifierar en operation inom den tracen. Ett korrelations-ID (eller request-ID) genereras av ditt webblager innan tracingen börjar och är det värde folk oftast misstar för trace-ID:t. De överlappar i omfattning men har olika ursprung.

Hur många spans ska en trace ha?

Det finns inget fast svar, men typiska intervall är 3–30 för en RAG-förfrågan och 10–50+ för en agentloop med flera verktygsanrop. Tumregeln: sätt spans på externa anrop och beslutsplatser, inte på in-process-transformeringar. Om din trace överstiger 100 spans instrumenterar du troligen för mycket.

Är Langfuses "observations" samma sak som spans?

Ja. En Langfuse-observation är samma objekt som en OTel-span: en tidsmätt operation med attribut. Langfuse delar upp observationer i tre typer (generation, span, event) där OTel använder gen_ai.operation.name. Om du utvärderar verktyg som läser dina traces täcker vår rundgång av LLM-utvärderingsverktyg vilka som accepterar båda ordförråden.

Hur grupperar man en chattbotkonversation med flera turer i en session?

Sätt samma konversationsidentifierare på rot-spanen för varje tur. I OTel-termer är det gen_ai.conversation.id. I Langfuse skickar du ett session_id när du skapar traces. I LangSmith sätter du metadata för session_id eller thread_id. Missar du en tur faller den turen ur grupperingen.

Behöver jag sessioner om jag bara hanterar en-turs-förfrågningar?

Troligen inte. Sessioner finns för att korrelera flera traces till en konversation. Om varje förfrågan är oberoende (ett klassificerings-API, en one-shot-summariserare) räcker metrik på trace-nivå. Lägg till sessioner när du behöver metrik över flera turer: lösningsgrad, turer-till-svar eller kostnad på konversationsnivå. Vår guide för LLM-utvärdering täcker när utvärderingar på sessionsnivå lönar sig.

Kortversionen

Spans nästlas inuti traces; traces grupperas i sessioner. Nästlingen är verklig, men specen strukturerar bara två av de tre nivåerna. gen_ai.conversation.id är ett attribut du sätter själv, inte en föräldra-span som propageras. Och leverantören du väljer idag namnger dessa objekt annorlunda än leverantören du byter till om 18 månader, så håll ditt span-ordförråd litet och portabelt.

Om du väljer plattform, börja med vår jämförelse av observabilitetsplattformar. Om du bygger utvärderingar ovanpå dina traces tar guiden för LLM-utvärdering vid härifrån.