OpenTelemetry cho ứng dụng LLM: một lần đo, gửi trace sang cả Datadog lẫn Langfuse tự host

Tháng 12/2025, Datadog thông báo sản phẩm LLM/Agent Observability của mình hỗ trợ native OpenTelemetry GenAI Semantic Conventions, áp dụng cho bộ quy ước từ phiên bản 1.37 trở lên.

Nghe như một dòng changelog, nhưng nó gỡ một nút thắt mà FDE nào làm dự án LLM cho doanh nghiệp cũng dễ gặp: đội vận hành của khách đã dùng Datadog, còn đội dữ liệu lại muốn giữ trace trong một Langfuse tự host.

Nếu mỗi backend đòi một SDK riêng, code ứng dụng sẽ dính chặt vào vendor đó. Một chuẩn chung làm thay đổi bài toán: Langfuse cũng tuyên bố nhắm tới tuân thủ cùng bộ quy ước GenAI của OpenTelemetry, nên một lần instrument có thể phục vụ cả hai phía.

Đây đúng là việc FDE hay phải làm ở site khách: thiết kế pipeline sao cho quyết định chọn công cụ của khách không kéo theo việc viết lại code ứng dụng.

OTel GenAI thực ra chuẩn hóa cái gì?

OpenTelemetry vốn là chuẩn mở cho trace, metric và log. Phần GenAI bổ sung một bộ tên thuộc tính thống nhất cho các lời gọi mô hình, để backend nào nhận trace cũng hiểu span nào là lời gọi LLM và thuộc tính nào chứa thông tin gì.

Nguồn chính thức cần đọc đã chuyển chỗ. Các quy ước GenAI được tách khỏi repo semantic-conventions chung sang một repo riêng, semantic-conventions-genai, bao gồm spans, metrics và events cho GenAI client. Khi tranh luận với khách về một tên thuộc tính, hãy dẫn link repo mới này, đừng dẫn trang cũ.

Datadog mô tả cách dùng khá gọn: instrument ứng dụng LLM một lần bằng OTel, rồi xuất GenAI span qua pipeline OTel Collector sẵn có. Tài liệu của hãng còn nói rõ có thể gửi trace OTel thẳng vào mà không cần SDK Agent Observability hay Datadog Agent.

Khi nào FDE nên dùng nó ở site khách?

Thử hình dung một khách hàng ngân hàng. Đội SRE muốn thấy độ trễ của agent ngay cạnh dashboard hạ tầng trên Datadog. Đội AI muốn đọc từng prompt và câu trả lời trong Langfuse chạy trên hạ tầng nội bộ. Nếu bạn cài hai SDK, mỗi thay đổi framework sẽ phải sửa hai lần, còn hai bên sẽ nhìn hai bức tranh lệch nhau.

Cách gọn hơn: instrument theo OTel GenAI, đẩy tất cả về một OTel Collector, rồi để Collector chia cùng một trace thành hai nhánh song song. Cách này càng hợp khi khách chưa chốt vendor, vì đổi backend về sau chỉ là sửa cấu hình exporter.

Một cấu hình Collector tối thiểu

Cấu hình xoay quanh hai chi tiết. Datadog định tuyến span OTLP vào Agent Observability nhờ header dd-otlp-source=llmobs. Langfuse, kể cả bản tự host, nhận trace OTLP tại endpoint /api/public/otel. Phác thảo có thể trông như sau, với endpoint và header xác thực điền theo tài liệu của từng bên:

receivers:
  otlp:
    protocols:
      http:
      grpc:

exporters:
  otlphttp/datadog:
    endpoint: <DATADOG_OTLP_ENDPOINT>
    headers:
      dd-otlp-source: llmobs
      # thêm header API key theo tài liệu Datadog
  otlphttp/langfuse:
    endpoint: <LANGFUSE_HOST>/api/public/otel
    headers:
      # thêm header xác thực theo tài liệu Langfuse

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlphttp/datadog, otlphttp/langfuse]

Với Langfuse, otlphttp là bắt buộc. Langfuse hỗ trợ OTLP qua HTTP, với cả HTTP/JSON lẫn HTTP/protobuf, nhưng chưa hỗ trợ gRPC.

Với Datadog thì khác: chọn otlphttp trong phác thảo này là để hai nhánh dùng chung một kiểu exporter, dễ đọc và dễ dò lỗi hơn, chứ không phải ràng buộc từ phía Langfuse. Nếu pipeline sẵn có của khách đã đẩy trace sang Datadog bằng exporter khác và đang chạy ổn, cứ giữ nguyên nhánh đó, chỉ thêm riêng một exporter HTTP cho Langfuse.

Giao thức Datadog chấp nhận ở endpoint của khách thì kiểm tra trong tài liệu Datadog trước khi đổi bất cứ thứ gì.

Kiểm tra trước khi báo xong

Đừng dừng ở chỗ Collector khởi động không báo lỗi. Hãy gửi đúng một lời gọi LLM thử từ ứng dụng, rồi mở cả hai backend để tìm trace đó: Datadog ở màn hình LLM/Agent Observability, Langfuse ở danh sách trace của project.

Nếu trace chỉ hiện ở một bên, lỗi đã được khoanh vùng sẵn. Thiếu ở Langfuse thì xem lại giao thức HTTP, đường dẫn /api/public/otel và phiên bản đang chạy. Thiếu ở màn hình LLM của Datadog thì xem lại header dd-otlp-source và chuẩn quy ước mà framework phát ra.

Ba cái bẫy trước buổi demo

Bẫy đầu tiên là gRPC, như đã nói ở trên. Bẫy thứ hai là phiên bản: Langfuse khuyên ai tự host mà gặp lỗi 4xx trên endpoint OTel thì nâng cấp lên bản mới nhất, và trang tài liệu ghi bản triển khai local cần từ v3.22.0 trở lên. Trước khi đổ lỗi cho cấu hình Collector, hãy hỏi khách đang chạy Langfuse bản nào.

Bẫy thứ ba nằm ở framework. Nhiều thư viện ra đời trước bản 1.37 của quy ước. Tài liệu Datadog hướng dẫn đặt biến môi trường OTEL_SEMCONV_STABILITY_OPT_IN để chúng phát trace tương thích 1.37+. Nếu Datadog nhận span nhưng không hiện trong màn hình LLM, đây là chỗ đầu tiên nên kiểm tra.

Cũng nên biết Datadog chấp nhận cả trace theo quy ước OpenInference, không chỉ OTel GenAI. Điều đó giúp khi khách đã instrument theo OpenInference, nhưng đừng coi đó là bảo đảm Langfuse sẽ hiểu y hệt. Điểm chung chắc chắn của hai bên là OTel GenAI.

Học gì trước?

Hãy bắt đầu từ OTel Collector, không phải từ dashboard. Hiểu receiver, exporter và pipeline là đủ để dựng cấu hình trên trong một buổi chiều. Sau đó đọc phần spans trong repo semantic-conventions-genai và đối chiếu với trace thật mà framework của bạn phát ra.

Khi đọc JD của các vị trí FDE, để ý những cụm như “observability”, “OpenTelemetry”, “LLM tracing”. Trong CV, một dòng như “dựng pipeline trace LLM theo OTel GenAI, xuất song song sang Datadog và Langfuse tự host” nói nhiều hơn danh sách tên công cụ.

Nếu khách còn đang cân nhắc công cụ observability, đừng đợi họ chốt. Một pipeline OTel đúng chuẩn cho phép bạn bắt đầu thu trace ngay hôm nay và để cuộc tranh luận đó diễn ra trong file YAML.