# 在事件检测及响应服务中定义和配置警报
AWS 将与您协作，一起定义指标和警报，让您能够了解应用程序及其底层 AWS 基础设施的性能。我们要求警报在定义和配置阈值时符合以下标准：
+ 警报只在受监控的工作负载遭受重大影响（收入损失/客户体验降级导致性能显著下降）且需要运维人员立即给予关注时才进入“警报”状态。
+ 警报还必须在与事件管理团队联系的同时或联系之前，与您工作负载的指定事件解决人员联系。事件管理工程师会在风险缓解流程中与您指定的事件解决人员协作，而非充当第一响应者然后再上报给您。
+ 警报阈值必须设置为适当的阈值和持续时间，以便每当警报触发时，都会介入调查。如果警报在“警报”和“正常”状态之间摇摆，会产生足够的影响以确保得到运维人员的响应和关注。
**警报类型**：
+ 可描述业务影响程度并传递相关信息以进行简单故障检测的警报。
+ Amazon CloudWatch 金丝雀警报。有关更多信息，请参阅[金丝雀和 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)。
+ **应用程序负载均衡器：**如果可能，最好为应用程序负载均衡器创建以下警报：
+ HTTPCode\$1ELB\$15XX\$1Count
+ HTTPCode\$1Target\$15XX\$1Count
通过上述警报，您可以监控来自应用程序负载均衡器背后或其它资源背后的目标的响应。这样就可以更轻松地确定 5XX 错误的来源。有关更多信息，请参阅[应用程序负载均衡器的 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** 指标。此指标是处于**自动恢复**状态的弹性网络接口数。此状态表示解析程序尝试恢复一个或多个与端点（通过 **EndpointId** 指定）关联的 Amazon Virtual Private Cloud 网络接口。在恢复过程中，端点会正常运行，但容量有限。并且在完全恢复之前，端点无法处理 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 秒指标，DatapointToAlarm 为 3/3]，则警报在 3 分钟后触发；如果设置为 [60 秒指标，DatapointToAlarm 为 5/5]，则警报会在 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)。
例如，如果某个指标用于监控错误率，然后没有错误，则该指标会报告无数据（零）数据点。如果您将警报配置为将缺失数据处理为**缺失**，则单个超出阈值的数据点后跟两个无数据（零）数据点会导致该指标进入“警报”状态（3/3 个数据点）。这是因为缺失数据配置会对评估周期内最后一个已知数据点进行评估。
对于指标监控错误率的情况，如果没有出现服务降级，您可以假设没有数据是一件好事。最佳做法是将缺失数据处理为 **notBreaching**，这样缺失数据就会被视为“正常”，该指标便不会基于单个数据点进入“警报”状态。
## 查看每个警报的历史记录
如果某个警报的历史记录显示其经常进入“警报”状态而后又快速恢复，那么该警报可能存在问题。确保调整警报以防出现噪音或误报警报。
## 验证底层资源的指标
确保您的指标查看有效的底层资源并使用正确的统计数据。如果警报配置为查看无效的资源名称，则警报可能无法跟踪底层数据。这可能会导致警报进入“警报”状态。
## 创建复合警报
如果您向事件检测及响应服务运维团队提供大量要加入的警报，则可能会要求您创建复合警报。复合警报可减少需要加入的警报总数。
# 使用 CloudFormation 模板在事件检测及响应服务中构建 CloudWatch 警报
为了更快地加入 AWS 事件检测及响应服务，并减少构建警报所需的工作，AWS 为您提供了 CloudFormation 模板。这些模板为常见的加入服务提供了优化的警报设置，例如应用程序负载均衡器、网络负载均衡器以及 Amazon CloudFront 等。
**使用 CloudFormation 模板构建 CloudWatch 警报**
1. 使用提供的链接下载模板：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/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. 选择**创建堆栈**。
1. 选择**模板已就绪**，然后从本地文件夹上传模板文件。
以下是**创建堆栈**屏幕的示例。
![\[创建堆栈上传模板文件示例\]](http://docs.aws.amazon.com/zh_cn/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_cn/IDR/latest/userguide/images/create-cfn-stack2.png)
1. 选择**下一步**。
1. 检查您的堆栈设置，然后选择**创建堆栈**。
1. 创建堆栈后，您会看到警报已在 Amazon CloudWatch **警报**列表中列出，如以下示例所示：
![\[CloudWatch 警报列表示例\]](http://docs.aws.amazon.com/zh_cn/IDR/latest/userguide/images/create-cfn-stack3.png)
1. 在正确的账户和 AWS 区域创建所有警报后，请通知您的技术客户经理（TAM）。AWS 事件检测及响应服务团队会审核您新警报的状态，然后继续加入流程。
# 事件检测及响应服务中的 CloudWatch 警报使用案例示例
以下使用案例提供了如何在事件检测及响应服务中使用 Amazon CloudWatch 警报的示例。这些示例演示了如何配置 CloudWatch 警报来监控各项 AWS 服务的关键指标和阈值，从而使您能够识别和应对可能会影响您应用程序和工作负载可用性及性能的潜在问题。
## 使用案例示例 A：应用程序负载均衡器
您可以创建以下 CloudWatch 警报来指示潜在的工作负载潜在影响。为此，您需要创建一个指标数学表达式，当成功连接数降至特定阈值以下时，便会发出警报。有关可用的 CloudWatch 指标，请参阅[应用程序负载均衡器的 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`
**命名空间：**AWS/ApplicationELB
**ComparisonOperator(阈值)：**小于 x（x = 客户的阈值）。
**时间段：**60 秒
**DatapointsToAlarm：**3/3
**缺失数据处理：**将缺失数据处理为 [breaching](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)。
**统计数据：**Sum
下图显示了使用案例 A 的流程：
![\[应用程序负载均衡器的使用案例示例\]](http://docs.aws.amazon.com/zh_cn/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))`
**命名空间：**AWS/API Gateway
**ComparisonOperator(阈值)：**大于客户的阈值 x 或 y。
**时间段：**60 秒
**DatapointsToAlarm：**1/1
**缺失数据处理：**将缺失数据处理为 [notBreaching](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)。
**统计数据 **– 。
下图显示了使用案例 B 的流程：
![\[API Gateway 使用案例示例\]](http://docs.aws.amazon.com/zh_cn/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`
**命名空间：**AWS/Route 53
**阈值 HealthCheckStatus**：3 分钟内 3 个数据点的 HealthCheckStatus < x（x 是客户的阈值）
**时间段**：1 分钟
**DatapointsToAlarm：**3/3
**缺失数据处理：**将缺失数据处理为 [breaching](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)。
**统计数据：**Minimum
下图显示了使用案例 C 的流程：
![\[Route 53 的使用案例示例\]](http://docs.aws.amazon.com/zh_cn/IDR/latest/userguide/images/UseCaseCR53.png)
## 示例使用案例 D：使用自定义应用程序监控工作负载
在这种情况下，花点时间定义适当的运行状况检查至关重要。如果您仅验证应用程序的端口是打开的，则说明您并未验证该应用程序是否正常运行。此外，调用应用程序的主页不一定是确定该应用程序是否正常运行的正确方法。例如，如果应用程序同时依赖一个数据库和 Amazon Simple Storage Service（Amazon S3），则运行状况检查必须验证所有元素。一种方法是创建一个监控网页，例如 **/monitor**。监控网页会调用数据库，以确保它可以连接并获取数据。而且，监控网页会调用 Amazon S3。然后，您再将负载均衡器上的运行状况检查指向 **/monitor** 页面。
下图显示了使用案例 D 的流程：
![\[使用自定义应用程序进行监控的使用案例示例\]](http://docs.aws.amazon.com/zh_cn/IDR/latest/userguide/images/CustomAlarm.png)