# 在事件偵測與回應中定義和設定警示
AWS 會與您一起定義指標和警示，讓您能夠檢視應用程式及其基礎 AWS 基礎結構的效能。我們要求遵循下列準則來定義和設定警示的閾值：
+ 警示只會在對監控的工作負載有重大影響 (收入損失或客戶體驗降級導致效能大幅降低) 且需要操作員立即注意時，才會進入「警示」狀態。
+ 警示也必須在與事件管理團隊互動的同時或之前，讓指定的工作負載解決人員參與。事件管理工程師會在緩解過程中與您指定的解決人員合作，而且不會作為一線回應者，再呈報給您。
+ 警示閾值必須設定為適當的閾值和持續時間，以便只要警示觸發，就必須進行調查。如果警示在「警示」和「正常」狀態之間轉換，這樣的影響就足以保證操作員回應和注意。
**警示類型**：
+ 描述業務影響層級並傳遞相關資訊以進行簡單的故障偵測的警示。
+ Amazon CloudWatch Canary。如需詳細資訊，請參閱 [Canary 和 X-Ray 追蹤](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_tracing.html)及 [X-Ray](https://aws.amazon.com/xray/)。
+ 彙總警示 (監控相依性)
下表提供範例警示，這些全都是使用 CloudWatch 監控系統。
****
| 指標名稱/警示閾值 | 警示 ARN 或資源 ID | 如果此警示觸發 | 若已參與，則截止這些服務的付費支援案例 |
| --- | --- | --- | --- |
| API 錯誤/ 10 個資料點的錯誤數 >= 10 | arn:aws:cloudwatch:us-west-2:000000000000:alarm:E2MPmimLambda-Errors | 票證分給資料庫管理員 (DBA) 團隊 | Lambda、API Gateway |
| ServiceUnavailable (Http 狀態碼 503) 5 分鐘內 10 個資料點 (不同用戶端) 的錯誤數 >=3 | arn:aws:cloudwatch:us-west-2:xxxxx:alarm:httperrorcode503 | 票證分給服務團隊 | Lambda、API Gateway |
| ThrottlingException (Http 狀態碼 400) 5 分鐘內 10 個資料點 (不同用戶端) 的錯誤數 >=3 | arn:aws:cloudwatch:us-west-2:xxxxx:alarm:httperrorcode400 | 票證分給服務團隊 | EC2、Amazon Aurora |
如需詳細資訊，請參閱[AWS 事件偵測與回應監控與可觀測性](observe-idr.md)。
如果您偏好使用自動化工具來將警示上線，事件偵測與回應命令列介面 (CLI) 可協助您部署並將警示上線。如需詳細資訊，請參閱[AWS 事件偵測與回應 CLI](idr-cli.md)。
**重要輸出：**
+ 工作負載上警示的定義和組態。
+ 完成填寫上線問卷中的警示詳細資訊。
**Topics**
+ [建立 CloudWatch 警示](idr-alarms-fit-purpose.md)
+ [使用 CloudFormation 範本建置 CloudWatch 警示](idr-create-alarms-with-cfn.md)
+ [CloudWatch 警示的範例使用案例](idr-ex-alarm-use-cases.md)
# 在事件偵測與回應中建立符合您業務需求的 CloudWatch 警示
當您建立 Amazon CloudWatch 警示時，您可以採取幾個步驟來確保您的警示最合乎您的業務需求。
**注意**
如需讓 AWS 服務 在事件偵測與回應上線的建議 CloudWatch 警示範例，請參閱 [AWS re:Post 上的事件偵測與回應警示最佳實務](https://repost.aws/selections/KP6FA7iQgVSVeSNq1jAcjwxg/incident-detection-and-response-idr)。
## 檢閱您提議的 CloudWatch 警示
檢閱您提議的警示，確保這些警示只會在對監控的工作負載有重大影響 (收入損失或客戶體驗降級導致效能大幅降低) 且需要操作員立即注意時，才會進入「警示」狀態。例如，您是否認為這是重大警示，因此當它進入「警示」狀態時，您必須立即回應？
以下是可能代表重大業務影響的建議指標，例如影響最終使用者使用應用程式的體驗：
+ **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)。
## 驗證您的警示組態
在您確認提議的警示符合您的業務需求後，請驗證警示的組態和歷史記錄：
+ 對照指標的圖形趨勢，驗證指標進入「警示」狀態的**閾值**。
+ 驗證用於輪詢資料點的**期間**。每 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 警示如何處理遺失資料](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**，以便將遺失的資料視為「正常」，且指標不會在單一資料點上進入「警示」狀態。
## 檢閱每個警示的歷史記錄
如果警示的歷史記錄顯示其經常進入「警示」狀態後快速復原，則該警示可能會對您造成問題。務必調整警示，以防止雜訊或誤報。
## 驗證基礎資源的指標
確定您的指標查看有效的基礎資源，並使用正確的統計資料。如果警示設定為檢閱無效的資源名稱，則警示可能無法追蹤基礎資料。這可能會導致警示進入「警示」狀態。
## 建立複合警示
如果您對事件偵測與回應操作提供大量上線警示，則可能需要建立複合警示。複合警示可減少需上線的警示總數。
# 使用 CloudFormation 範本在事件偵測與回應中建置 CloudWatch 警示
為了加速在 AWS 事件偵測與回應中上線，並減少建置警示所需的工作量，AWS 為您提供了 CloudFormation 範本。這些範本包括常用上線服務的最佳化警示設定，例如 Application Load Balancer、Network Load Balancer 和 Amazon CloudFront。
**使用 CloudFormation 範本建置 CloudWatch 警示**
1. 使用提供的連結下載範本：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/IDR/latest/userguide/idr-create-alarms-with-cfn.html)
1. 檢閱下載的 JSON 檔案，確保其符合您組織的營運和安全程序。
1. 建立 CloudFormation 堆疊：
**注意**
以下步驟使用標準 CloudFormation 堆疊建立程序。如需詳細步驟，請參閱[在 CloudFormation 主控台上建立堆疊](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)。
1. 在以下網址開啟 AWS CloudFormation 主控台：[https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/)。
1. 選擇 **Create Stack** (建立堆疊)。
1. 選擇**範本已準備就緒**，然後從本機資料夾上傳範本檔案。
以下是**建立堆疊**畫面的範例。
![\[建立堆疊上傳範本檔案範例\]](http://docs.aws.amazon.com/zh_tw/IDR/latest/userguide/images/create-cfn-stack1.png)
1. 選擇**下一步**。
1. 輸入下列必填資訊：
+ **AlarmNameConfig** 和 **AlarmDescriptionConfig**：輸入警示的名稱和說明。
+ **ThresholdConfig**：修訂閾值以符合應用程式的需求。
+ **DistributionIDConfig**：確定分佈 ID 指向您建立 CloudFormation 堆疊所在帳戶中的正確資源。
1. 選擇**下一步**。
1. 檢閱 **PeriodConfig**、**EvalutionPeriodConfig** 和 **DatapointsToAlarmConfig** 欄位中的預設值。最佳實務是使用這些欄位的預設值。您可以視需要進行調整，以符合應用程式的需求。
1. 視需要選擇性地輸入標籤和 SNS 通知資訊。最佳實務是開啟**終止保護**，防止意外刪除警示。若要開啟終止保護，請選取**已啟用**選項按鈕，如下列範例所示：
![\[建立堆疊啟用終止保護範例\]](http://docs.aws.amazon.com/zh_tw/IDR/latest/userguide/images/create-cfn-stack2.png)
1. 選擇**下一步**。
1. 檢閱您的堆疊設定，然後選擇**建立堆疊**。
1. 建立堆疊後，您會看到 Amazon CloudWatch **警示**清單中列出警示，如下列範例所示：
![\[範例 CloudWatch 警示清單\]](http://docs.aws.amazon.com/zh_tw/IDR/latest/userguide/images/create-cfn-stack3.png)
1. 您在正確的帳戶和 AWS 區域中建立所有警示之後，請通知您的技術客戶經理 (TAM)。AWS 事件偵測與回應團隊會檢閱新警示的狀態，然後繼續上線。
# 事件偵測與回應中 CloudWatch 警示的範例使用案例
下列使用案例提供如何在事件偵測與回應中使用 Amazon CloudWatch 警示的範例。這些範例示範如何設定 CloudWatch 警示以監控各種 AWS 服務的關鍵指標和閾值，讓您能夠識別和回應可能影響應用程式和工作負載可用性與效能的潛在問題。
## 範例使用案例 A：Application Load Balancer
您可以建立下列 CloudWatch 警示，以指出潛在的工作負載影響。若要這樣做，您可以建立指標數學，在成功連線低於特定閾值時發出警示。若要了解可用的 CloudWatch 指標，請參閱 [Application Load Balancer 的 CloudWatch 指標](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)
**指標：**`HTTPCode_Target_3XX_Count;HTTPCode_Target_4XX_Count;HTTPCode_Target_5XX_Count. (m1+m2)/(m1+m2+m3+m4)*100 m1 = HTTP Code 2xx || m2 = HTTP Code 3xx || m3 = HTTP Code 4xx || m4 = HTTP Code 5xx`
**NameSpace：**AWS/ApplicationELB
**ComparisonOperator(Threshold)：**小於 x (x = 客戶的閾值)。
**Period：**60 秒
**DatapointsToAlarm：**3 之 3
**遺失資料處理：**將遺失資料視為[違反](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)。
**統計資料：**總和
下圖顯示使用案例 A 的流程：
![\[Application Load Balancer 的範例使用案例\]](http://docs.aws.amazon.com/zh_tw/IDR/latest/userguide/images/UseCaseAALB.png)
## 範例使用案例 B：Amazon API Gateway
您可以建立下列 CloudWatch 警示，以指出潛在的工作負載影響。若要這樣做，您可以建立複合指標，在 API Gateway 中出現高延遲或高平均 4XX 錯誤數時發出警示。如需可用的指標，請參閱 [Amazon API Gateway 維度和指標](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-metrics-and-dimensions.html)
**指標：**`compositeAlarmAPI Gateway (ALARM(error4XXMetricApiGatewayAlarm)) OR (AALARM(latencyMetricApiGatewayAlarm))`
**NameSpace：**AWS/API Gateway
**ComparisonOperator(Threshold)：**大於 (x 或 y 客戶的閾值)
**Period：**60 秒
**DatapointsToAlarm：**1 之 1
**遺失資料處理：**將遺失資料視為[未違反](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)。
**統計資料：**
下圖顯示使用案例 B 的流程：
![\[API Gateway 的範例使用案例\]](http://docs.aws.amazon.com/zh_tw/IDR/latest/userguide/images/UseCaseBAPIGW.png)
## 範例使用案例 C：Amazon Route 53
您可以透過建立 Route 53 運作狀態檢查，以使用 CloudWatch 收集原始資料並將其處理成為可讀取、近乎即時的指標，藉此監控資源。您可以建立下列 CloudWatch 警示，以指出潛在的工作負載影響。您可以使用 CloudWatch 指標來建立警示，並在違反建立的閾值時觸發警示。如需可用的 CloudWatch 指標，請參閱 [Route 53 運作狀態檢查的 CloudWatch 指標](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-cloudwatch.html#cloudwatch-metrics)
**指標：**`R53-HC-Success`
**NameSpace：**AWS/Route 53
**Threshold HealthCheckStatus：**3 分鐘內 3 個資料點的 HealthCheckStatus < x (x 為客戶的閾值)
**Period：**1 分鐘
**DatapointsToAlarm：**3 之 3
**遺失資料處理：**將遺失資料視為[違反](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)。
**統計資料：**最小值
下圖顯示使用案例 C 的流程：
![\[Route 53 的範例使用案例\]](http://docs.aws.amazon.com/zh_tw/IDR/latest/userguide/images/UseCaseCR53.png)
## 範例使用案例 D：使用自訂應用程式監控工作負載
請務必花些時間在此案例中定義適當的運作狀態檢查。如果您只驗證應用程式的連接埠是否開啟，則尚未驗證應用程式是否正常運作。此外，呼叫應用程式的首頁不一定是判斷應用程式是否正常運作的正確方式。例如，如果應用程式同時依賴資料庫和 Amazon Simple Storage Service (Amazon S3)，則運作狀態檢查必須驗證所有元素。其中一種方法是建立監控網頁，例如 **/monitor**。監控網頁會呼叫資料庫，確認其可以連線並取得資料。監控網頁也會呼叫 Amazon S3。接著您將負載平衡器上的運作狀態檢查指向 **/monitor** 頁面。
下圖顯示使用案例 D 的流程：
![\[使用自訂應用程式進行監控的範例使用案例\]](http://docs.aws.amazon.com/zh_tw/IDR/latest/userguide/images/CustomAlarm.png)