Sessions, Traces i Spans w obserwowalności LLM: jeden z nich nie jest poziomem strukturalnym

Sessions, Traces i Spans w obserwowalności LLM: jeden z nich nie jest poziomem strukturalnym

Strona terminów Datadoga, wynik numer 1 w Google dla zapytania LLM observability sessions traces spans, definiuje dwa z tych trzech słów. Nie trzy. Brakujące odwzorowuje się na gen_ai.conversation.id, a powód jego nieobecności jest taki, że specyfikacja OpenTelemetry nigdy nie uczyniła z niego poziomu strukturalnego. Jeśli potrzebujesz najpierw argumentów za samą obserwowalnością, zacznij tutaj. Ten artykuł zaczyna się tam, gdzie tamten się kończy: od modelu danych.

Najważniejsze wnioski

• Spans zagnieżdżają się w traces, a traces grupują się w sessions. Zagnieżdżenie biegnie od środka na zewnątrz: span, potem trace, potem sesja.
• Span to jedna mierzona czasowo operacja. Trace to jedno żądanie od początku do końca. Sesja to jedna wieloturowa konwersacja.
• Konwencje GenAI OpenTelemetry definiują spans i atrybut gen_ai.conversation.id. Nie definiują poziomu sesji.
• ID trace'a i spanu propagują się automatycznie przez kontekst. ID sesji nie. Ustawiasz je sam, w każdej turze.

Sessions, Traces i Spans w skrócie

W obserwowalności LLM span to jedna mierzona czasowo operacja (wywołanie modelu, krok wyszukiwania), trace to drzewo spanów, które tworzy jedno żądanie, a sesja grupuje wiele trace'ów z tej samej konwersacji. Zagnieżdżenie biegnie do środka: spans wewnątrz traces, traces wewnątrz sessions. Trzecie z tych grupowań jest tym, które nie jest tym, czym wygląda.

Te liczby dotyczące ilości i czasu życia to typowe zakresy, których można się spodziewać w chatbocie RAG lub pętli agenta, a nie pomiary z kontrolowanego testu. Twoje wartości będą inne. Co się nie zmieni: wiersz Sesji jest tym, który nie jest poziomem strukturalnym w specyfikacji, a sekcja „Sessions: poziom, który prawdopodobnie wymyśliło Twoje narzędzie" to udowadnia.

Czym jest span, a czym rodzaj spanu?

Span to jedna mierzona czasowo operacja z nazwą, znacznikiem czasu rozpoczęcia, znacznikiem czasu zakończenia, kodem statusu i zbiorem atrybutów klucz-wartość. W tracingu LLM to właśnie w atrybutach mieszkają przydatne dane: gen_ai.usage.input_tokens, gen_ai.usage.output_tokens i gen_ai.request.model mówią, ile kosztowała operacja i który model ją wykonał.

Span to jedna operacja, nie jedno wywołanie funkcji

Każdy span niesie wskaźnik na ID spanu nadrzędnego (pusty w spanie głównym), który buduje drzewo. Zbiór atrybutów jest otwarty: dołączasz, jaki kontekst potrzebujesz. Konwencje spanów GenAI OpenTelemetry (status: Development) wymagają gen_ai.operation.name i gen_ai.provider.name w każdym spanie GenAI, a zalecają powyższe atrybuty zużycia tokenów.

Jedna praktyczna zasada ze strony terminów Datadoga: spans LLM, Workflow i Agent mogą pełnić rolę spanu głównego. Spans Tool, Task, Embedding i Retrieval nie mogą. To zasada Datadoga, nie uniwersalna, ale tylko ten dostawca ją zapisuje, a oszczędza Ci budowania trace'a, który zaczyna się od wywołania narzędzia bez rodzica.

Rodzaje spanów: ta sama idea, pięć słowników

Każde narzędzie musi jakoś powiedzieć „ten span to wywołanie modelu" w odróżnieniu od „ten span to wyszukiwanie". Tylko że dostawcy nie zgadzają się co do słowa:

