# 在事件检测及响应服务中创建符合您业务需求的 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)。
+ **应用程序负载均衡器：**如果可能，最好为应用程序负载均衡器创建以下警报：
  + 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)。

## 验证警报配置
<a name="idr-validate-alarm-config"></a>

确认您提出的警报符合自己的业务需求后，请验证警报的配置和历史记录：
+ 根据指标的图表趋势，验证支持指标进入“警报”状态的**阈值**。
+ 验证用于轮询数据点的**时间段**。在 60 秒时对数据点进行轮询有助于及早检测事件。
+ 验证 **DatapointToAlarm** 配置。在大多数情况下，最佳做法是将其设置为 3/3 或 5/5。在事件中，如果设置为 [60 秒指标，DatapointToAlarm 为 3/3]，则警报在 3 分钟后触发；如果设置为 [60 秒指标，DatapointToAlarm 为 5/5]，则警报会在 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)。

例如，如果某个指标用于监控错误率，然后没有错误，则该指标会报告无数据（零）数据点。如果您将警报配置为将缺失数据处理为**缺失**，则单个超出阈值的数据点后跟两个无数据（零）数据点会导致该指标进入“警报”状态（3/3 个数据点）。这是因为缺失数据配置会对评估周期内最后一个已知数据点进行评估。

对于指标监控错误率的情况，如果没有出现服务降级，您可以假设没有数据是一件好事。最佳做法是将缺失数据处理为 **notBreaching**，这样缺失数据就会被视为“正常”，该指标便不会基于单个数据点进入“警报”状态。

## 查看每个警报的历史记录
<a name="idr-review-alarm-history"></a>

如果某个警报的历史记录显示其经常进入“警报”状态而后又快速恢复，那么该警报可能存在问题。确保调整警报以防出现噪音或误报警报。

## 验证底层资源的指标
<a name="idr-validate-underlying-resources"></a>

确保您的指标查看有效的底层资源并使用正确的统计数据。如果警报配置为查看无效的资源名称，则警报可能无法跟踪底层数据。这可能会导致警报进入“警报”状态。

## 创建复合警报
<a name="idr-create-composite-alarms"></a>

如果您向事件检测及响应服务运维团队提供大量要加入的警报，则可能会要求您创建复合警报。复合警报可减少需要加入的警报总数。