本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
REL11-BP01 監控工作負載的所有元件以偵測故障
持續監控工作負載的運作狀態，讓您和自動化系統在發生故障或效能降低時能夠察覺。根據商業價值監控關鍵績效指標 （KPIs）。
所有復原和修復機制首先都必須能夠快速偵測問題。應該先偵測技術故障，以便解決問題。但是，可用性取決於工作負載提供商業價值的能力，因此衡量此值的關鍵效能指標 （KPIs） 需要成為偵測和修復策略的一部分。
預期成果：工作負載的基本元件會單獨監控，以偵測故障發生的時機和位置並發出警示。
常見的反模式：
-
未設定任何警報，因此會在未發出通知的情況下發生中斷。
-
警示存在，但在此閾值下無法提供足夠的回應時間。
-
指標的收集頻率不足以達到復原時間目標 （RTO）。
-
只主動監控面對客戶的工作負載介面。
-
只收集技術指標，未收集業務功能指標。
-
無測量工作負載使用者體驗的指標。
-
建立了太多監控。
建立此最佳實務的優勢：在各層級內進行適當的監控，可讓您減少偵測時間，進而減少復原時間。
未建立此最佳實務時的曝險等級：高
實作指引
確定將要檢閱以進行監控的所有工作負載。確定需要監控的所有工作負載元件之後，您現在需要確定監控間隔。根據偵測故障所需的時間而定，監控間隔會直接影響復原的速度。平均偵測時間 （MTTD） 是從發生故障到開始修復操作之間的時間量。服務清單應盡可能廣泛且完整。
監控必須涵蓋應用程式堆疊的所有層級，包括應用程式、平台、基礎設施和網路。
您的監控策略應考慮微小故障的影響。如需微小故障的詳細資訊，請參閱《進階多可用區域彈性模式》白皮書中的 Gray failures。
實作步驟
-
您的監控間隔取決於復原必須多快完成。復原時間是由復原所需的時間所驅動，因此您必須考慮此時間和復原時間目標 （） 來決定收集頻率RTO。
-
設定元件和受管服務的詳細監控。
-
判斷是否需要詳細的EC2執行個體監控和 Auto Scaling。詳細監控提供 1 分鐘的間隔指標，預設監控則提供 5 分鐘的間隔指標。
-
判斷是否需要增強對 的監控RDS。增強型監控會在RDS執行個體上使用代理程式，以取得不同程序或執行緒的有用資訊。
-
判斷 Lambda 、APIGateway 、Amazon EKS、Amazon ECS
和所有類型負載平衡器 的重要無伺服器元件的監控需求。 -
判斷 Amazon S3、Amazon 、Amazon FSx EFS和 Amazon EBS儲存元件的監控需求。
-
-
建立自訂指標以測量業務金鑰效能指標 （KPIs）。工作負載會實作關鍵業務函數，這些函數應用作KPIs協助識別間接問題發生的時間。
-
以使用者 Canary 監控使用者的故障體驗。可執行和模擬客戶行為的綜合交易測試 (也稱為 Canary 測試，但請別與 Canary 部署混淆)，是最重要的測試程序之一。針對來自不同遠端位置的工作負載端點持續執行這些測試。
-
建立追蹤使用者體驗的自訂指標。如果您可以檢測客戶的體驗，則可以判斷消費者體驗何時變差。
-
設定警示以偵測工作負載的任何部分何時未正常運作，並指示何時自動擴展資源。警示可以視覺化顯示在儀表板上，透過 Amazon SNS或電子郵件傳送警示，並使用 Auto Scaling 將工作負載資源向上或向下擴展。
-
建立儀表板以視覺化指標。儀表板可以讓您以視覺化方式查看趨勢、極端值和其他潛在問題的指標，或指出您可能想要調查的問題。
-
為您的服務建立分散式追蹤監控
。透過分散式監控，您可以了解應用程式及其基礎服務的執行方式，以確定和疑難排解效能問題與錯誤的根本原因。 -
在個別區域和帳戶中建立監控系統 （使用或 CloudWatch X-Ray）
儀表板和資料收集。 -
建立 Amazon Health Aware
監控的整合，以允許監控可能降低 AWS 的資源可見性。對於業務必要工作負載，此解決方案可讓您存取 AWS 服務的主動和即時警示。
資源
相關的最佳實務：
相關文件：
相關影片：
相關範例：
相關工具：
