Giám sát AI Agent với CloudWatch

Ghi lại mọi lượt gọi agent vào cơ sở dữ liệu không phải là giám sát. Đó chỉ là lưu trữ.

Nếu bạn cần chạy các truy vấn SQL vào lúc 2 giờ sáng để xem liệu bộ tóm tắt (summarizer) của mình có bị chậm hay không, nghĩa là bạn đã thất bại trong việc thiết lập khả năng quan sát (observability). Bạn cần các dashboard và cảnh báo (alarms), chứ không phải các dòng dữ liệu trong cơ sở dữ liệu.

Tôi đã tìm ra hai cách để giám sát các AI agent mà không làm tăng độ trễ hoặc làm phức tạp hóa mã nguồn.

1. Sử dụng Metric Filters cho các kịch bản lỗi (Failure Modes)

Các kịch bản lỗi như giới hạn ngân sách (budget caps) hoặc throttling dịch vụ không nên bị bỏ qua. Đừng viết thêm mã mới để gọi một API. Thay vào đó, hãy sử dụng các log hiện có của bạn.

Khi chạm giới hạn ngân sách, mã của bạn sẽ ghi lại một lỗi. Bạn có thể thiết lập một CloudWatch Metric Filter để quét các log đó. Nếu khớp với mẫu (pattern), CloudWatch sẽ tăng một metric.

Phương pháp này rất rẻ. Nó không yêu cầu thêm quyền IAM và không gây ra bất kỳ độ trễ nào cho agent của bạn.

Sử dụng cho:

  • Đạt giới hạn chi phí hàng tháng
  • Các lỗi throttling của Bedrock
  • Các lỗi agent chung

2. Sử dụng EMF cho dữ liệu hiệu suất

Nếu bạn muốn theo dõi độ trễ, mức sử dụng token hoặc chi phí trên mỗi agent, Metric Filters là không đủ. Bạn cần các dimension.

Đừng sử dụng PutMetricData. Đó là một lệnh gọi mạng đồng bộ (synchronous). Nó làm tăng thêm từ 30ms đến 80ms cho yêu cầu của bạn. Nó cũng có thể thất bại nếu bản thân CloudWatch đang bị quá tải.

Thay vào đó, hãy sử dụng Embedded Metric Format (EMF).

Bạn chỉ cần viết một dòng JSON duy nhất ra stdout. CloudWatch sẽ tự động trích xuất chúng thành các metric kèm theo các dimension.

Với một dòng JSON, bạn sẽ có:

  • Tổng số lần gọi (invocations)
  • Tỷ lệ lỗi
  • Độ trễ (P95)
  • Token đầu vào và đầu ra
  • Chi phí trên mỗi model và mỗi agent

Các quy tắc để có khả năng quan sát hiệu quả

  • Xuất một dòng và để CloudWatch làm phần việc còn lại.
  • Đừng bao giờ để telemetry làm hỏng agent của bạn. Hãy bao bọc các lệnh gọi metric trong các khối try-except.
  • Cảnh báo dựa trên các đợt bùng phát (bursts), chứ không phải các sự kiện đơn lẻ. Một lần bị throttle là bình thường. Mười lần bị throttle trong năm phút là một sự cố.
  • Sử dụng dimension cho các agent cụ thể, nhưng sử dụng các giá trị tổng hợp (aggregates) cho độ trễ trên toàn hệ thống.
  • Khớp các lỗi theo mã (code), không phải theo chuỗi văn bản (text strings).

Bạn có thể xây dựng một hệ thống giám sát chuyên nghiệp với chi phí 0$ chỉ bằng cách sử dụng logs và EMF.

Source: https://dev.to/aws-builders/monitorear-agentes-de-ia-con-cloudwatch-45c4

Optional learning community: https://t.me/GyaanSetuAi