LLM Observability 2026 - Tracing, Metrics, Evals cho Multi-Agent AI voi OpenTelemetry, Langfuse va ClickHouse

Posted on: 4/14/2026 11:09:37 AM

Khi các hệ thống AI chuyển từ demo sang production với hàng triệu lượt gọi LLM mỗi ngày, các đội ngũ kỹ sư đối mặt với một câu hỏi tưởng chừng đơn giản nhưng lại cực kỳ khó trả lời: "Chuyện gì thực sự đang xảy ra bên trong hệ thống AI của tôi?". Một prompt bị lỗi ở agent thứ ba trong chuỗi năm bước, một tool call tốn 12 giây mà không rõ lý do, một regression về chất lượng câu trả lời chỉ xuất hiện với 2% request — đây là những loại vấn đề mà stack monitoring truyền thống (Prometheus + Grafana + ELK) không đủ sức giải quyết. Bài viết này đi sâu vào kiến trúc LLM Observability 2026 — cách kết hợp OpenTelemetry GenAI, Langfuse, ClickHouse và Redis để xây một pipeline quan sát hoàn chỉnh cho hệ thống multi-agent production.

1. Tại sao LLM Observability trở thành yêu cầu bắt buộc của 2026

Observability cho hệ thống LLM không phải là một phiên bản copy-paste của APM truyền thống. Bản chất của LLM tạo ra nhiều chiều quan sát hoàn toàn mới mà hệ thống monitoring cũ không có khái niệm:

• Tính bất định (non-determinism): Cùng một input có thể cho ra output khác nhau giữa các lần chạy. Một bug có thể chỉ xuất hiện 1/1000 request.
• Chi phí biến thiên: Mỗi request có chi phí token khác nhau, có thể chênh nhau 1000 lần. Một prompt leak context có thể tốn 200 USD trong vài phút.
• Chuỗi hành động phức tạp: Một yêu cầu người dùng có thể kích hoạt 5-50 lượt gọi LLM, hàng chục tool call, và nhiều sub-agent song song.
• Chất lượng là chiều quan sát mới: "Response có đúng không?", "Agent có bị hallucination không?" — không thể đo bằng 200 OK.
• Feedback vòng lặp dài: Regression có thể chỉ lộ ra sau khi người dùng báo lại hàng giờ sau, lúc đó dữ liệu debug đã mất.

2. Ba trụ cột quan sát — áp dụng cho thế giới LLM

Observability truyền thống đứng trên ba trụ cột: Metrics, Logs, và Traces. Với LLM, mỗi trụ cột mang ý nghĩa mới và được bổ sung trụ cột thứ tư — Evals.

