View a markdown version of this page

可觀測性和監控 - AWS 方案指引
要監控的關鍵可觀測性指標AWS 服務 用於觀察無伺服器和生成式 AI範例：監控以代理程式為基礎的支援工作流程可觀測性的最佳實務可觀測性和監控的摘要

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

可觀測性和監控

可觀測性對於大規模操作事件驅動、AI 驅動的系統至關重要。與單體應用程式不同，無伺服器和生成式 AI 系統是分散式、無狀態的，由暫時性運算和整合的 AI 服務 （例如 Amazon Bedrock 和 Amazon SageMaker) 組成。這些特性需要對可見性、相互關聯性和責任性進行新的思考。

如果沒有可觀測性，團隊會面臨下列問題：

  • 執行和客服人員行為中的盲點

  • 未偵測到的成本異常或效能迴歸

  • 對模型輸出和大型語言模型 (LLM) 品質的有限洞察

  • 跨非同步工作流程的根本原因分析有困難

可觀測性在無伺服器 AI 的下列領域中扮演重要角色：

  • AI 輸出 – LLMs 是非確定性的。記錄和檢查其輸出是驗證其隨時間的正確性的唯一方法。

  • 無伺服器執行 – AWS Lambda、 AWS Step Functions和 Amazon EventBridge 不會在固定主機上執行。監控需要以追蹤為基礎，而不是以伺服器為基礎。

  • 成本和延遲 – Amazon Bedrock 用量是以權杖為基礎。Lambda 和 Step Functions 會依持續時間和執行收費。

  • 安全性與控管 – 必須稽核提示日誌、客服人員工具用量和 API 呼叫，並將其範圍限定為身分和角色內容。

  • 使用者體驗 – 失敗、延遲或幻覺會影響信任。及早偵測這些問題是維持使用者對 AI 系統信心的關鍵。

要監控的關鍵可觀測性指標

下表說明與可觀測性和監控相關的關鍵指標的重要性。

指標類別

指標

為什麼指標很重要

代理程式行為

  • 工具選擇率

  • 無效的工具叫用

顯示意圖和動作之間的不一致。

成本趨勢

每個使用者或工作階段的推論成本

啟用 FinOps 報告和分層模型路由決策。

呼叫指標

  • Lambda 調用

  • 錯誤率

  • 冷啟動

驗證管道穩定性和錯誤彈性。

知識庫擷取

  • 命中/命中率

  • 接地相關性分數

測量 RAG 管道的效能。

延遲

每個模型的推論延遲

  • 偵測 Amazon Bedrock 或 SageMaker 中的減速。

  • 最佳化使用者回應時間。

提示和回應品質

  • 幻覺率

  • 備用速率

確保接地正常運作，並且提示如預期般運作。

安全與存取

依 IAM 角色的代理程式和工具用量

確保最低權限和可追蹤性的原則。

字符用量

輸入和輸出字符總數 (Amazon Bedrock)

  • 控制成本。

  • 偵測提示膨脹或模型濫用。

工作流程運作狀態

Step Functions 工作流程失敗、重試和逾時

表面協同運作問題和重試迴圈。

AWS 服務 用於觀察無伺服器和生成式 AI

下表說明支援無伺服器和生成式 AI 應用程式可觀測性的 AWS 服務 和 功能，包括其理想的使用案例。

AWS 服務

Description

理想的使用案例

Amazon CloudWatch Logs

從 Lambda、Step Functions、Amazon Bedrock Agents 和 Amazon API Gateway 擷取日誌

  • 除錯

  • 稽核線索

  • 使用者工作階段追蹤

Amazon CloudWatch 指標

自訂和服務產生的金鑰效能指標 KPIs)，例如調用計數、持續時間和字符計數

  • 儀表板

  • Alerts (提醒)

  • 趨勢分析

AWS X-Ray

跨無伺服器流程的追蹤，包括 Lambda、API Gateway 和 Step Functions

  • 根本原因分析

  • 延遲追蹤

  • 相依性映射

CloudWatch 內嵌指標格式

日誌串流中進階指標的結構化記錄

啟用無需個別指標呼叫的分析

Amazon Bedrock 代理程式追蹤和模型調用記錄

原生 Amazon Bedrock 代理程式執行追蹤、工具呼叫和 RAG 洞察

監控代理程式行為並故障診斷失敗

Amazon EventBridge 管道和結構描述登錄檔

追蹤和驗證流經管道的事件格式

  • 防止格式不正確的事件

  • 確保合約一致性

AWS CloudTrail

記錄所有 API 呼叫和身分內容

  • 合規

  • 安全性稽核

  • 依角色區分的代理程式和工具用量

Amazon OpenSearch Service

索引推論回應、結構化日誌或稽核記錄

  • 回應的語意搜尋

  • 可觀測性儀表板

Amazon CloudWatch Synthetics

模擬流量以主動測試端點或工作流程

確保跨版本的執行時間和迴歸監控

範例：監控以代理程式為基礎的支援工作流程

若要有效監控以代理程式為基礎的支援工作流程，請考慮在其相關聯的工作流程階段使用以下指標：

  1. API Gateway 的使用者查詢 – 監控回應時間和 5xx 錯誤。

  2. 預處理器 Lambda 函數 – 監控冷啟動和剖析失敗。

  3. Amazon Bedrock 代理程式 – 監控提示、工具呼叫追蹤、字符成本和延遲。

  4. 工具 Lambda 函數 （例如 getOrderStatus) – 監控每個使用者的執行時間和工具叫用計數。

  5. 透過知識庫的 RAG 查詢 – 監控相關性分數和缺少基礎。

  6. 後處理器 Lambda 函數 – 監控結構描述驗證和備用觸發。

  7. 日誌 CloudWatch 和 OpenSearch – 監控工作階段日誌、追蹤 IDs和模型回應品質。

  8. 警示 – 監控高故障率、每個工作階段成本激增和延遲降低的警示。

可觀測性的最佳實務

在無伺服器和生成式 AI 工作流程中，請考慮下列可觀測性的最佳實務：

  • 使用結構化日誌檢測 AI 流程，以啟用跨元件的相互關聯 （例如，使用者工作階段、追蹤 ID 和模型回應）。

  • 使用一致的記錄結構描述來支援下游剖析、警示和分析管道。

  • 每層發出自訂指標，以協助追蹤與基礎設施問題相比的模型相關錯誤。

  • 使用環境和內容標記日誌，以依使用者角色、區域、版本或團隊啟用篩選。

  • 使用異常偵測警示來偵測字符突增、延遲峰值或輸出偏離。

  • 將 LLM 回應日誌與下游影響相關聯，將代理程式輸出連結至決策、呈報或失敗。

  • 透過具有提示成本、模型使用率和備用率的每週儀表板自動化報告產生，以推動責任和改進週期。

可觀測性和監控的摘要

在 AI 驅動的無伺服器系統中，您不監控主機。反之，您可以監控行為、成本和正確性。可觀測性提供營運彈性、成本控制和預測、LLM 效能評估、控管和合規，以及持續提示和客服人員改善的基礎。

原生 AWS 服務 支援可觀測性和監控，以及結構化的事件感知遙測，可提供必要的功能。透過這些功能，團隊可以放心地大規模操作 AI 工作負載，並了解發生的情況、位置和原因。