AWS Cloudwatch 警报状态更改延迟

Question

我有一个警报，用于跟踪单个 ALB 中 LoadBalancer 5xx 错误的指标。如果过去 1 中的 1 个数据点高于阈值 2，这应该处于“警报中”状态。周期设置为 1 分钟。查看报警详情：

2020 年 9 月 23 日 17:18 UTC，负载均衡器开始返回 502 错误。这显示在下面的 Cloudwatch 指标图表中，我已经确认时间是正确的（这是一个强制的 502 响应，所以我知道我什么时候触发了它，我可以在 ALB 日志中看到 17:18 时间戳）

但在警报日志中，“警报中”状态仅在 UTC 时间 17:22 触发 - 在 17:18 时段出现超过 2 个错误后的 4 分钟。这不是接收通知的延迟——与我的预期相比，这是关于状态变化的延迟。在状态更改后的几秒钟内正确接收到通知。

这是带有状态更改时间戳的警报日志：

我们认为缺失数据为 GOOD，因此根据指标图，我假设它应该在 17:22 恢复到 OK（在 17:21 之后出现 0 个错误），但仅在 17:27 恢复到 OK -延迟 5 分钟。

然后我预计它会在 17:24 返回“处于警报状态”，但直到 17:28 才返回。

最后，我预计它会在 17:31 恢复正常，但直到 17:40 - 整整 9 分钟。

为什么在我预期状态转换和实际发生之间会有 4-9 分钟的延迟？

Answer 1

我认为在以下AWS论坛中给出了解释：

。 Unexplainable delay between Alarm data breach and Alarm state change

基本上，警报会在更长的时间内评估，而不是您设置的时间，而不仅仅是 1 分钟。句号是evaluation range，作为用户，你不能直接控制它。

来自论坛：

HTTPCode_Target_4XX_Count 指标的报告标准是是否存在非零值。这意味着只有在生成非零值时才会报告数据点，否则不会向指标推送任何内容。

CloudWatch 标准警报每分钟评估一次其状态，无论您为如何处理丢失数据设置什么值，当警报评估是否更改状态时，CloudWatch 会尝试检索比评估周期指定的更多数量的数据点 ( 1 在这种情况下）。它尝试检索的数据点的确切数量取决于警报周期的长度以及它是基于具有标准分辨率还是高分辨率的度量。它尝试检索的数据点的时间范围是评估范围。 如果评估范围内的所有数据都缺失，而不仅仅是评估期间的数据缺失，则将缺失数据视为应用设置。

因此，CloudWatch 警报将查看一些以前的数据点来评估其状态，如果评估范围内的所有数据都丢失，则会使用处理丢失数据作为设置。 在这种情况下，对于警报没有转换到 OK 状态的时间，它使用评估范围内的先前数据点来评估其状态，正如预期的那样。

此处详细解释了丢失数据时的警报评估，这将有助于进一步理解这一点： https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-evaluating-missing-data