graph TB
    subgraph "LLM Observability Stack"
        M["Metrics
Token/sec, Cost, Latency,
Cache hit ratio"]
        L["Logs
Prompts, Responses,
Tool Call Payloads"]
        T["Traces
Distributed spans qua
agent, tool, sub-agent"]
        E["Evals
Quality score, Hallucination,
Groundedness, Safety"]
    end
    M --> DB["ClickHouse
Columnar store"]
    L --> DB
    T --> DB
    E --> DB
    DB --> UI["Langfuse / Grafana /
Custom dashboard"]
    style M fill:#e94560,stroke:#fff,color:#fff
    style L fill:#0f3460,stroke:#fff,color:#fff
    style T fill:#4CAF50,stroke:#fff,color:#fff
    style E fill:#ff9800,stroke:#fff,color:#fff
    style DB fill:#2c3e50,stroke:#fff,color:#fff
    style UI fill:#2c3e50,stroke:#fff,color:#fff

Khác biệt chính so với APM cũ: payload phải được lưu. Trong hệ thống web, log một request GET /users không cần lưu header. Với LLM, nếu không lưu prompt và response, bạn không thể debug, không thể tính lại chi phí theo từng user, và không thể đánh giá chất lượng hồi sau.

3. OpenTelemetry GenAI Semantic Conventions — Chuẩn hóa telemetry LLM

OpenTelemetry (OTel) là chuẩn công nghiệp cho telemetry từ năm 2019, nhưng chỉ đến 2024-2025 mới có một nhóm GenAI Special Interest Group định nghĩa ra semantic conventions cho LLM. Đây là bước đi then chốt: khi mọi hệ thống dùng chung một bộ attribute name, bạn có thể đổi backend (Langfuse → Phoenix → Datadog) mà không phải viết lại toàn bộ instrumentation.

Các attribute chuẩn được định nghĩa trong gen_ai.* namespace:

4. Giải phẫu một LLM Trace

Trong thế giới LLM multi-agent, một trace không còn là một HTTP request đơn giản. Nó là một cây span có thể có độ sâu 5-10 cấp, đại diện cho chuỗi: người dùng → router → planner agent → nhiều sub-agent → tool call → LLM call → sub-tool → response.

graph TD
    R["Root Span
user.request
dur 12.4s"] --> P["Span: planner.invoke
gen_ai.operation=chat
dur 1.2s"]
    R --> E1["Span: executor.task_1
dur 4.8s"]
    R --> E2["Span: executor.task_2
dur 6.1s"]
    E1 --> L1["Span: llm.call
claude-opus-4-6
tokens 12k in / 800 out"]
    E1 --> T1["Span: tool.read_file
dur 0.1s"]
    E2 --> L2["Span: llm.call
claude-sonnet-4-6
tokens 8k in / 1.2k out"]
    E2 --> T2["Span: tool.web_search
dur 2.1s"]
    E2 --> T3["Span: tool.bash
dur 0.8s"]
    style R fill:#e94560,stroke:#fff,color:#fff
    style P fill:#0f3460,stroke:#fff,color:#fff
    style E1 fill:#0f3460,stroke:#fff,color:#fff
    style E2 fill:#0f3460,stroke:#fff,color:#fff
    style L1 fill:#4CAF50,stroke:#fff,color:#fff
    style L2 fill:#4CAF50,stroke:#fff,color:#fff
    style T1 fill:#ff9800,stroke:#fff,color:#fff
    style T2 fill:#ff9800,stroke:#fff,color:#fff
    style T3 fill:#ff9800,stroke:#fff,color:#fff

Mỗi span cần ghi lại ít nhất: tên operation, parent_id để tái tạo cây, start/end time, attributes theo GenAI convention, và events (ví dụ: cache.hit, rate_limit.retry, streaming.first_token). Đặc biệt với streaming, thời điểm first token là metric UX quan trọng nhất — không phải tổng latency.

5. Langfuse — Nền tảng Observability chuyên dụng cho LLM

Langfuse là một open-source platform ra đời cuối 2023, đến 2026 đã trở thành một trong những giải pháp LLM observability được dùng rộng rãi nhất trong cộng đồng — cùng với Arize Phoenix, Helicone, và LangSmith. Langfuse v3 (2025) được tái kiến trúc hoàn toàn trên ClickHouse làm store cho traces và events, Postgres cho metadata, Redis cho queue và cache, và S3-compatible object store cho payload lớn.

graph LR
    A["Application
Python/TS SDK"] --> B["Langfuse Ingest API"]
    B --> Q["Redis Queue"]
    Q --> W["Worker
Async processing"]
    W --> CH[("ClickHouse
traces, observations,
scores")]
    W --> PG[("Postgres
projects, users,
prompts")]
    W --> S3[("S3
large payloads")]
    CH --> UI["Langfuse Web UI"]
    PG --> UI
    S3 --> UI
    UI --> USER["Developer"]
    style A fill:#e94560,stroke:#fff,color:#fff
    style Q fill:#ff9800,stroke:#fff,color:#fff
    style W fill:#4CAF50,stroke:#fff,color:#fff
    style CH fill:#2c3e50,stroke:#fff,color:#fff
    style PG fill:#2c3e50,stroke:#fff,color:#fff
    style S3 fill:#2c3e50,stroke:#fff,color:#fff
    style UI fill:#0f3460,stroke:#fff,color:#fff

Mô hình dữ liệu của Langfuse gồm ba khái niệm chính:

• Trace: Tương ứng với một yêu cầu đầu-cuối của người dùng. Có user_id, session_id, metadata tùy ý.
• Observation: Một span con bên trong trace. Có ba loại: span (bất kỳ operation nào), generation (lượt gọi LLM), event (điểm đánh dấu).
• Score: Điểm đánh giá gắn với trace hoặc observation — có thể là user feedback, LLM-as-judge score, hoặc kết quả eval tự động.

Điểm mạnh của Langfuse là integration sâu với các framework agent phổ biến (LangChain, LlamaIndex, Vercel AI SDK, OpenAI SDK, Anthropic SDK) — chỉ cần set một environment variable là toàn bộ trace được bắt tự động. Đồng thời, Langfuse cung cấp Playground và Prompt Management: bạn có thể version prompt, A/B test, và rollback ngay trên UI.

6. ClickHouse — Vì sao là backend lý tưởng cho AI Telemetry

Khi bạn có một hệ thống multi-agent xử lý 10 triệu trace mỗi ngày, mỗi trace trung bình 15 observation và 30 KB payload, phép tính cho ra: 150 triệu row/ngày và 450 GB dữ liệu/ngày. Postgres sẽ "chết" trong vòng một tuần. Elasticsearch có thể chạy được nhưng chi phí sẽ cao gấp 5-10 lần. ClickHouse được sinh ra cho chính loại workload này.

Một bảng llm_observations điển hình trong ClickHouse có thể được định nghĩa như sau:

CREATE TABLE llm_observations (
    trace_id          String,
    span_id           String,
    parent_span_id    String,
    start_time        DateTime64(9, 'UTC'),
    duration_ms       UInt32,
    agent_id          LowCardinality(String),
    operation_name    LowCardinality(String),
    gen_ai_system     LowCardinality(String),
    model             LowCardinality(String),
    input_tokens      UInt32,
    output_tokens     UInt32,
    cache_read_tokens UInt32,
    cost_usd          Float64,
    user_id           String,
    session_id        String,
    status            LowCardinality(String),
    error_type        LowCardinality(String),
    prompt            String CODEC(ZSTD(3)),
    response          String CODEC(ZSTD(3)),
    metadata          String
) ENGINE = MergeTree
PARTITION BY toYYYYMM(start_time)
ORDER BY (user_id, agent_id, start_time, trace_id)
TTL start_time + INTERVAL 90 DAY
SETTINGS index_granularity = 8192;

7. Redis — Caching, Rate Limiting và Deduplication

Trong pipeline observability, Redis đóng vai trò "bộ đệm nóng" trước ClickHouse. Có ba loại workload chính:

• Queue ingestion: Langfuse dùng BullMQ trên Redis làm queue cho các event đến. Client gửi event → ghi ngay vào Redis → trả về 202 Accepted → worker consume và batch ghi xuống ClickHouse mỗi 500ms. Kiến trúc này tách decoupling giữa tầng ingest và tầng store, chịu được spike 10-100x.
• Rate limiting & cost guardrail: Dùng Redis với atomic INCRBY và EXPIRE để giới hạn token/phút theo user, project, hoặc agent. Khi vượt ngưỡng, request bị chặn ngay tại gateway — không bao giờ chạm đến provider LLM.
• Deduplication & idempotency: Mỗi trace được gán một idempotency_key dạng hash. Client retry có thể gửi lại cùng event; Redis SET NX sẽ loại bỏ duplicate trong cửa sổ 10 phút, tránh phình dữ liệu.

Ngoài ra, Redis còn được dùng làm semantic cache cho LLM response — khi một prompt đã được xử lý và có câu trả lời "đủ tốt", lần sau với prompt tương tự (so sánh qua vector embedding) sẽ được trả lời ngay từ cache. Chủ đề này đã được tôi phân tích sâu trong bài Semantic Caching cho LLM Agents, ở đây tôi chỉ nhấn mạnh: một sự kiện cache.hit phải được gắn vào span để dashboard có thể theo dõi cache hit ratio và cost saved theo thời gian.

8. Kiến trúc End-to-End cho Multi-Agent Observability

Gộp tất cả lại, một pipeline observability hoàn chỉnh cho hệ thống multi-agent có thể được vẽ như sau:

graph TB
    subgraph "Application Layer"
        U["User / API client"]
        GW["API Gateway
+ Auth + Rate Limit"]
        ORCH["Orchestrator Agent"]
        A1["Sub-Agent 1"]
        A2["Sub-Agent 2"]
        TOOLS["Tool Layer
Read, Bash, Search..."]
        LLM["LLM Providers
Anthropic, OpenAI"]
    end

    subgraph "Telemetry Layer"
        SDK["OTel GenAI SDK
openinference"]
        COL["OTel Collector"]
        R1[("Redis
Queue + Rate Limit")]
    end

    subgraph "Storage Layer"
        CH2[("ClickHouse Cluster
traces + metrics")]
        PG2[("Postgres
metadata")]
        S32[("S3
large payloads")]
    end

    subgraph "Analysis Layer"
        LF["Langfuse UI"]
        GRAF["Grafana
Dashboards"]
        EVAL["Eval Pipeline
LLM-as-judge"]
        ALERT["Alerting
PagerDuty"]
    end

    U --> GW --> ORCH
    ORCH --> A1 --> TOOLS
    ORCH --> A2 --> TOOLS
    A1 --> LLM
    A2 --> LLM
    ORCH --> SDK
    A1 --> SDK
    A2 --> SDK
    TOOLS --> SDK
    SDK --> COL --> R1 --> CH2
    COL --> S32
    COL --> PG2
    CH2 --> LF
    CH2 --> GRAF
    CH2 --> EVAL
    EVAL --> CH2
    GRAF --> ALERT

    style U fill:#e94560,stroke:#fff,color:#fff
    style ORCH fill:#0f3460,stroke:#fff,color:#fff
    style A1 fill:#0f3460,stroke:#fff,color:#fff
    style A2 fill:#0f3460,stroke:#fff,color:#fff
    style SDK fill:#4CAF50,stroke:#fff,color:#fff
    style COL fill:#4CAF50,stroke:#fff,color:#fff
    style R1 fill:#ff9800,stroke:#fff,color:#fff
    style CH2 fill:#2c3e50,stroke:#fff,color:#fff
    style PG2 fill:#2c3e50,stroke:#fff,color:#fff
    style S32 fill:#2c3e50,stroke:#fff,color:#fff
    style LF fill:#e94560,stroke:#fff,color:#fff
    style GRAF fill:#e94560,stroke:#fff,color:#fff
    style EVAL fill:#ff9800,stroke:#fff,color:#fff

Trong kiến trúc này, OTel Collector đóng vai trò trung tâm — nó nhận telemetry từ mọi ngôn ngữ, transform (thêm resource attributes, sampling, redaction PII), và route đến nhiều sink cùng lúc. Bạn có thể gửi cùng một trace đến Langfuse cho developer, Datadog cho SRE, và ClickHouse tự quản cho phân tích dài hạn — mà không phải instrument lại code.

9. Cost Tracking, Token Accounting và Budget Control

Một trong những lý do chính khiến các công ty áp dụng LLM observability là kiểm soát chi phí. Không có hệ thống nào nằm ngoài nỗi đau này — khi chuyển từ POC sang production, chi phí LLM có thể tăng 50-100x chỉ trong vài tuần.

Một hệ thống cost tracking hoàn chỉnh phải trả lời được các câu hỏi sau trong < 2 giây:

• Hôm nay chi bao nhiêu USD cho mỗi model, mỗi agent, mỗi feature, mỗi user?
• So với tuần trước thay đổi bao nhiêu phần trăm?
• Ai là top 10 user gây tốn chi phí nhất? Họ có phải abuse không?
• Feature nào có cost-per-request cao bất thường?
• Nếu tôi thêm 1000 user mới với pattern hiện tại, chi phí dự kiến là bao nhiêu?

Công thức tính cost cần lưu ý bốn loại token riêng biệt (đây là điểm rất nhiều team bỏ qua):

cost = (input_tokens - cache_read_tokens) * price_input
     + cache_read_tokens                  * price_cache_read
     + cache_write_tokens                 * price_cache_write
     + output_tokens                      * price_output

10. Evals liên tục — Continuous Evaluation Loop

Với observability truyền thống, bạn đo latency và error rate — hai chỉ số tự có. Với LLM, chỉ số quan trọng nhất là chất lượng câu trả lời, và chỉ số này phải được tạo ra bằng cách chạy eval. Đây là lý do mọi platform LLM observability đều tích hợp sẵn hệ thống eval.

Ba kiểu eval thường dùng trong pipeline production:

Trong pipeline end-to-end, kết quả eval được ghi ngược vào ClickHouse dưới dạng score gắn với trace. Sau đó, dashboard Langfuse hoặc Grafana có thể hiển thị: "Quality score của agent planner giảm 8% trong 24 giờ qua sau khi thay đổi prompt v2.3". Đây là cách phát hiện regression chất lượng trước khi người dùng phàn nàn.

11. Debug Multi-Agent bằng Distributed Tracing

Trong hệ thống một agent, debug là việc đọc log theo thứ tự. Trong hệ thống multi-agent, nơi các agent chạy song song, gọi nhau qua message bus, và có thể tự spawn sub-agent, đọc log tuyến tính là bất khả thi. Distributed tracing là kỹ thuật bắt buộc để điều tra bug.

Quy trình điển hình khi có một trace bị lỗi:

12. Privacy, PII Redaction và Security Considerations

Observability đi kèm một vấn đề nghiêm trọng: dữ liệu nhạy cảm rò rỉ vào telemetry. Prompt của người dùng có thể chứa email, số điện thoại, mã số thẻ, thậm chí thông tin y tế. Nếu telemetry được gửi đến third-party SaaS hoặc lưu 90 ngày trong ClickHouse không kiểm soát, bạn có thể vi phạm GDPR, HIPAA, hoặc nghị định bảo vệ dữ liệu cá nhân.

Các nguyên tắc bắt buộc cho một pipeline observability an toàn:

• PII redaction tại collector layer: OTel Collector có processor transform và attributes để match regex và mask trước khi ghi xuống storage. Không bao giờ tin client-side redaction.
• Encryption at rest: ClickHouse hỗ trợ encryption của disk và column-level encryption cho field nhạy cảm.
• Access control theo vai trò: Phân biệt quyền xem metadata (ai cũng xem được) và quyền xem raw prompt/response (chỉ on-call + senior).
• Data retention phù hợp: Dùng TTL của ClickHouse để tự động xóa trace cũ sau 30/60/90 ngày tùy chính sách.
• Audit log riêng: Mọi lượt truy cập prompt/response phải được log — đây là bằng chứng compliance khi audit.

13. Checklist triển khai production

Dưới đây là 12 điểm cần kiểm tra trước khi đưa pipeline observability lên production:

14. Kết luận — Observability là lớp hạ tầng không thể thiếu

Bước vào năm 2026, LLM Observability không còn là lựa chọn. Khi hệ thống AI của bạn có 5 agent trở lên, mỗi agent gọi LLM chục lần cho một request, và tổng chi phí LLM vượt 10.000 USD/tháng, bạn bắt buộc phải có một pipeline quan sát hoàn chỉnh nếu không muốn vận hành "mò trong bóng tối".

Kiến trúc được trình bày trong bài — OpenTelemetry GenAI + Langfuse + ClickHouse + Redis — là một stack open-source, tiết kiệm chi phí và đã được chứng minh ở quy mô lớn. Nó cho bạn ba thứ mà không có stack truyền thống nào làm được: (1) theo dõi đến từng token trong hệ thống multi-agent phức tạp, (2) kiểm soát chi phí LLM chính xác theo user và feature, (3) phát hiện regression chất lượng trước khi ảnh hưởng người dùng.

Nếu bạn đang xây dựng hệ thống AI production, hãy coi observability là lớp hạ tầng bắt buộc — ngang hàng với database và CI/CD — ngay từ sprint đầu tiên. Chi phí build một pipeline observability ở giai đoạn sớm thấp hơn 100 lần so với khi hệ thống đã scale và bạn phải đi ngược dòng để instrument lại toàn bộ code base.