Lỗ hổng âm thầm trong việc theo dõi và tình trạng phình to ổ đĩa khi tự host Langfuse

Một nhà phát triển đã phát hiện ra rằng nền tảng quan sát (observability) Langfuse tự host của họ chỉ thu thập được một phần nhỏ hoạt động của AI agent, dẫn đến dữ liệu hiệu suất gây hiểu lầm. Cuộc điều tra cho thấy những sơ suất trong cấu hình đã gây ra các lỗi giám sát âm thầm trên hầu hết các hồ sơ agent, trong khi cơ sở dữ liệu nền tảng tích lũy hàng gigabyte nhật ký nội bộ không cần thiết.

Chuyện gì đã xảy ra

Vấn đề được phát hiện khi một AI agent mất tới hai mươi lăm phút để phản hồi một lệnh đơn giản là đăng bài trả lời trên diễn đàn. Thay vì thực thi tác vụ, mô hình lại tạo ra một bản tóm tắt bịa đặt về bài viết mục tiêu. Nhà phát triển đã tham khảo các trace Langfuse để chẩn đoán độ trễ, với kỳ vọng sẽ thấy vấn đề nằm ở độ trễ mạng hoặc nút thắt cổ chai trong việc thực thi công cụ. Dữ liệu trace cho thấy các công cụ web được thực thi trong vòng chưa đầy năm giây, trong khi mô hình ngôn ngữ cục bộ mất hơn hai mươi lăm phút để xử lý. Nguyên nhân gốc rễ không phải là hiệu suất mà là ngữ cảnh: phiên làm việc của agent đã bắt đầu trước khi kỹ năng đăng bài khả dụng, khiến mô hình phải ứng biến thay vì sử dụng công cụ bị thiếu.

Sự cố này đã thúc đẩy một cuộc kiểm toán sâu hơn đối với thiết lập quan sát. Nhà phát triển so sánh số lượng phiên được ghi lại trong cơ sở dữ liệu nội bộ của agent với các trace được lưu trữ trong Langfuse trong khoảng thời gian mười bốn ngày. Agent đã thực hiện 1.387 lần gọi mô hình qua 188 phiên, nhưng Langfuse chỉ chứa 618 sự kiện từ 79 trace. Phân tích thêm cho thấy việc theo dõi (tracing) chỉ được bật trên một trong mười hồ sơ agent, nghĩa là hệ thống chỉ giám sát khoảng 7% tổng lưu lượng. Các hồ sơ hoạt động mạnh nhất, bao gồm những hồ sơ dành cho tác vụ lập trình và bảo mật, hoàn toàn vô hình đối với nền tảng quan sát.

Phát hiện lớn thứ hai liên quan đến mức tiêu thụ dung lượng lưu trữ. Langfuse phiên bản 3 sử dụng ClickHouse làm kho lưu trữ trace chính, cùng với PostgreSQL và Redis. Trong khi dữ liệu trace thực tế chỉ chiếm 2,2 MiB, instance ClickHouse đang sử dụng hơn 6 GiB không gian ổ đĩa. Phần lớn không gian này bị chiếm bởi các bảng hệ thống chẩn đoán của riêng ClickHouse, chẳng hạn như nhật ký trace và nhật ký metric, vốn được ghi liên tục. Việc ghi log quá mức này tạo ra chi phí I/O đáng kể trên máy chủ, góp phần gây ra các đợt bão hiệu suất định kỳ trên ổ cứng.

Chi tiết chính

• Việc theo dõi chỉ hoạt động trên một trong mười hồ sơ agent, ghi lại khoảng 7% tất cả các lần gọi mô hình.
• Các hồ sơ không được theo dõi bao gồm các agent khối lượng cao cho tác vụ lập trình, bảo mật và quản trị IT.
• Nhật ký hệ thống ClickHouse chiếm 6,03 GiB không gian ổ đĩa, trong khi dữ liệu trace thực tế chỉ dùng 2,2 MiB.
• Plugin theo dõi thất bại âm thầm khi thiếu API key, không cung cấp bất kỳ thông báo lỗi hay cảnh báo nào trong log.
• Các job chạy một lần (one-shot jobs) ở chế độ an toàn bỏ qua hoàn toàn các plugin, đòi hỏi phải tích hợp SDK riêng biệt cho việc theo dõi.
• Việc xóa các bảng nhật ký hệ thống ClickHouse thông qua cấu hình sẽ ngăn chặn các ghi mới nhưng không tự động xóa dữ liệu hiện có.

Bối cảnh

