事件检测及响应服务中的 CloudWatch 警报使用案例示例

以下使用案例提供了如何在事件检测及响应服务中使用 Amazon CloudWatch 警报的示例。这些示例演示了如何配置 CloudWatch 警报来监控各项 AWS 服务的关键指标和阈值，从而使您能够识别和应对可能会影响您应用程序和工作负载可用性及性能的潜在问题。

使用案例示例 A：应用程序负载均衡器

您可以创建以下 CloudWatch 警报来指示潜在的工作负载潜在影响。为此，您需要创建一个指标数学表达式，当成功连接数降至特定阈值以下时，便会发出警报。有关可用的 CloudWatch 指标，请参阅应用程序负载均衡器的 CloudWatch 指标

指标：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。

统计数据：Sum

下图显示了使用案例 A 的流程：

示例使用案例 B：Amazon API Gateway

您可以创建以下 CloudWatch 警报来指示潜在的工作负载潜在影响。为此，您需要创建一个复合指标，当 API Gateway 中存在高延迟或 4XX 错误平均数量较高时发出警报。有关可用的指标，请参阅 Amazon API Gateway 维度和指标

指标：compositeAlarmAPI Gateway (ALARM(error4XXMetricApiGatewayAlarm)) OR (AALARM(latencyMetricApiGatewayAlarm))

命名空间：AWS/API Gateway

ComparisonOperator(阈值)：大于客户的阈值 x 或 y。

时间段：60 秒

DatapointsToAlarm：1/1

缺失数据处理：将缺失数据处理为 notBreaching。

统计数据 – 。

下图显示了使用案例 B 的流程：

示例使用案例 C：Amazon Route 53

您可以通过创建 Route 53 运行状况检查来监控您的资源，这些检查使用 CloudWatch 收集原始数据并将其处理为近乎实时的可读指标。您可以创建以下 CloudWatch 警报来指示潜在的工作负载潜在影响。您可以使用 CloudWatch 指标创建警报，以便在超出既定阈值时触发该警报。有关可用的 CloudWatch 指标，请参阅 Route 53 运行状况检查的 CloudWatch 指标

指标：R53-HC-Success

命名空间：AWS/Route 53

阈值 HealthCheckStatus：3 分钟内 3 个数据点的 HealthCheckStatus < x（x 是客户的阈值）

时间段：1 分钟

DatapointsToAlarm：3/3

缺失数据处理：将缺失数据处理为 breaching。

统计数据：Minimum

下图显示了使用案例 C 的流程：

示例使用案例 D：使用自定义应用程序监控工作负载

在这种情况下，花点时间定义适当的运行状况检查至关重要。如果您仅验证应用程序的端口是打开的，则说明您并未验证该应用程序是否正常运行。此外，调用应用程序的主页不一定是确定该应用程序是否正常运行的正确方法。例如，如果应用程序同时依赖一个数据库和 Amazon Simple Storage Service（Amazon S3），则运行状况检查必须验证所有元素。一种方法是创建一个监控网页，例如 /monitor。监控网页会调用数据库，以确保它可以连接并获取数据。而且，监控网页会调用 Amazon S3。然后，您再将负载均衡器上的运行状况检查指向 /monitor 页面。

下图显示了使用案例 D 的流程：