Specyfikacja OpenInference wymienia dziesięć rodzajów. Datadog siedem. OTel idzie trzecią drogą: jego rejestr atrybutów GenAI publikuje 15 znanych wartości dla 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) i stwierdza, że jeśli jedna z nich pasuje, to MUSI zostać użyta. Wartość własna MOŻE być użyta tylko wtedy, gdy żadna nie pasuje. To więc półotwarta enumeracja, a nie jej brak. Trzy listy, trzy długości i żadnego dopasowania między nimi. Jeśli wybierasz narzędzie, ta luka w słowniku liczy się bardziej niż lista funkcji, bo to na niej będą się opierać Twoje dashboardy i filtry alertów.

Czym jest trace i dlaczego kształt drzewa ma znaczenie?

Trace to drzewo spanów utworzone przez jedno żądanie. Jeden span główny siedzi na szczycie, a każdy inny span wisi pod nim przez krawędzie ID spanu nadrzędnego. Kształt drzewa jest całym sensem: płaski log powie Ci, że coś było wolne, ale drzewo powie, który krok był wolny i który krok wyprodukował zły wynik.

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

Przeczytaj to drzewo, a diagnoza jest natychmiastowa: 74% opóźnienia siedziało w wywołaniu modelu, nie w wyszukiwaniu. Płaski log z pięcioma znacznikami czasu da Ci tę samą sumę, ale zero przypisania.

Pętla agenta czyni to drzewo głębszym i szerszym niż zwykłe żądanie RAG. Każde wywołanie narzędzia tworzy własne poddrzewo. Pięciokrokowa tura agenta może bez problemu wyprodukować ponad 30 spanów pod jednym korzeniem. To normalne i to jest powód, dla którego istnieje poniższe pytanie o szczegółowość spanów.

Rozróżnienie między tracingiem a logowaniem też ma tu znaczenie: logowanie zapisuje zdarzenia, tracing zapisuje przyczynowość. Jeśli wciąż decydujesz, co logować, a co trace'ować, nasz artykuł o najlepszych praktykach logowania LLM wyznacza tę granicę.

Sessions: poziom, który prawdopodobnie wymyśliło Twoje narzędzie

