Thứ Ba tuần trước, một khách hàng hỏi mình tại sao kênh Slack debug agent của họ lại pin tới ba dashboard khác nhau — một cho agent chạy Bedrock, một cho service LangGraph trên ECS, và một board Grafana ai đó tự dựng tay cho prototype Strands. Không ai trả lời được trong vòng năm phút là trace nào thuộc về tool call nào bị lỗi. Đó chính xác là vấn đề mà AWS nói họ đã giải quyết ngày 23/9 với CloudWatch Omni.

Thực sự đã ra mắt gì

CloudWatch Omni được xây trên OpenTelemetry thay vì hệ instrumentation độc quyền cũ của AWS — đây là chi tiết quan trọng nhất. Nó thu thập trace xuyên account, và đáng chú ý là xuyên cả cloud khác — bạn không bị khóa vào toàn bộ stack AWS mới có được một màn hình tổng hợp duy nhất. Region ra mắt là us-east-1, us-west-2, eu-west-1, nên nếu workload của bạn nằm ở ap-southeast-1 thì phải chờ.

Hai tính năng đáng để nâng cấp riêng nó:

  1. Truy vấn ngôn ngữ tự nhiên qua DevOps Agent — gõ “tại sao checkout agent retry 4 lần lúc 14:02” thay vì tự viết query CloudWatch Logs Insights.
  2. Eval-driven observability native cho LangGraph, CrewAI, OpenAI Agents SDK, và Strands của chính AWS. Đây là phần thực sự mới: thay vì gắn eval như một pipeline riêng, Omni coi điểm eval là một span attribute hạng nhất, ngang hàng với latency và token count.

Còn có extension IDE cho VS Code, Cursor, Kiro, nên bạn nhảy thẳng từ trace lỗi đến đúng dòng code agent đã kích hoạt nó.

Vì sao OpenTelemetry-first mới là câu chuyện thật

Vendor observability nào giờ cũng claim hỗ trợ OTel — Cloudflare, Datadog, Honeycomb, tất cả. Điểm khác ở đây là AWS — chính cái vendor đã dành cả thập kỷ đẩy bạn vào định dạng metric độc quyền của CloudWatch — giờ vừa thừa nhận agent không tôn trọng ranh giới account, chứ đừng nói ranh giới cloud. Một request của user có thể nhảy từ agent Bedrock, sang Lambda tool call, sang API ngoài chạy trên GCP, sang query Snowflake. Nếu công cụ observability của bạn mặc định mọi thứ nằm trong một account AWS, bạn đang mù trước cả nửa lưu lượng production.

Thực hành: nối một Strands agent vào Omni

Đây là setup tối thiểu, giả sử bạn đã có agent AWS Strands chạy sẵn:

from strands import Agent
from strands.telemetry import OmniExporter

agent = Agent(
    name="checkout-agent",
    telemetry=OmniExporter(
        eval_hooks=["tool_call_success", "hallucination_check"],
        cloudwatch_omni=True,
    ),
)

@agent.tool
def charge_card(order_id: str, amount: float) -> dict:
    # Omni tự động gắn eval score vào span này
    # nếu bạn đã đăng ký tool_call_success ở trên
    return payment_client.charge(order_id, amount)

Dòng eval_hooks là phần người ta hay bỏ qua rồi tiếc. Không có nó, Omni chỉ cho bạn một trace OTel bình thường — vẫn hữu ích, nhưng không khác gì Honeycomb đã làm. Có nó, mỗi span mang một tín hiệu pass/fail mà kỹ sư trực có thể lọc thẳng: eval:tool_call_success=false AND service:checkout-agent.

Chỗ nó chưa xong

Ba region lúc ra mắt là một giới hạn thật nếu bạn chạy ở châu Á - Thái Bình Dương — bạn sẽ phải proxy telemetry xuyên region trong nhiều tháng, nghịch lý là chính điều đó lại thêm latency cho pipeline observability. Việc đăng ký eval-hook cũng đang gắn chặt vào từng framework; nếu bạn tự viết agent loop tay mà không phải LangGraph, CrewAI, Strands, hay OpenAI Agents SDK, bạn vẫn phải tự viết OTel span, y như trước khi có Omni.

Còn truy vấn ngôn ngữ tự nhiên thì vẫn là tính năng demo cho tới khi nó không còn là demo nữa. Mình test nó với một bộ trace giả lập, nó xử lý ổn các câu hỏi đơn giản kiểu “cho tôi xem tool call chậm nhất hôm nay”, nhưng vấp ngay khi có so sánh thời gian (“so sánh error rate hôm nay với thứ Ba tuần trước”) — nó chỉ chạy lại y hệt query của hôm nay hai lần. AWS chắc sẽ sửa. Nhưng hiện tại thì chưa.

Quyết định thực sự cho team bạn

Nếu bạn đã chạy từ hai framework agent trở lên, xuyên nhiều account, thì nên chuyển. Nền tảng OTel một mình nó đã đáng, kể cả bỏ qua tính năng NL query — nghĩa là công cụ observability tiếp theo bạn đánh giá, dù là Omni hay thứ khác, đều đọc được cùng bộ trace mà không cần một dự án re-instrument từ đầu.

Nếu bạn single-cloud, single-framework, và dashboard CloudWatch hiện tại vẫn ổn, thì chưa có gì cháy nhà ở đây cả. Chờ danh sách region mở rộng và hỗ trợ eval-hook rộng hơn trước khi bỏ một sprint vào migration. Vấn đề mà CloudWatch Omni giải quyết là có thật — quý này mình đã thấy ba khách hàng khác nhau vướng phải nó — nhưng “vấn đề có thật” và “vấn đề cấp bách” không phải một, và với nhiều team đây vẫn là cái thứ hai đang chờ trở thành cái thứ nhất.

Một điều nữa cần tính trước khi bỏ giờ công vào: chuyển từ metric CloudWatch độc quyền sang span OTel không miễn phí, kể cả khi đích đến tốt hơn. Dashboard cũ xây trên metric filter của CloudWatch không tự động port sang — phải có người xây lại theo schema span mới, và theo kinh nghiệm của mình, người đó thường là ai kêu ca to nhất khi dashboard cũ hỏng đầu tiên. Nên dành ra một tuần cho việc xây lại đó, không phải một ngày, và báo cho đội trực trước khi bật công tắc, chứ đừng đợi đến sự cố đầu tiên khi runbook cũ không còn khớp với những gì hiện trên màn hình.

Xuất nội dung

Bình luận