# 在事件偵測與回應中建立符合您業務需求的 CloudWatch 警示
<a name="idr-alarms-fit-purpose"></a>

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

**注意**  
如需讓 AWS 服務 在事件偵測與回應上線的建議 CloudWatch 警示範例，請參閱 [AWS re:Post 上的事件偵測與回應警示最佳實務](https://repost.aws/selections/KP6FA7iQgVSVeSNq1jAcjwxg/incident-detection-and-response-idr)。

## 檢閱您提議的 CloudWatch 警示
<a name="idr-review-alarms"></a>

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

以下是可能代表重大業務影響的建議指標，例如影響最終使用者使用應用程式的體驗：
+ **CloudFront：**如需詳細資訊，請參閱[檢視 CloudFront 和邊緣函數指標](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/viewing-cloudfront-metrics.html)。
+ **Application Load Balancer：**盡可能為 Application Load Balancer 建立下列警示，這是最佳實務：
  + HTTPCode\$1ELB\$15XX\$1Count
  + HTTPCode\$1Target\$15XX\$1Count

  上述警示可讓您監控來自 Application Load Balancer 後方或其他資源後方之目標的回應。如此更方便您識別 5XX 錯誤的來源。如需詳細資訊，請參閱 [Application Load Balancer 的 CloudWatch 指標](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)。
+ **Amazon API Gateway：**如果您在 Elastic Beanstalk 中使用 WebSocket API，請考慮使用下列指標：
  + 整合錯誤率 (篩選出 5XX 錯誤)
  + 整合延遲
  + 執行錯誤

  如需詳細資訊，請參閱[使用 CloudWatch 指標來監控 WebSocket API 執行](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api-logging.html)。
+ **Amazon Route 53：**監控 **EndPointUnhealthyENICount** 指標。此指標是處於**自動復原**狀態的彈性網路介面數量。此狀態表示，解決人員嘗試復原與端點相關聯的一或多個 Amazon Virtual Private Cloud 網路介面 (以 **EndpointId** 指定)。在復原過程中，端點會以有限的容量運作。在完全復原之前，端點無法處理 DNS 查詢。如需詳細資訊，請參閱[透過 Amazon CloudWatch 監控 Amazon Route 53 Resolver 端點](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-resolver-with-cloudwatch.html)。

## 驗證您的警示組態
<a name="idr-validate-alarm-config"></a>

在您確認提議的警示符合您的業務需求後，請驗證警示的組態和歷史記錄：
+ 對照指標的圖形趨勢，驗證指標進入「警示」狀態的**閾值**。
+ 驗證用於輪詢資料點的**期間**。每 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 服務在工作負載內的運作方式有所不同。而且相同服務在多個位置使用時，運作方式也可能不同。您必須確實了解工作負載如何利用饋送警示的資源，以及上游和下游的作用。

## 驗證警示處理遺失資料的情形
<a name="idr-validate-missing-data"></a>

有些指標來源不會定期傳送資料至 CloudWatch。對於這些指標，最佳實務是將遺失的資料視為 **notBreaching**。如需詳細資訊，請參閱[設定 CloudWatch 警示如何處理遺失資料](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)和[避免過早轉換到警示狀態](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#CloudWatch-alarms-avoiding-premature-transition)。

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

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

## 檢閱每個警示的歷史記錄
<a name="idr-review-alarm-history"></a>

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

## 驗證基礎資源的指標
<a name="idr-validate-underlying-resources"></a>

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

## 建立複合警示
<a name="idr-create-composite-alarms"></a>

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