在事件偵測與回應中建立符合您業務需求的 CloudWatch 警示 - AWS 事件偵測與回應使用者指南
檢閱 CloudWatch 警示驗證您的警示驗證處理遺失資料的情形檢閱警示歷史記錄驗證基礎資源的指標建立複合警示

在事件偵測與回應中建立符合您業務需求的 CloudWatch 警示

當您建立 Amazon CloudWatch 警示時，您可以採取幾個步驟來確保您的警示最合乎您的業務需求。

注意

如需讓 AWS 服務 在事件偵測與回應上線的建議 CloudWatch 警示範例，請參閱 AWS re:Post 上的事件偵測與回應警示最佳實務。

檢閱您提議的 CloudWatch 警示

檢閱您提議的警示，確保這些警示只會在對監控的工作負載有重大影響 (收入損失或客戶體驗降級導致效能大幅降低) 且需要操作員立即注意時，才會進入「警示」狀態。例如，您是否認為這是重大警示，因此當它進入「警示」狀態時，您必須立即回應？

以下是可能代表重大業務影響的建議指標，例如影響最終使用者使用應用程式的體驗：

  • CloudFront：如需詳細資訊，請參閱檢視 CloudFront 和邊緣函數指標。

  • Application Load Balancer：盡可能為 Application Load Balancer 建立下列警示，這是最佳實務：

    • HTTPCode_ELB_5XX_Count

    • HTTPCode_Target_5XX_Count

    上述警示可讓您監控來自 Application Load Balancer 後方或其他資源後方之目標的回應。如此更方便您識別 5XX 錯誤的來源。如需詳細資訊，請參閱 Application Load Balancer 的 CloudWatch 指標。

  • Amazon API Gateway：如果您在 Elastic Beanstalk 中使用 WebSocket API，請考慮使用下列指標：

    • 整合錯誤率 (篩選出 5XX 錯誤)

    • 整合延遲

    • 執行錯誤

    如需詳細資訊，請參閱使用 CloudWatch 指標來監控 WebSocket API 執行。

  • Amazon Route 53：監控 EndPointUnhealthyENICount 指標。此指標是處於自動復原狀態的彈性網路介面數量。此狀態表示，解決人員嘗試復原與端點相關聯的一或多個 Amazon Virtual Private Cloud 網路介面 (以 EndpointId 指定)。在復原過程中，端點會以有限的容量運作。在完全復原之前，端點無法處理 DNS 查詢。如需詳細資訊，請參閱透過 Amazon CloudWatch 監控 Amazon Route 53 Resolver 端點。

驗證您的警示組態

在您確認提議的警示符合您的業務需求後，請驗證警示的組態和歷史記錄：

  • 對照指標的圖形趨勢，驗證指標進入「警示」狀態的閾值。

  • 驗證用於輪詢資料點的期間。每 60 秒輪詢一次資料點，有助於及早偵測到事件。

  • 驗證 DatapointToAlarm 組態。在大多數情況下，最佳實務是將此項設定為 3 之 3 或 5 之 5。發生事件時，警示會在設定為 [60 second metrics with 3 out of 3 DatapointToAlarm] 時經過 3 分鐘後觸發，或設定為 [60 second metrics with 5 out of 5 DatapointToAlarm] 時經過 5 分鐘後觸發。使用此組合可消除雜訊警示。

注意

上述建議可能因您使用服務的方式而有所不同。每項 AWS 服務在工作負載內的運作方式有所不同。而且相同服務在多個位置使用時，運作方式也可能不同。您必須確實了解工作負載如何利用饋送警示的資源，以及上游和下游的作用。

驗證警示處理遺失資料的情形

有些指標來源不會定期傳送資料至 CloudWatch。對於這些指標，最佳實務是將遺失的資料視為 notBreaching。如需詳細資訊，請參閱設定 CloudWatch 警示如何處理遺失資料和避免過早轉換到警示狀態。

例如，如果指標監控錯誤率，但沒有錯誤，則指標會回報無資料 (nil) 資料點。如果您將警示設定為將遺失資料視為遺失，則單一違規資料點後面接著兩個無資料 (nil) 資料點會導致指標進入「警示」狀態 (3 個資料點中的 3 個)。這是因為遺失資料組態會評估在評估期間的最後已知資料點。

在指標監控錯誤率的情況下，若未發生服務降級，您可以假設無資料是良好情況。最佳實務是將遺失的資料視為 notBreaching，以便將遺失的資料視為「正常」，且指標不會在單一資料點上進入「警示」狀態。

檢閱每個警示的歷史記錄

如果警示的歷史記錄顯示其經常進入「警示」狀態後快速復原，則該警示可能會對您造成問題。務必調整警示，以防止雜訊或誤報。

驗證基礎資源的指標

確定您的指標查看有效的基礎資源，並使用正確的統計資料。如果警示設定為檢閱無效的資源名稱，則警示可能無法追蹤基礎資料。這可能會導致警示進入「警示」狀態。

建立複合警示

如果您對事件偵測與回應操作提供大量上線警示，則可能需要建立複合警示。複合警示可減少需上線的警示總數。