Session, Trace và Span trong LLM Observability: Một Trong Số Đó Không Phải Là Cấp Cấu Trúc

Session, Trace và Span trong LLM Observability: Một Trong Số Đó Không Phải Là Cấp Cấu Trúc

Trang thuật ngữ của Datadog, kết quả số 1 trên Google cho cụm từ khóa LLM observability sessions traces spans, chỉ định nghĩa hai trong ba từ đó. Không phải ba. Từ còn thiếu tương ứng với gen_ai.conversation.id, và lý do nó vắng mặt là vì spec OpenTelemetry chưa bao giờ biến nó thành một cấp cấu trúc. Nếu bạn cần lập luận cho bản thân observability, bắt đầu tại đây. Bài này tiếp nối đúng nơi bài đó dừng lại: mô hình dữ liệu.

Ý chính

• Span lồng bên trong trace; trace gom thành session. Thứ tự lồng đi từ trong ra ngoài: span, rồi trace, rồi session.
• Span là một thao tác được đo thời gian. Trace là một request từ đầu đến cuối. Session là một cuộc hội thoại nhiều lượt.
• Quy ước GenAI của OpenTelemetry định nghĩa span và thuộc tính gen_ai.conversation.id. Chúng không định nghĩa cấp session.
• ID trace và span tự lan truyền qua context. ID session thì không. Bạn phải tự đặt nó, ở mọi lượt.

Session, Trace và Span, nhìn nhanh một lượt

Trong LLM observability, span là một thao tác được đo thời gian (một lời gọi mô hình, một bước truy xuất), trace là cây span mà một request sinh ra, và session gom nhiều trace từ cùng một cuộc hội thoại. Chiều lồng hướng vào trong: span trong trace, trace trong session. Cấp thứ ba chính là cấp không giống như vẻ ngoài của nó.

Những con số về số lượng và vòng đời đó là các khoảng điển hình mà bạn có thể kỳ vọng ở một chatbot RAG hoặc một vòng lặp agent, không phải số đo từ một thử nghiệm có kiểm soát. Con số của bạn sẽ khác. Điều không khác: dòng Session là dòng không phải một cấp cấu trúc trong spec, và phần "Session: cấp mà có lẽ chính công cụ của bạn đã tự bịa ra" sẽ chứng minh điều đó.

Span là gì, và loại span là gì?

Span là một thao tác được đo thời gian, có tên, timestamp bắt đầu, timestamp kết thúc, mã trạng thái và một túi thuộc tính khóa-giá trị. Trong LLM tracing, thuộc tính là nơi chứa dữ liệu hữu ích: gen_ai.usage.input_tokens, gen_ai.usage.output_tokens và gen_ai.request.model cho bạn biết thao tác đó tốn bao nhiêu và mô hình nào đã chạy nó.

Một span là một thao tác, không phải một lời gọi hàm

Mọi span mang một con trỏ ID span cha (trống ở span gốc) để dựng nên cây. Túi thuộc tính là mở: bạn gắn bất kỳ context nào mình cần. Quy ước span GenAI của OpenTelemetry (trạng thái: Development) yêu cầu gen_ai.operation.name và gen_ai.provider.name trên mọi span GenAI, và khuyến nghị các thuộc tính mức dùng token ở trên.

Một quy tắc thực tế từ trang thuật ngữ của Datadog: span LLM, Workflow và Agent có thể đóng vai trò span gốc; span Tool, Task, Embedding và Retrieval thì không. Đó là quy tắc của Datadog, không phải quy tắc phổ quát, nhưng họ là vendor duy nhất nêu rõ, và nó giúp bạn tránh dựng một trace bắt đầu từ một lời gọi công cụ không có cha.

Span kind: cùng một ý tưởng, năm bộ từ vựng

Công cụ nào cũng cần cách để nói "span này là một lời gọi mô hình" khác với "span này là một bước truy xuất". Chỉ là chúng không thống nhất về từ ngữ:

Spec OpenInference liệt kê mười loại. Datadog liệt kê bảy. OTel đi con đường thứ ba: registry thuộc tính GenAI của họ công bố 15 giá trị well-known cho 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) và tuyên bố rằng nếu một trong số đó đúng ngữ cảnh, BẮT BUỘC phải dùng giá trị đó; giá trị tùy chỉnh CHỈ được dùng khi không có giá trị nào khớp. Vậy đây là một enum bán mở, không phải sự vắng mặt của enum. Ba danh sách, ba độ dài, và không có sự tương đồng giữa chúng. Nếu bạn đang chọn công cụ, khoảng cách từ vựng này quan trọng hơn cả danh sách tính năng, vì nó chính là thứ mà dashboard và bộ lọc cảnh báo của bạn sẽ bám vào.

