Giảm chi phí telemetry của AI agent bằng OpenTelemetry Collector

Adnan Rahic từ Bindplane by Dynatrace đã công bố một hướng dẫn thực tế vào ngày 22 tháng 10 năm 2026, chi tiết hóa cách tối ưu hóa các pipeline OpenTelemetry cho AI agents. Bài viết giải quyết vấn đề thường gặp trong môi trường production là lượng dữ liệu telemetry quá lớn được tạo ra bởi các công cụ như Claude Code, dẫn đến chi phí lưu trữ cao và độ cardinality khó kiểm soát.

Chuyện gì đã xảy ra

Việc bật telemetry cho một AI coding agent thường dẫn đến khối lượng dữ liệu khổng lồ, tốn kém để lưu trữ và khó diễn giải. Trong một trường hợp thử nghiệm nơi Claude Code sửa hai bài test lỗi và thêm các bài test biên (boundary tests), một lần chạy duy nhất đã tạo ra 181 bản ghi telemetry và 289 KB JSON. Dữ liệu này bao gồm toàn bộ prompt, nội dung file và diff, phần lớn trong số đó không cần thiết cho việc giám sát vận hành liên tục.

Vấn đề cốt lõi là instrumentation mặc định được thiết kế để debug từng phiên làm việc riêng lẻ của developer, chứ không phải để quản lý cả một đội hình agent. Ở quy mô lớn, chẳng hạn với 200 phiên mỗi ngày, phương pháp này trở nên không bền vững. Các metric mang những thuộc tính có độ cardinality cao như session ID và email người dùng, tạo ra hàng trăm chuỗi thời gian (time series) độc nhất vô nhị không bao giờ hết hạn. Ngoài ra, nội dung công cụ bị trùng lặp giữa traces và logs, làm phình to thêm yêu cầu về lưu trữ.

Rahic chứng minh rằng mục tiêu không phải là thu thập ít dữ liệu hơn một cách tùy tiện, mà là chỉ giữ lại những dữ liệu trả lời được các câu hỏi vận hành cụ thể. Bằng cách định hình dữ liệu trong OpenTelemetry Collector trước khi nó đến backend, các nhóm có thể giảm đáng kể chi phí mà không mất đi khả năng hiển thị đối với các chỉ số hiệu suất và chi phí quan trọng.

Cách thức hoạt động

Giải pháp liên quan đến việc cấu hình OpenTelemetry Collector để phân tán (fan out) mọi tín hiệu thành hai pipeline riêng biệt: một pipeline thô (raw) và một pipeline đã được tối ưu hóa. Cả hai pipeline đều nhận đầu vào giống hệt nhau từng byte từ một OTLP receiver duy nhất, đảm bảo sự so sánh chính xác. Pipeline thô đóng vai trò là nhóm đối chứng, chỉ chứa tên dịch vụ và một batch processor, trong khi pipeline tối ưu áp dụng các bộ lọc và biến đổi cụ thể.

Trong pipeline tối ưu, các processor loại bỏ các chiều dữ liệu có độ cardinality cao và nội dung thừa. Ví dụ, toàn bộ nội dung file từ đầu ra của công cụ được gỡ bỏ khỏi spans và logs, chỉ để lại metadata thiết yếu. Các metric được tổng hợp trước hoặc điều chỉnh để loại bỏ các định danh theo từng phiên gây ra sự bùng nổ cardinality. Điều này đảm bảo dữ liệu gửi đến backend gọn nhẹ và tập trung vào các insight có thể hành động được.

Cấu hình sử dụng Grafana LGTM cho cả hai pipeline để trực quan hóa sự khác biệt. Các dashboard so sánh cardinality, số byte mỗi phút và số lượng bản ghi song song. Trong môi trường production, pipeline thô có thể được chuyển hướng đến object storage để phục vụ việc debug sâu thỉnh thoảng, hoặc bị loại bỏ hoàn toàn, trong khi pipeline tối ưu cung cấp dữ liệu cho backend giám sát chính.

Chi tiết quan trọng

• Một lần chạy Claude Code duy nhất đã tạo ra 181 bản ghi telemetry và 289 KB JSON khi tất cả các cờ nội dung được bật.
• Metric mặc định bao gồm các thuộc tính có độ cardinality cao như session.id và user.email, tạo ra 300 chuỗi thời gian chỉ cho tám metric trên 25 phiên.
• Nội dung công cụ bị trùng lặp trong cả traces và logs, với nội dung file được lưu dưới dạng span events và log attributes.
• Pipeline tối ưu giảm số lượng chuỗi metric từ 300 xuống còn 12 bằng cách loại bỏ các chiều dữ liệu theo từng phiên.
• Sáu câu hỏi chính thúc đẩy việc tối ưu hóa: chi phí theo model, mức sử dụng token, tỷ lệ lỗi công cụ, tỷ lệ từ chối chỉnh sửa, độ trễ và lỗi.
• Metric otelcol_exporter_enqueue_size_bytes chỉ tồn tại ở mức chi tiết khi hàng đợi gửi (sending queue) được bật.

Tại sao điều này quan trọng

Đối với các nhóm kỹ thuật xây dựng ứng dụng với AI agents, chi phí telemetry có thể nhanh chóng vượt tầm kiểm soát nếu không được quản lý. Độ cardinality cao trong metrics dẫn đến tăng chi phí lưu trữ và truy vấn trên các nền tảng observability, trong khi payload trace và log lớn tiêu tốn băng thông và tài nguyên lập chỉ mục. Bằng cách lọc dữ liệu này ở cấp độ collector, các tổ chức có thể duy trì khả năng hiển thị toàn diện mà không phải chịu chi phí đắt đỏ của việc lưu trữ mọi prompt và file diff.

Hơn nữa, việc tập trung vào các câu hỏi vận hành cụ thể cải thiện tỷ lệ tín hiệu trên nhiễu (signal-to-noise ratio) cho developers và SREs. Thay vì sàng lọc qua những bức tường văn bản, các nhóm có thể giám sát các chỉ báo rõ ràng về hiệu suất của agent, chẳng hạn như mức sử dụng token theo loại, tỷ lệ thành công của công cụ và độ trễ. Sự chuyển đổi từ việc thu thập dữ liệu thô sang observability có mục tiêu giúp khắc phục sự cố nhanh hơn và quản lý chi phí hiệu quả hơn.

Bạn có thể làm gì

• Xác định sáu câu hỏi chính mà nhóm của bạn cần được trả lời về hiệu suất của AI agent, chẳng hạn như chi phí theo model và tỷ lệ lỗi công cụ.
• Cấu hình OpenTelemetry Collector của bạn để tạo các pipeline thô và tối ưu riêng biệt cho telemetry của AI agent.
• Loại bỏ các thuộc tính có độ cardinality cao như session IDs và email người dùng khỏi metrics để ngăn chặn sự bùng nổ chuỗi thời gian.
• Gỡ bỏ toàn bộ nội dung file và prompts khỏi trace spans và logs, chỉ giữ lại metadata thiết yếu và thông tin lỗi.
• Sử dụng các metric đã được tổng hợp trước khi có thể để giảm số lượng điểm dữ liệu gửi đến backend.
• Trực quan hóa sự khác biệt giữa luồng dữ liệu thô và đã tối ưu để xác nhận mức tiết kiệm lưu trữ và đảm bảo không mất dữ liệu quan trọng.