AI đã thay đổi cách chúng ta xây dựng phần mềm, nhưng nó không làm thay đổi một sự thật cơ bản về máy móc. Chúng cũng bị ngập trong nhiễu giống như con người vậy. Khi các kỹ sư lần đầu thử nghiệm gỡ lỗi với sự hỗ trợ của AI, bản năng thường rất đơn giản: nạp mọi thứ vào mô hình. Các logs thô, traces và metrics đều được đổ hết vào cửa sổ ngữ cảnh (context window). Kết quả không phải là sự thấu hiểu, mà là sự thất bại. Khối lượng dữ liệu quá lớn. Tín hiệu bị sụp đổ. Các metrics nằm ở một công cụ, traces nằm ở một công cụ khác, và mô hình không thể kết nối chúng lại thành một câu chuyện mạch lạc. Trước khi AI có thể giúp bạn quan sát hệ thống, chính bạn phải quan sát chúng trước. Bạn phải định hình dữ liệu trước.

Tại sao Logs thô làm hỏng các Pipeline AI

Các hệ thống hiện đại tạo ra telemetry với tốc độ mà không con người nào có thể đọc hết. Điều đó đáng lẽ phải khiến chúng trở nên hoàn hảo cho trí tuệ nhân tạo. Nhưng thực tế không phải vậy. Cửa sổ ngữ cảnh của một mô hình ngôn ngữ lớn, dù đang ngày càng mở rộng, vẫn là một đường ống có giới hạn. Nếu bạn nhồi nhét vào đó các logs sản xuất chưa qua lọc, bạn sẽ lãng phí token vào các tín hiệu heartbeat của cron job và các nhiễu từ health-check, trong khi lại bỏ lỡ sự cố thực sự. Tệ hơn nữa, logs thô thiếu các mối quan hệ. Một sự gia tăng độ trễ vào lúc 2:00 chiều và một lỗi kết nối cơ sở dữ liệu trong một log tại cùng một mốc thời gian rõ ràng là có liên quan, nhưng trừ khi có ai đó đã cấu trúc mối quan hệ đó từ trước, nếu không AI sẽ phải tự đoán. Việc đoán mò rất tốn kém, chậm chạp và thường xuyên sai lầm.

Giải pháp nằm ở kiến trúc, không phải ở thuật toán. Bạn cần quyết định cái gì sẽ được thu thập, cách nó được định hình, và backend nào sẽ trả lời câu hỏi nào trước khi bạn bắt đầu đặt câu lệnh (prompt) cho mô hình.

Bốn trục Giám sát

Tại airCloset, đội ngũ kỹ sư đã ngừng coi observability như một dòng thác dữ liệu duy nhất. Họ chia việc giám sát thành bốn trục riêng biệt. Mỗi trục đảm nhận một hình thái cụ thể và trả lời một câu hỏi cụ thể.

  • Application: Logs và traces trả lời câu hỏi "Điều gì đang xảy ra ngay lúc này?"
  • Infrastructure: Metrics trả lời câu hỏi "Chúng ta có đủ tài nguyên không?"
  • CI: Logs và cảnh báo trả lời câu hỏi "Cái gì đã hỏng và khi nào?"
  • LLM: Metrics và các bản ghi có cấu trúc trả lời câu hỏi "Chúng ta đang chi tiêu bao nhiêu?"

Sự phân tách này rất quan trọng vì hình thái phù hợp cho một biểu đồ độ trễ thời gian thực sẽ trở nên vô dụng đối với việc phân tích chi phí sau đó. Việc ép buộc một schema duy nhất cho cả bốn lĩnh vực sẽ tạo ra chính loại nhiễu khiến sự hỗ trợ của AI trở nên vô dụng.

CI Observability: Kéo (Pull), đừng Đẩy (Push)

Tích hợp liên tục (Continuous integration) là nơi mã nguồn đối mặt với thực tế. Khi một bản build thất bại, các nhà phát triển cần biết câu chuyện đó thật nhanh. Cách tiếp cận ngây thơ là để CI runner đẩy trực tiếp logs vào backend observability của bạn khi nó đang chạy. Nghe có vẻ hiệu quả, nhưng thực tế lại rất nguy hiểm.

Tại airCloset, họ đã đảo ngược mô hình này. CI runner không chạm vào stack observability. Sau khi workflow của GitHub Actions kết thúc, họ kéo (pull) các logs từ GitHub API và nạp (ingest) chúng vào Loki.

Kiến trúc kéo này mang lại ba lợi ích cụ thể.

Decoupling. Nếu pipeline nạp dữ liệu gặp trục trặc hoặc Grafana không thể truy cập, bản thân quá trình chạy test sẽ không bị ảnh hưởng. Bản build thành công hay thất bại dựa trên chính giá trị của nó. Việc gặp lỗi ở hệ thống observability không bao giờ được phép làm gián đoạn quá trình triển khai.

Security. Workflow CI không bao giờ cần đến API key của Grafana. Mã kiểm thử vốn nổi tiếng với việc chạm vào những bí mật mà nó không nên, và việc loại bỏ sự tiếp xúc đó sẽ thu hẹp phạm vi ảnh hưởng nếu một dependency bị xâm nhập.

Cross-querying. Một khi CI