Trace là gì, và vì sao cấu trúc cây lại quan trọng?

Trace là cây span do một request sinh ra. Một span gốc nằm trên đỉnh; mọi span khác treo bên dưới nó qua các cạnh ID-span-cha. Cấu trúc cây là toàn bộ ý nghĩa: một log phẳng cho bạn biết có thứ gì đó chậm, nhưng cái cây cho bạn biết bước nào chậm và bước nào sinh ra kết quả sai.

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

Đọc cái cây đó và chẩn đoán hiện ra ngay: 74% độ trễ nằm ở lời gọi mô hình, không phải ở bước truy xuất. Một log phẳng gồm năm timestamp cho bạn cùng tổng thời gian nhưng không cho bạn chút phân bổ nào.

Vòng lặp agent làm cái cây này sâu hơn và rộng hơn một request RAG thông thường. Mỗi lời gọi công cụ sinh ra cây con riêng; một lượt agent năm bước có thể dễ dàng tạo ra hơn 30 span dưới một gốc. Chuyện đó bình thường, và nó là lý do câu hỏi về độ chi tiết của span bên dưới tồn tại.

Phân biệt giữa tracing và logging cũng quan trọng ở đây: logging ghi lại sự kiện, tracing ghi lại quan hệ nhân quả. Nếu bạn vẫn đang cân nhắc ghi log thứ gì so với trace thứ gì, bài best practices logging LLM của chúng tôi vạch ra ranh giới đó.

Session: cấp mà có lẽ chính công cụ của bạn đã tự bịa ra

Không. Session không phải một cấp cấu trúc trong quy ước GenAI của OpenTelemetry. Spec định nghĩa span và thuộc tính gen_ai.conversation.id (bắt buộc có điều kiện, "khi có sẵn", trạng thái: Development), được mô tả là định danh duy nhất cho một cuộc hội thoại hoặc luồng, dùng để tương quan các tin nhắn. Các vendor sau đó tự dựng đối tượng session riêng trên thuộc tính đó. Không ai khác trên trang kết quả tìm kiếm này nói thẳng trạng thái spec, nên chúng tôi nói ở đây.

Hệ quả là câu mà cả bài này tồn tại để đưa ra:

Session là một khóa gom nhóm, không phải một span cha. Nó không lan truyền theo cách ID trace vẫn làm; bạn phải tự đặt nó ở mọi lượt.

Bỏ sót một lượt và lượt đó rơi khỏi session. Không có cơ chế lan truyền context tự động nào cho nó.

Session bắt đầu và kết thúc khi nào?

Do vendor định nghĩa. Một số công cụ mở session ở trace đầu tiên mang ID cuộc hội thoại mới và đóng nó khi hết thời gian chờ không hoạt động (Langfuse mặc định một cửa sổ có thể cấu hình). Số khác yêu cầu một lời gọi đóng rõ ràng. Spec không nói gì về vòng đời vì spec không mô hình hóa session như một đối tượng.

Điều gì được mang qua giữa các lượt, và điều gì không?

Cửa sổ ngữ cảnh của mô hình không phải session. Session là một khóa gom nhóm trên các trace độc lập. Mỗi lượt có trace riêng, span gốc riêng, số token riêng. Thứ được mang qua là thuộc tính ID cuộc hội thoại mà bạn đóng dấu lên từng span gốc. Thứ không được mang qua: độ trễ, mức dùng token, cấu trúc span. Những thứ đó thuộc về từng trace.

Metric cấp session đo lường điều gì?

Những thứ mà một trace đơn lẻ không đo được: tỷ lệ giải quyết (cuộc hội thoại có giải quyết được vấn đề của người dùng không?), số lượt đến câu trả lời (bao nhiêu trace trước khi người dùng nhận được thứ họ cần?), và cuộc hội thoại bị bỏ dở (session không có tín hiệu kết thúc). Chạy eval trên trace trực tiếp ở cấp session là cách bạn bắt những lỗi đa lượt mà nhìn từng lượt một thì có vẻ ổn.

Code, không phụ thuộc vendor

