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