Langfuse là một nền tảng quan sát mã nguồn mở được thiết kế cho các ứng dụng mô hình ngôn ngữ lớn. Nó giúp các nhà phát triển theo dõi chi phí, độ trễ và phản hồi của người dùng bằng cách ghi lại các trace về tương tác giữa các agent và mô hình. Việc tự host Langfuse mang lại cho các đội ngũ quyền kiểm soát dữ liệu của họ nhưng đòi hỏi phải quản lý cơ sở hạ tầng nền tảng, bao gồm cả lớp cơ sở dữ liệu. Trong phiên bản 3, Langfuse dựa vào ClickHouse, một hệ quản trị cơ sở dữ liệu định hướng cột được tối ưu hóa cho xử lý phân tích trực tuyến (OLAP). ClickHouse rất mạnh mẽ trong việc xử lý lượng lớn dữ liệu chuỗi thời gian nhưng bao gồm các tính năng ghi log nội bộ rộng rãi để giám sát hiệu suất và hoạt động của chính nó.

Các mẫu thiết kế fail-open (mở khi lỗi) phổ biến trong các plugin phần mềm nhằm đảm bảo rằng một phụ thuộc bị thiếu không làm sập ứng dụng chính. Trong bối cảnh này, nếu plugin theo dõi không thể tìm thấy thông tin xác thực API hợp lệ, nó đơn giản là tự vô hiệu hóa thay vì ném ra lỗi. Mặc dù điều này ngăn chặn việc sập ứng dụng, nó tạo ra một điểm mù nơi việc giám sát dừng lại mà không cảnh báo cho người vận hành. Hiểu rõ sự khác biệt giữa lỗi cấp ứng dụng và các lỗ hổng cấu hình âm thầm là yếu tố then chốt để duy trì khả năng quan sát đáng tin cậy trong các hệ thống phân tán.

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

Đối với các đội ngũ vận hành cơ sở hạ tầng AI riêng, khả năng quan sát không đầy đủ có thể dẫn đến những kết luận sai lệch về hiệu suất và chi phí hệ thống. Trong trường hợp này, ban đầu nhà phát triển nghi ngờ các vấn đề về mạng do thời gian phản hồi dài, nhưng trace đã tiết lộ rằng vấn đề nằm ở suy luận của mô hình trong một phiên cũ. Nếu việc theo dõi được kích hoạt trên agent lập trình, vốn chiếm phần lớn các lần gọi, đội ngũ đã có thể thấy tần suất các mô hình cục bộ gặp phải độ trễ đuôi (latency tails) so với các giải pháp đám mây. Nếu không có việc theo dõi toàn diện, các quyết định phân bổ tài nguyên sẽ dựa trên thói quen thay vì dữ liệu, có khả năng dẫn đến việc sử dụng kém hiệu quả các tài nguyên GPU đắt đỏ hoặc API đám mây.

Quản lý dung lượng lưu trữ là một mối lo ngại thực tế khác đối với các dịch vụ tự host. Nhật ký chẩn đoán hữu ích cho việc khắc phục sự cố hiệu suất cơ sở dữ liệu, nhưng chúng có thể nhanh chóng làm quá tải các triển khai quy mô nhỏ. Khi nhật ký nội bộ chiếm dụng không gian gấp hàng nghìn lần so với dữ liệu ứng dụng thực tế, chúng làm giảm hiệu suất ổ đĩa và tăng thời gian sao lưu. Đối với các nhà vận hành quản lý homelab hoặc cụm máy chủ nhỏ, sự tăng trưởng log không được kiểm soát có thể gây ra gián đoạn dịch vụ hoặc đòi hỏi phải dọn dẹp thủ công thường xuyên. Cấu hình cơ sở dữ liệu để chỉ giữ lại dữ liệu vận hành liên quan đảm bảo rằng nền tảng quan sát vẫn nhẹ nhàng và bền vững.

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

• So sánh số lượng yêu cầu được ghi lại trong nhật ký ứng dụng của bạn với số lượng trace trong nền tảng quan sát để xác định các lỗ hổng về phạm vi phủ sóng.
• Xác minh rằng API key và plugin theo dõi được cấu hình cho mọi hồ sơ agent, worker và dịch vụ, chứ không chỉ mặc định.
• Gửi một yêu cầu thử nghiệm từ mỗi hồ sơ agent riêng biệt và xác nhận rằng một trace được gắn thẻ đã được tạo.
• Xóa các bảng nhật ký hệ thống ClickHouse thông qua cấu hình để ngăn chặn các ghi mới, đồng thời lên kế hoạch dọn dẹp dữ liệu cũ nếu cần.