Đoạn snippet này chỉ dùng các primitive OTel ổn định. Không SDK vendor. Nó tạo một span gốc cho một lượt, một span con cho truy xuất, một span con cho lời gọi mô hình, và đặt gen_ai.conversation.id để ba lượt rơi vào một 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

Gọi handle_turn ba lần với cùng SESSION_ID và cả ba trace gom vào một session ở bất kỳ backend nào đọc thuộc tính đó. Đổi ID và bạn đã bắt đầu một session mới. Toàn bộ cơ chế chỉ có vậy.

Chúng tôi đọc docs của năm vendor đặt cạnh nhau. Họ không đồng thuận.

Ngày 30-07-2026, chúng tôi đọc tài liệu mô hình dữ liệu hiện hành của Langfuse, LangSmith, OpenInference / Phoenix và Datadog đặt cạnh nhau, cùng với spec span GenAI của OpenTelemetry. Bốn trong năm gọi cùng một đối tượng bằng tên khác. Chỉ một bên coi session là đối tượng hạng nhất thay vì một thuộc tính. Trang thuật ngữ của Datadog, kết quả số 1 trên Google cho truy vấn này, hoàn toàn không định nghĩa session.

Một ghi chú nguồn về dòng đầu tiên: session.id của OpenInference không nằm trong spec trace liên kết ở trên, phần bao quát mười span kind. Nó được định nghĩa trong file quy ước ngữ nghĩa OpenInference anh em với tư cách định danh duy nhất cho một session. Hai file, một spec.

Chúng tôi không phát minh ra so sánh liên vendor; FutureAGI cũng công bố một bảng OTel đấu với vendor. Hai bổ sung của chúng tôi là dòng session (FutureAGI bỏ qua) và cái bẫy cùng-từ-khác-nghĩa: "observation" của Langfuse và "run" của LangSmith là cùng đối tượng với span, trong khi span kind của Datadog và OpenInference là những bộ từ vựng khác nhau cho cùng một ý tưởng.

Langfuse gọi nó là observation, LangSmith gọi nó là run, Datadog gọi nó là span. Cùng một đối tượng, ba dashboard sẽ vỡ khi bạn di chuyển.

Đó là cách đọc của chúng tôi về chi phí di chuyển, không phải tuyên bố của vendor. Nhưng đó là lý do các bộ lọc đã lưu, cấu hình eval và quy tắc cảnh báo bám vào "observation" hoặc "run" ngừng chạy vào ngày bạn đổi công cụ. Bạn không đổi tên một trường. Bạn đổi tên một cấp. Nếu bạn đang cân nhắc giữa đúng hai công cụ đó, bài so sánh Langfuse và LangSmith của chúng tôi đi sâu hơn vào sự phân kỳ.

Người đọc cũng có thể đã có Opik, PostHog, Sentry hoặc Weights & Biases trong stack; Google liên kết cả bốn với llm tracing, và mỗi bên ánh xạ các khái niệm này hơi khác nhau. Đang chọn bên phù hợp? Bài tổng hợp nền tảng observability của chúng tôi bao quát cả thị trường.

Một ghi chú về tính mới: quy ước GenAI đã chuyển sang repository riêng, tách khỏi repo semantic-conventions chính. Đường dẫn opentelemetry.io/docs/specs/semconv/gen-ai/ cũ giờ chỉ còn một con trỏ.

ID nào nằm ở đâu?

Trace ID định danh một request và lan truyền tự động qua context. Span ID định danh một thao tác bên trong trace đó, cũng tự động. ID tương quan (hoặc ID request) đến từ tầng web của bạn trước khi tracing bắt đầu, và nó là thứ mọi người hay nhầm với trace ID nhất. ID session là kẻ lạc loài: bạn tự đặt, thủ công, ở mọi lượt.

Quy tắc thực tế: gắn gen_ai.conversation.id như một thuộc tính span lên span gốc của mọi lượt, và đóng dấu user ID bên cạnh nó. Bỏ sót một lượt và metric cấp session của bạn âm thầm mất lượt đó.

Một cảnh báo về cardinality: user ID và ID session là các giá trị cardinality cao. Điều đó quan trọng với hóa đơn lập chỉ mục của backend, cũng chính là vấn đề của phần tiếp theo.

Span nên chi tiết đến mức nào?

Hai chế độ lỗi, cả hai đều phổ biến:

