Observability cho Amazon Bedrock AgentCore: log và trace theo từng agent
Bedrock AgentCore tách log runtime khỏi trace span ra sao, vì sao cần bật CloudWatch Transaction Search, và log group theo agent không giải quyết được gì.

Thông tin cho rằng AWS đã cập nhật AgentCore để agent mới tạo ở các Region được hỗ trợ mặc định có CloudWatch log group riêng chưa được xác nhận bằng nguồn chính thống trong bản nháp này. Trước khi coi đó là hành vi mặc định đã công bố, hãy kiểm tra release notes AgentCore.
Transaction Search không tự bật. Hướng dẫn observability của AWS yêu cầu người dùng lần đầu bật tính năng này một lần và cho biết span có thể mất khoảng mười phút mới tìm kiếm được. Với workflow agent tự chủ, log và trace là bằng chứng để tái dựng lại quá trình lập kế hoạch, tool call, retry và bước human review. Khi phát triển AI agent cho production, cần xác định rõ các trạng thái workflow, quyền dùng tool, điểm duyệt (review gate) và đường khôi phục.
Điểm chính
- Đừng mặc định rằng mỗi agent có log group riêng; hãy xác minh trên runtime thực tế và đối chiếu release notes chính thức.
- Theo tài liệu AWS, runtime log và trace span được ghi về hai đích riêng.
- Phải bật Transaction Search thì mới tìm kiếm được trace của AgentCore.
- Cô lập theo agent giúp thu hẹp phạm vi debug và xác định rõ người sở hữu, nhưng truy vấn trên toàn fleet và chính sách vẫn phải tự thiết kế.
- SLO dựa trên trace, alert, retention, sampling và escalation là trách nhiệm của đội vận hành.
Điều gì thay đổi trong AgentCore observability
Nếu cấu hình hoặc hành vi mặc định đã được xác minh, ranh giới log riêng giúp điều tra từng agent, còn Transaction Search và CloudWatch GenAI observability giúp tìm trace. AWS cho biết: “After you enable Transaction Search, it can take ten minutes for spans to become available for search and analysis.”
| Thành phần | Nguồn AWS | Điều cần xác minh |
| ---------------- | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------ |
| Runtime log | CloudWatch log group theo runtime | Agent, endpoint và path thực tế |
| Trace span | /aws/spans/default | Transaction Search đã bật và indexing xong |
| Curated view | CloudWatch AgentCore docs | Điều tra được theo agent, prompt, session |
| Cost attribution | Không tự động | Người sở hữu, môi trường, usage, báo cáo |
Vì sao cô lập theo agent thay đổi vận hành production
Ranh giới log theo agent giúp thu hẹp phạm vi debug, phân quyền và trách nhiệm sở hữu. Nhưng nó không thay thế được danh mục (inventory) của toàn fleet. Hãy duy trì bảng ánh xạ giữa agent, endpoint, log group, người sở hữu workflow, tool hạ nguồn, đường escalation và runbook. Điều này đặc biệt quan trọng với agentic BI và báo cáo có khả năng quan sát, nơi một câu trả lời cuối trông hợp lý vẫn có thể che giấu truy vấn nguồn bị lỗi.
| Vấn đề | Cô lập giúp được gì | Kiểm soát vẫn cần có | | ------------ | ----------------------------- | --------------------------------- | | Incident | Khoanh đúng agent và endpoint | Trace, owner và runbook | | Permission | Hạn chế truy cập log | IAM, retention và redaction | | Cost | Điểm khởi đầu để phân bổ | Usage metadata và reporting | | Fleet search | Ngữ cảnh cục bộ rõ hơn | Inventory và truy vấn cross-agent |
Xem playbook escalation cho agent production để quyết định khi nào retry, fallback, dừng hay chuyển cho operator.
Trace phân tán làm lộ các kiểu lỗi của agent
Trace cho thấy quyết định của mô hình, tool call, thời gian chờ, retry, vòng lặp và các bước chuyển trạng thái trong workflow. Lỗi đọc vô hại có thể retry. Thao tác ghi có quyền hạn không rõ ràng phải dừng lại và đưa vào hàng đợi review. Human review cho hành động rủi ro của agent giúp gắn bằng chứng observability với thiết kế quy trình phê duyệt.
| Tín hiệu trace | Ý nghĩa | Phản ứng | | ---------------- | ----------------------------- | ----------------------------------- | | Tool fail | Dependency hoặc input lỗi | Retry, fallback hoặc escalation | | Repetition | Loop hoặc retry bất thường | Giới hạn loop và điều tra | | Missing evidence | Thiếu ngữ cảnh | Dừng và yêu cầu review | | Write có rủi ro | Quyền hoặc tác động mơ hồ | Không thực thi, chuyển human review | | Latency dài | Tool chờ hoặc workflow bị kẹt | Alert, timeout và fallback |
Checklist observability cho AgentCore trong production
Bắt đầu bằng kiến trúc triển khai rõ ràng
Hình 1. Runtime log và span là hai đường telemetry cần xác minh riêng.
Ứng dụng nên gắn tên workflow, môi trường, phiên bản triển khai, người sở hữu, session ID, trace ID, loại tool, trạng thái review và kết quả cuối cùng vào bằng chứng kỹ thuật. Chỉ xây alert dựa trên những field mà hệ thống thực sự phát ra.
Ghi lại kết quả xác minh triển khai thành tài liệu
Agent:
Endpoint:
Expected runtime log group:
Transaction Search enabled:
Spans searchable:
GenAI observability view checked:
Prompt or session trace checked:
Workflow owner:
Incident runbook:
Retention and sampling policy:
Log đã xuất hiện không có nghĩa là span đã tìm kiếm được; trace chưa có người sở hữu hoặc runbook thì cũng chưa sẵn sàng cho xử lý sự cố.
Xác định mục tiêu độ tin cậy dựa trên trace
| Khái niệm SLO | Đội cần quyết định | | ------------------ | ------------------------------------------ | | Hoàn tất workflow | Thế nào là kết quả kinh doanh đúng, dùng được | | Độ trễ end-to-end | Session được phép chạy bao lâu | | Kết quả tool | Khi nào retry, fallback hoặc escalation | | Repetition | Mẫu nào là loop thay vì retry hợp lệ | | Trace completeness | Bước chuyển nào phải thấy được để chẩn đoán | | Human escalation | Điều kiện nào thì dừng tự động hóa | | Recovery | Cách tiếp tục hoặc bù trừ sau thao tác lỗi |
Chỉ alert theo các triệu chứng cần hành động: tool lỗi đáng kể, workflow bị kẹt, thao tác lặp lại, độ trễ bất thường, thiếu bằng chứng hoặc fallback thất bại. Lưu trace ID trong hồ sơ sự cố.
Quản trị retention, sampling và dữ liệu nhạy cảm
Chính sách retention phải cân bằng giữa nhu cầu điều tra, nghĩa vụ pháp lý, rủi ro quyền riêng tư và chi phí. Chỉ nên sampling traffic thành công khi các lỗi vẫn chẩn đoán được. Prompt, input/output của tool và metadata của session có thể chứa dữ liệu nhạy cảm, vì vậy cần rà soát nội dung log, hạn chế quyền truy cập và che (redact) những gì operator không cần xem.
Van Data Team có thể cung cấp bản đồ ánh xạ giữa agent và tín hiệu, đánh giá khoảng trống của dashboard, SLO dựa trên trace, kế hoạch retention và runbook xử lý sự cố thông qua dịch vụ phát triển AI agent.
Lỗi phổ biến cần tránh
Đừng mặc định Transaction Search đã được bật, đừng kết luận cấu hình bị lỗi khi chưa hết thời gian indexing, đừng giả định mọi agent đều có log group riêng, đừng sửa các path mà AWS đã quy định trong tài liệu, đừng coi log group riêng là báo cáo chi phí tự động, đừng tự đặt tên metric hoặc ngưỡng, đừng đọc log mà không đối chiếu trace, và đừng giữ mọi span khi không có lý do rõ ràng về điều tra, quyền riêng tư và chi phí.
Tooling và độ phù hợp
AgentCore phù hợp khi runtime là AgentCore và CloudWatch đã là control plane. Tracing của framework hữu ích khi phát triển nhưng không nên là nguồn hồ sơ sự cố duy nhất. Tracing trung lập với nhà cung cấp phù hợp với hệ thống có nhiều runtime hoặc chạy trên nhiều cloud. Orchestration xử lý các bước bàn giao xác định (deterministic), retry và phê duyệt, còn vòng lặp tự chủ vẫn cần trace end-to-end. Hãy tiếp cận theo nhiều lớp: ranh giới log theo agent, trace trên toàn fleet và ngữ cảnh từ framework ở những chỗ có giá trị. Bật Transaction Search một lần và đưa khoảng trễ mười phút vào checklist triển khai.
Kết luận: đưa observability vào cam kết vận hành của runtime
AgentCore có thể tạo ra ranh giới vận hành gọn gàng hơn nếu cấu hình log group riêng đã được xác minh; trace giúp tái dựng các quyết định, tool call, hành vi lặp lại và bước chuyển trạng thái. Nhưng việc thiết lập không hoàn toàn tự động. Đội phải xác định người sở hữu, kiểm tra log và trace riêng biệt, đặt SLO theo workflow, chỉ alert các triệu chứng cần hành động, lưu trace ID, và thiết kế retry, fallback cùng human review. Mục tiêu không phải là có thêm telemetry, mà là có đủ bằng chứng đáng tin để giải thích, cô lập, khôi phục và phòng ngừa một lần chạy hỏng.

Nhà sáng lập Van Data Team, trực tiếp xây dựng Vanaxity và điều hành kỹ thuật dữ liệu, AI Agent cho các đội ngũ doanh nghiệp.
Về tác giảCâu hỏi thường gặp
Những câu hỏi người đọc thường đặt ra tiếp theo.
Các câu trả lời ngắn này làm rõ những câu hỏi thực tế thường xuất hiện sau khi đọc bài viết.
Bạn cần một hệ thống tương tự?
Nếu bài viết này phản ánh một quy trình đội ngũ bạn đang vận hành, bước tiếp theo thường là rà soát có phạm vi về hệ thống, ràng buộc và lộ trình triển khai.
Tư vấn
Xác định phạm vi cho quy trình AI tiếp theo.
Chia sẻ hệ thống và điểm nghẽn. Chúng tôi sẽ cùng làm rõ mức độ phù hợp, khoảng trống và bước tiếp theo.







