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

# 可觀測性和監控
<a name="observability-and-monitoring"></a>

可觀測性對於大規模操作事件驅動、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 系統信心的關鍵。

## 要監控的關鍵可觀測性指標
<a name="section-observability-key-metrics"></a>

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


| 
| 
| **指標類別** | **指標** | **為什麼指標很重要** | 
| --- |--- |--- |
| 代理程式行為 |   工具選擇率   無效的工具叫用   | 顯示意圖和動作之間的不一致。 | 
| 成本趨勢 | 每個使用者或工作階段的推論成本 | 啟用 FinOps 報告和分層模型路由決策。 | 
| 呼叫指標 |   Lambda 調用   錯誤率   冷啟動   | 驗證管道穩定性和錯誤彈性。 | 
| 知識庫擷取 |   命中/命中率   接地相關性分數   | 測量 RAG 管道的效能。 | 
| 延遲 | 每個模型的推論延遲 |   偵測 Amazon Bedrock 或 SageMaker 中的減速。   最佳化使用者回應時間。   | 
| 提示和回應品質 |   幻覺率   備用速率   | 確保接地正常運作，並且提示如預期般運作。 | 
| 安全與存取 | 依 IAM 角色的代理程式和工具用量 | 確保最低權限和可追蹤性的原則。 | 
| 字符用量 | 輸入和輸出字符總數 (Amazon Bedrock) |   控制成本。   偵測提示膨脹或模型濫用。   | 
| 工作流程運作狀態 | Step Functions 工作流程失敗、重試和逾時 | 表面協同運作問題和重試迴圈。 | 

## AWS 服務 用於觀察無伺服器和生成式 AI
<a name="section-observability-aws-services"></a>

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


| 
| 
| **AWS 服務** | **Description** | **理想的使用案例** | 
| --- |--- |--- |
| [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) | 從 Lambda、Step Functions、Amazon Bedrock Agents 和 Amazon API Gateway 擷取日誌 |   除錯   稽核線索   使用者工作階段追蹤   | 
| [Amazon CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) | 自訂和服務產生的金鑰效能指標 KPIs)，例如調用計數、持續時間和字符計數 |   儀表板   Alerts (提醒)    趨勢分析   | 
| [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) | 跨無伺服器流程的追蹤，包括 Lambda、API Gateway 和 Step Functions |   根本原因分析   延遲追蹤   相依性映射   | 
| [CloudWatch 內嵌指標格式](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html) | 日誌串流中進階指標的結構化記錄 | 啟用無需個別指標呼叫的分析 | 
| [Amazon Bedrock 代理程式追蹤](https://docs.aws.amazon.com/bedrock/latest/userguide/trace-events.html)和[模型調用記錄](https://docs.aws.amazon.com/bedrock/latest/userguide/model-invocation-logging.html) | 原生 Amazon Bedrock 代理程式執行追蹤、工具呼叫和 RAG 洞察 | 監控代理程式行為並故障診斷失敗 | 
| [Amazon EventBridge 管道](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-pipes.html)和[結構描述登錄檔](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-schema-registry.html) | 追蹤和驗證流經管道的事件格式 |   防止格式不正確的事件    確保合約一致性   | 
| [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) | 記錄所有 API 呼叫和身分內容 |   合規   安全性稽核   依角色區分的代理程式和工具用量   | 
| [Amazon OpenSearch Service](https://docs.aws.amazon.com/whitepapers/latest/big-data-analytics-options/elasticsearch.html) | 索引推論回應、結構化日誌或稽核記錄 |   回應的語意搜尋    可觀測性儀表板   | 
| [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) | 模擬流量以主動測試端點或工作流程 | 確保跨版本的執行時間和迴歸監控 | 

## 範例：監控以代理程式為基礎的支援工作流程
<a name="section-observability-example-workflow"></a>

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

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

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

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

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

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

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

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

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

## 可觀測性的最佳實務
<a name="section-observability-best-practices"></a>

在無伺服器和生成式 AI 工作流程中，請考慮下列可觀測性的最佳實務：
+ 使用結構化日誌檢測 AI 流程，以啟用跨元件的相互關聯 （例如，使用者工作階段、追蹤 ID 和模型回應）。
+ 使用一致的記錄結構描述來支援下游剖析、警示和分析管道。
+ 每層發出自訂指標，以協助追蹤與基礎設施問題相比的模型相關錯誤。
+ 使用環境和內容標記日誌，以依使用者角色、區域、版本或團隊啟用篩選。
+ 使用異常偵測警示來偵測字符突增、延遲峰值或輸出偏離。
+ 將 LLM 回應日誌與下游影響相關聯，將代理程式輸出連結至決策、呈報或失敗。
+ 透過具有提示成本、模型使用率和備用率的每週儀表板自動化報告產生，以推動責任和改進週期。

## 可觀測性和監控的摘要
<a name="section-observability-summary"></a>

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

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