Quá nhiều span. Mỗi span cho một lời gọi hàm cho bạn một trace 400 span không ai đọc nổi và một hóa đơn theo span không ai phê duyệt. Các backend hosted (Datadog, Langfuse Cloud) định giá theo dung lượng span. Một vòng lặp agent nói nhiều, instrument mọi phép nối chuỗi, sẽ đốt cháy gói miễn phí trong một buổi chiều.

Quá ít span. Một span cho "toàn bộ chain" cho bạn biết nó chậm nhưng không biết ở đâu. Rốt cuộc bạn lại thêm print statement vào, đúng thứ mà tracing đáng lẽ phải thay thế.

Quy tắc kinh nghiệm (và nó đúng là quy tắc kinh nghiệm, không phải số đo): đặt span ở những ranh giới nơi một quyết định hoặc một lời gọi ra bên ngoài diễn ra.

• Bước truy xuất: đặt span.
• Lời gọi rerank: đặt span.
• Mỗi lời gọi mô hình: đặt span.
• Mỗi lời gọi công cụ: đặt span.
• Mỗi lần kiểm tra guardrail: đặt span.
• Các phép biến đổi thuần túy trong tiến trình (định dạng chuỗi, parse JSON, lắp ráp prompt): thuộc tính trên span cha, không phải span riêng.

Về cardinality, lấy mẫu và lưu trữ:

• Thuộc tính cardinality cao (user ID, toàn bộ prompt) làm phồng chi phí lưu trữ. Lấy mẫu hoặc cắt ngắn chúng.
• Hầu hết backend cho phép lấy mẫu ở cấp trace. Giữ 100% trace lỗi; lấy mẫu luồng thành công.
• Cửa sổ lưu trữ khác nhau: 7 ngày ở gói miễn phí, 30–90 ngày ở gói trả phí. Quyết định trước khi bạn cần dữ liệu.

Về mô hình chi phí thực sự đằng sau dung lượng span và định giá theo span, xem hướng dẫn giám sát chi phí LLM của chúng tôi. Chúng tôi sẽ không dựng lại nó ở đây.

Cách Techsy tiếp cận vấn đề này

Với công việc agent cho khách hàng, chúng tôi chuẩn hóa trên ba quy tắc:

1. Một trace mỗi lượt. Không bao giờ gộp hai lượt của người dùng vào một trace, kể cả khi agent lặp bên trong.
2. ID session đóng dấu trên mọi span gốc, đặt trong code ứng dụng, không bao giờ giả định là nó tự lan truyền.
3. Span kind giữ ở một tập nhỏ cố định (truy xuất, suy luận, công cụ, guardrail) để dashboard sống sót qua một lần đổi vendor.

Quy tắc thứ ba là quy tắc các đội hay bỏ qua, và là quy tắc cứu một cuộc di chuyển. Nếu từ vựng span của bạn gắn với enum của một vendor, mọi cảnh báo và view đã lưu sẽ vỡ vào ngày bạn chuyển.

Nếu bạn đang xây một hệ thống agent và muốn một ý kiến thứ hai về kiến trúc tracing, nhận tư vấn miễn phí.

Về tác giả

Mert Batur là Đồng sáng lập của Techsy.io, nơi đội ngũ triển khai AI agent, hệ thống tự động hóa và pipeline voice/SDR cho khách hàng B2B. Anh viết về stack công cụ LLM mà đội Techsy thực sự dùng trong production. Kết nối trên LinkedIn.

Câu hỏi thường gặp

Span trong distributed tracing là gì?

Span là một đơn vị công việc được đo thời gian: nó có tên, thời gian bắt đầu, thời gian kết thúc, trạng thái và một tập thuộc tính. Span liên kết với nhau qua tham chiếu ID-span-cha, tạo thành một cây. Trong ứng dụng LLM, một span thường bao bọc một lời gọi mô hình, một bước truy xuất hoặc một lời gọi công cụ.

Span trong Datadog là gì?

Trong LLM Observability của Datadog, span là cùng thao tác được đo thời gian đó, nhưng Datadog thêm một phân loại span kind: LLM, Workflow, Agent, Tool, Task, Embedding và Retrieval. Chỉ các kind LLM, Workflow và Agent mới được làm span gốc. Phân loại này là đặc thù của Datadog; nó không thuộc chuẩn OpenTelemetry.

Bốn trụ cột của observability là gì?