Nie. Sesja nie jest poziomem strukturalnym w konwencjach OpenTelemetry GenAI. Specyfikacja definiuje spans i atrybut gen_ai.conversation.id (warunkowo wymagany, „gdy dostępny", status: Development), opisany jako unikalny identyfikator konwersacji lub wątku służący do korelowania wiadomości. Dostawcy budują potem własny obiekt sesji na tym atrybucie. Nikt inny na tej stronie wyników nie podaje statusu specyfikacji wprost, więc oto on.

Konsekwencją jest zdanie, dla którego istnieje cały ten artykuł:

Sesja to klucz grupowania, nie span nadrzędny. Nie propaguje się tak jak ID trace'a. Ustawiasz ją sam w każdej turze.

Pomiń jedną turę, a ta tura wypadnie z sesji. Nie ma dla niej automatycznej propagacji kontekstu.

Kiedy sesja się zaczyna, a kiedy kończy?

Zależy od dostawcy. Niektóre narzędzia otwierają sesję przy pierwszym trace'u niosącym nowe ID konwersacji i zamykają ją po przekroczeniu limitu bezczynności (Langfuse domyślnie stosuje konfigurowalne okno). Inne wymagają jawnego wywołania zamknięcia. Specyfikacja nie mówi nic o cyklu życia, bo nie modeluje sesji jako obiektu.

Co przechodzi między turami, a co nie?

Okno kontekstowe modelu to nie sesja. Sesja to klucz grupowania nałożony na niezależne trace'i. Każda tura dostaje własny trace, własny span główny, własne liczniki tokenów. Przechodzi atrybut ID konwersacji, który przybiłeś do każdego spanu głównego. Nie przechodzą: opóźnienie, zużycie tokenów, struktura spanów. Te są przypisane do trace'a.

Co mierzy metryka na poziomie sesji?

Rzeczy, których pojedynczy trace nie zmierzy: wskaźnik rozwiązania (czy konwersacja rozwiązała problem użytkownika?), liczba tur do odpowiedzi (ile trace'ów minęło, zanim użytkownik dostał to, czego potrzebował?) i porzucone konwersacje (sesje bez sygnału zamknięcia). Uruchamianie ewaluacji na żywych trace'ach na poziomie sesji to sposób na łapanie wieloturowych awarii, które wyglądają poprawnie tura po turze.

Kod, bez zależności od dostawcy

Ten fragment używa tylko stabilnych prymitywów OTel. Bez SDK dostawcy. Tworzy span główny dla jednej tury, span potomny dla wyszukiwania, potomny dla wywołania modelu i ustawia gen_ai.conversation.id, tak że trzy tury lądują w jednej sesji:

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

Wywołaj handle_turn trzy razy z tym samym SESSION_ID, a wszystkie trzy trace'i zgrupują się w jednej sesji w każdym backendzie, który czyta ten atrybut. Zmień ID, a zaczynasz nową sesję. To cały mechanizm.

Przeczytaliśmy dokumentacje pięciu dostawców obok siebie. Nie zgadzają się

30 lipca 2026 r. przeczytaliśmy równolegle aktualną dokumentację modelu danych dla Langfuse, LangSmith, OpenInference / Phoenix i Datadoga, plus specyfikację spanów GenAI OpenTelemetry. Czterech z pięciu nazywa ten sam obiekt inaczej. Tylko jeden traktuje sesję jako obiekt pierwszej klasy, a nie jako atrybut. Strona terminów Datadoga, wynik numer 1 w Google dla tego zapytania, w ogóle nie definiuje sesji.

Jedna uwaga źródłowa do pierwszego wiersza: session.id w OpenInference nie znajduje się w powyższej specyfikacji trace'ów, która obejmuje dziesięć rodzajów spanów. Jest zdefiniowane w siostrzanym pliku konwencji semantycznych OpenInference jako unikalny identyfikator sesji. Dwa pliki, jedna specyfikacja.

Nie wymyśliliśmy tego porównania między dostawcami. FutureAGI też publikuje tabelę OTel kontra dostawcy. Nasze dwa dodatki to wiersz sesji (FutureAGI go pomija) oraz pułapka tego samego słowa o innym znaczeniu: „obserwacja" w Langfuse i „run" w LangSmith to ten sam obiekt co span, podczas gdy rodzaje spanów Datadoga i OpenInference to różne słowniki na tę samą ideę.

Langfuse nazywa to obserwacją, LangSmith nazywa to runem, Datadog nazywa to spanem. Ten sam obiekt, trzy dashboardy, które psują się przy migracji.

To nasza interpretacja kosztu migracji, nie twierdzenie dostawcy. Ale to jest powód, dla którego zapisane filtry, konfiguracje ewaluacji i reguły alertów oparte na „obserwacji" lub „runie" przestają działać w dniu zmiany narzędzia. Nie zmieniasz nazwy pola. Zmieniasz nazwę poziomu. Jeśli ważysz dokładnie te dwa narzędzia, nasze porównanie Langfuse i LangSmith głębiej opisuje te rozbieżności.

Czytelnicy mogą mieć już w swoim stosie Opik, PostHog, Sentry lub Weights & Biases. Google wiąże wszystkie cztery z llm tracing, a każde mapuje te pojęcia nieco inaczej. Wybierasz właściwe? Nasz przegląd platform obserwowalności obejmuje cały rynek.

Jedna uwaga o świeżości: konwencje GenAI przeniosły się do własnego repozytorium, poza główne repo semantic-conventions. Stara ścieżka opentelemetry.io/docs/specs/semconv/gen-ai/ zawiera teraz tylko wskaźnik.

Które ID dokąd trafia?

ID trace'a identyfikuje jedno żądanie i propaguje się automatycznie przez kontekst. ID spanu identyfikuje jedną operację wewnątrz tego trace'a, też automatycznie. ID korelacji (lub ID żądania) przychodzi z Twojej warstwy webowej, zanim tracing się zacznie, i to je ludzie najczęściej mylą z ID trace'a. ID sesji jest tym odstającym: ustawiasz je sam, ręcznie, w każdej turze.

Praktyczna zasada: dołącz gen_ai.conversation.id jako atrybut do spanu głównego każdej tury i przybij obok ID użytkownika. Pomiń jedną turę, a Twoje metryki na poziomie sesji po cichu stracą tę turę.

Jedno ostrzeżenie o kardynalności: ID użytkowników i ID sesji to wartości o wysokiej kardynalności. To ma znaczenie dla rachunku za indeksowanie w Twoim backendzie, co jest problemem następnej sekcji.

Jak szczegółowy powinien być span?

Dwa tryby awarii, oba powszechne:

Nadmiar spanów. Span na każde wywołanie funkcji daje Ci trace o 400 spanach, którego nikt nie przeczyta, i rachunek za każdy span, którego nikt nie zaakceptował. Hostowane backendy (Datadog, Langfuse Cloud) cenią się według wolumenu spanów. Rozgadana pętla agenta, która instrumentuje każde sklejenie stringów, przejada darmowy plan w jedno popołudnie.

Niedomiar spanów. Jeden span na „cały łańcuch" powie Ci, że było wolno, ale nie gdzie. Skończysz z powrotem dodając printy, czyli dokładnie to, co tracing miał zastąpić.

Reguła kciuka (i to jest reguła kciuka, nie pomiar): obejmuj spanami granice, na których zapada decyzja lub następuje wywołanie zewnętrzne.

• Krok wyszukiwania: span.
• Wywołanie rerank: span.
• Każde wywołanie modelu: span.
• Każde wywołanie narzędzia: span.
• Każde sprawdzenie guardraila: span.
• Czyste przekształcenia wewnątrz procesu (formatowanie stringów, parsowanie JSON, składanie promptu): atrybuty spanu nadrzędnego, nie własne spany.

O kardynalności, próbkowaniu i retencji:

• Atrybuty o wysokiej kardynalności (ID użytkowników, pełne prompty) pompują koszty przechowywania. Próbkuj je lub przycinaj.
• Większość backendów pozwala próbkować na poziomie trace'a. Zatrzymaj 100% trace'ów z błędami. Próbkuj szczęśliwą ścieżkę.
• Okna retencji są różne: 7 dni w planach darmowych, 30–90 dni w płatnych. Zdecyduj, zanim będziesz potrzebować danych.

Po rzeczywisty model kosztów stojący za wolumenem spanów i cenami za span zajrzyj do naszego przewodnika po monitorowaniu kosztów LLM. Nie będziemy go tu odtwarzać.

Jak Techsy do tego podchodzi

W projektach klienckich z agentami standaryzujemy trzy zasady:

1. Jeden trace na turę. Nigdy nie łącz dwóch tur użytkownika w jeden trace, nawet jeśli agent zapętla się wewnętrznie.
2. ID sesji przybite do każdego spanu głównego, ustawiane w kodzie aplikacji, nigdy z założeniem propagacji.
3. Rodzaje spanów trzymane w małym stałym zbiorze (retrieval, inference, tool, guardrail), żeby dashboardy przeżyły zmianę dostawcy.

Trzecia zasada jest tą, którą zespoły pomijają, i tą, która ratuje migrację. Jeśli Twój słownik spanów jest przywiązany do enumeracji jednego dostawcy, każdy alert i każdy zapisany widok psuje się w dniu zmiany.

Jeśli budujesz system agentowy i chcesz drugiej opinii o architekturze tracingu, umów się na bezpłatną konsultację.

O autorze

Mert Batur jest współzałożycielem Techsy.io, gdzie zespół dostarcza agentów AI, systemy automatyzacji i pipeline'y głosowe/SDR dla klientów B2B. Pisze o stosie narzędzi LLM, którego zespół Techsy faktycznie używa w produkcji. Napisz na LinkedIn.

Najczęściej zadawane pytania

Czym jest span w distributed tracingu?

Span to jedna mierzona czasowo jednostka pracy: ma nazwę, czas rozpoczęcia, czas zakończenia, status i zbiór atrybutów. Spany łączą się ze sobą przez odniesienia do ID spanu nadrzędnego, tworząc drzewo. W aplikacjach LLM span zwykle owija jedno wywołanie modelu, jedno wyszukiwanie lub jedno wywołanie narzędzia.

Czym jest span w Datadogu?

W LLM Observability Datadoga span to ta sama mierzona czasowo operacja, ale Datadog dodaje taksonomię rodzajów spanów: LLM, Workflow, Agent, Tool, Task, Embedding i Retrieval. Tylko rodzaje LLM, Workflow i Agent mogą pełnić rolę spanu głównego. Taksonomia jest specyficzna dla Datadoga. Nie jest częścią standardu OpenTelemetry.

Czym są cztery filary obserwowalności?

Cztery filary to logi, metryki, trace'i i (zależnie od tego, czyją przyjąć ramę) profile lub zdarzenia. Trace'y są filarem, w którym żyje ten artykuł. Przypadek LLM dodaje komplikację: zużycie tokenów i tożsamość modelu są atrybutami spanów trace'a, nie osobnymi strumieniami metryk, co zwija to, co byłoby dwoma filarami, w jedno zapytanie.

Czym są cztery złote sygnały obserwowalności?

Opóźnienie, ruch, błędy i nasycenie. Dla systemów LLM opóźnienie oznacza czas do pierwszego tokenu i całkowity czas generacji. Ruch oznacza żądania na sekundę na model. Błędy oznaczają nieudane spany (kod statusu ERROR). Nasycenie oznacza wyczerpanie budżetu tokenów lub głębokość kolejki. Sygnały są te same. Jednostki się różnią.

Czy sesja jest częścią specyfikacji OpenTelemetry?

Nie jako poziom strukturalny. Konwencje spanów GenAI OTel definiują gen_ai.conversation.id jako warunkowo wymagany atrybut („gdy dostępny") do korelowania wiadomości w konwersacji lub wątku. Leży na spanach. Dostawcy tacy jak Langfuse i LangSmith budują na nim własne obiekty sesji lub wątku.

Jaka jest różnica między ID trace'a, ID spanu i ID korelacji?

ID trace'a identyfikuje jedno żądanie i propaguje się automatycznie przez wszystkie usługi niżej. ID spanu identyfikuje jedną operację wewnątrz tego trace'a. ID korelacji (lub ID żądania) jest generowane przez Twoją warstwę webową, zanim zacznie się tracing, i to tę wartość ludzie najczęściej biorą za ID trace'a. Nakładają się zakresem, ale mają różne pochodzenie.

Ile spanów powinien mieć jeden trace?

Nie ma jednej odpowiedzi, ale typowe zakresy to 3–30 dla żądania RAG i 10–50+ dla pętli agenta z wieloma wywołaniami narzędzi. Reguła kciuka: obejmuj spanami wywołania zewnętrzne i punkty decyzyjne, nie przekształcenia wewnątrz procesu. Jeśli Twój trace przekracza 100 spanów, prawdopodobnie instrumentujesz za dużo.

Czy „obserwacje" w Langfuse to to samo co spany?

Tak. Obserwacja w Langfuse to ten sam obiekt co span OTel: jedna mierzona czasowo operacja z atrybutami. Langfuse dzieli obserwacje na trzy typy (generation, span, event), tam gdzie OTel używa gen_ai.operation.name. Jeśli oceniasz narzędzia, które czytają Twoje trace'y, nasz przegląd narzędzi do ewaluacji LLM opisuje, które akceptują oba słowniki.

Jak zgrupować wieloturową konwersację chatbota w jedną sesję?

Ustaw ten sam identyfikator konwersacji na spanie głównym każdej tury. W terminologii OTel to gen_ai.conversation.id. W Langfuse przekazujesz session_id przy tworzeniu trace'ów. W LangSmith ustawiasz metadane session_id lub thread_id. Pomiń jedną turę, a ta tura wypadnie z grupowania.

Czy potrzebuję sesji, jeśli obsługuję tylko żądania jednoturowe?

Prawdopodobnie nie. Sesje istnieją po to, by korelować wiele trace'ów w jedną konwersację. Jeśli każde żądanie jest niezależne (API klasyfikacyjne, jednorazowy sumaryzator), metryki na poziomie trace'a wystarczą. Dodaj sesje, gdy potrzebujesz metryk między turami: wskaźnika rozwiązania, liczby tur do odpowiedzi lub kosztu na poziomie konwersacji. Nasz przewodnik po ewaluacji LLM opisuje, kiedy ewaluacje na poziomie sesji się opłacają.

Wersja skrócona

Spans zagnieżdżają się w traces, a traces grupują się w sessions. Zagnieżdżenie jest prawdziwe, ale specyfikacja strukturyzuje tylko dwa z trzech poziomów. gen_ai.conversation.id to atrybut, który ustawiasz sam, nie span nadrzędny, który się propaguje. A dostawca, którego wybierasz dziś, nazywa te obiekty inaczej niż dostawca, na którego przejdziesz za 18 miesięcy, więc trzymaj swój słownik spanów mały i przenośny.

Jeśli wybierasz platformę, zacznij od naszego porównania platform obserwowalności. Jeśli budujesz ewaluacje na swoich trace'ach, przewodnik po ewaluacji LLM podejmuje temat od tego miejsca.