本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
REL06-BP07 監控 end-to-end透過您的系統追蹤請求
在透過服務元件處理請求時追蹤請求，讓產品團隊可以更輕鬆地分析和偵錯問題，並改善效能。
預期結果：具有所有元件全面追蹤的工作負載易於偵錯，透過簡化根本原因探索來改善錯誤和延遲的平均解決時間 （MTTR）。 End-to-end追蹤可減少探索受影響元件所需的時間，並深入探索錯誤或延遲的詳細根本原因。
常見的反模式：
-
追蹤可用於某些元件，但不適用於所有元件。例如，如果沒有追蹤 AWS Lambda，團隊可能無法清楚了解因頻繁工作負載冷啟動所造成的延遲。
-
合成 Canary 或真實使用者監控 （RUM） 未設定追蹤。如果沒有 Canary 或 RUM，追蹤分析會省略用戶端互動遙測，產生不完整的效能描述檔。
-
混合式工作負載同時包含雲端原生和第三方追蹤工具，但未採取相關步驟來選擇及完全整合單一追蹤解決方案。根據選擇的追蹤解決方案，雲端原生追蹤SDKs應用於非雲端原生或第三方工具的儀器元件，應設定為擷取雲端原生追蹤遙測。
建立此最佳實務的優勢：當開發團隊收到問題的提醒時，他們可以看到系統元件互動的全貌，包括個別元件與日誌記錄、效能和失敗的關聯性。由於追蹤可讓您輕鬆地以視覺化方式識別根本原因，調查根本原因的所需時間將可縮短。詳細了解元件互動的團隊，可在解決問題時做出更明智、更快速的決策。諸如何時應調用災難復原 (DR) 容錯移轉，或何處最適合實作自我修復策略之類的決策，可藉由分析系統追蹤來改善，最終提升客戶對服務的滿意度。
未建立此最佳實務時的曝險等級：中
實作指引
操作分散式應用程式的團隊，可使用追蹤工具來建立關聯性識別碼、收集請求追蹤，以及建置連網元件的服務圖。所有應用程式元件均應包含在請求追蹤中，包括服務用戶端、中介軟體閘道和事件匯流排、運算元件和儲存體 (包括鍵值存放區和資料庫)。在追蹤組態中 end-to-end包含合成 Canary 和真實使用者監控，以測量遠端用戶端互動和延遲，以便您可以根據服務層級協議和目標準確評估系統效能。
您可以使用 AWS X-Ray和 Amazon CloudWatch Application Monitoring 測試服務，在請求通過應用程式時提供完整的檢視。X-Ray 會收集應用程式遙測，並可讓您針對無程式碼或低程式碼的系統元件，將 APIs和 視覺化並進行篩選。 CloudWatch 應用程式監控包括 ServiceLens 整合您的追蹤與指標、日誌和警示。 CloudWatch 應用程式監控還包括用於監控端點和 的合成APIs，以及用於測試 Web 應用程式用戶端的真實使用者監控。
實作步驟
-
在 Amazon S3 和 Amazon Gateway 等所有支援的原生服務 AWS X-Ray 上使用 。 Amazon S3 AWS Lambda API AWS 這些服務使用基礎設施作為程式碼 AWS SDKs或 啟用具有組態切換的 X-Ray AWS Management Console。
-
檢測應用程式 AWS Distro for Open Telemetry 和 X-Ray 或第三方收集代理程式。
-
檢閱 AWS X-Ray 開發人員指南，了解程式設計語言特定實作。這些文件章節詳細說明如何針對您的應用程式程式設計語言執行HTTP請求、SQL查詢和其他程序。
-
使用適用於 Amazon CloudWatch Synthetic Canary 和 Amazon CloudWatch RUM 的 X-Ray 追蹤，透過下游 AWS 基礎設施來分析最終使用者用戶端的請求路徑。
-
根據資源運作狀態和 Canary 遙測設定 CloudWatch 指標和警示，以便團隊快速收到問題警示，然後可以透過 深入探索追蹤和服務地圖 ServiceLens。
-
如果將第三方工具用於主要追蹤解決方案，請為第三方追蹤工具 (例如 Datadog
、New Relic 或 Dynatrace ) 啟用 X-Ray 整合。
資源
相關的最佳實務：
相關文件：
相關範例：
相關影片：
相關工具：