Bốn trụ cột là log, metric, trace và (tùy cách phân loại của từng người) profile hoặc event. Trace là trụ cột mà bài này thuộc về. Trường hợp LLM thêm một nếp gấp: mức dùng token và định danh mô hình là thuộc tính trên span của trace, không phải luồng metric riêng, điều này gộp thứ đáng lẽ là hai trụ cột vào một truy vấn.

Bốn tín hiệu vàng của observability là gì?

Độ trễ, lưu lượng, lỗi và mức bão hòa. Với hệ thống LLM, độ trễ nghĩa là thời gian đến token đầu tiên và tổng thời gian sinh; lưu lượng nghĩa là số request mỗi giây trên mỗi mô hình; lỗi nghĩa là span hỏng (mã trạng thái ERROR); bão hòa nghĩa là cạn ngân sách token hoặc độ sâu hàng đợi. Tín hiệu thì giống nhau; đơn vị thì khác.

Session có phải một phần của đặc tả OpenTelemetry không?

Không phải với tư cách một cấp cấu trúc. Quy ước span GenAI của OTel định nghĩa gen_ai.conversation.id là thuộc tính bắt buộc có điều kiện ("khi có sẵn") để tương quan các tin nhắn trong một cuộc hội thoại hoặc luồng. Nó nằm trên span. Các vendor như Langfuse và LangSmith dựng đối tượng session hoặc thread riêng trên nó.

Khác nhau giữa trace ID, span ID và ID tương quan là gì?

Trace ID định danh một request và lan truyền tự động qua mọi dịch vụ hạ nguồn. Span ID định danh một thao tác bên trong trace đó. ID tương quan (hoặc ID request) do tầng web của bạn sinh ra trước khi tracing bắt đầu và là giá trị mọi người hay nhầm với trace ID nhất. Chúng chồng lấn về phạm vi nhưng có nguồn gốc khác nhau.

Một trace nên có bao nhiêu span?

Không có câu trả lời cố định, nhưng khoảng điển hình là 3–30 cho một request RAG và 10–50+ cho một vòng lặp agent có nhiều lời gọi công cụ. Quy tắc kinh nghiệm: đặt span cho lời gọi ra ngoài và điểm quyết định, không đặt cho phép biến đổi trong tiến trình. Nếu trace của bạn vượt 100 span, có lẽ bạn đang instrument quá tay.

"Observation" của Langfuse có phải là span không?

Có. Một observation của Langfuse là cùng đối tượng với một span OTel: một thao tác được đo thời gian có thuộc tính. Langfuse chia observation thành ba loại (generation, span, event) trong khi OTel dùng gen_ai.operation.name. Nếu bạn đang đánh giá các công cụ đọc trace của mình, bài tổng hợp công cụ đánh giá LLM của chúng tôi cho biết công cụ nào chấp nhận cả hai bộ từ vựng.

Làm sao gom một cuộc hội thoại chatbot nhiều lượt vào một session?

Đặt cùng một định danh cuộc hội thoại lên span gốc của mọi lượt. Với OTel, đó là gen_ai.conversation.id. Với Langfuse, bạn truyền session_id khi tạo trace. Với LangSmith, bạn đặt metadata session_id hoặc thread_id. Bỏ sót một lượt và lượt đó rơi khỏi nhóm.

Tôi có cần session nếu chỉ xử lý request một lượt không?

Có lẽ không. Session tồn tại để tương quan nhiều trace vào một cuộc hội thoại. Nếu mọi request độc lập (một API phân loại, một trình tóm tắt một lần), metric cấp trace là đủ. Thêm session khi bạn cần metric liên lượt: tỷ lệ giải quyết, số lượt đến câu trả lời, hoặc chi phí cấp cuộc hội thoại. Hướng dẫn đánh giá LLM của chúng tôi bao quát khi nào eval cấp session đáng công sức.

Phiên bản ngắn

Span lồng bên trong trace; trace gom thành session. Sự lồng nhau là thật, nhưng spec chỉ cấu trúc hóa hai trong ba cấp. gen_ai.conversation.id là một thuộc tính bạn tự đặt, không phải một span cha tự lan truyền. Và vendor bạn chọn hôm nay đặt tên các đối tượng này khác với vendor bạn sẽ chuyển sang sau 18 tháng nữa, nên hãy giữ từ vựng span của mình nhỏ và di chuyển được.

Nếu bạn đang chọn nền tảng, bắt đầu với bài so sánh nền tảng observability của chúng tôi. Nếu bạn đang xây eval trên trace của mình, hướng dẫn đánh giá LLM sẽ tiếp nối từ đây.