AWS Cloudwatch 警报状态更改延迟

Question

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

世界标准时间 2020 年 9 月 23 日 17:18，负载均衡器开始返回 502 错误。这显示在下面的 Cloudwatch 指标图表中，并且我已确认时间是正确的（这是强制 502 响应，因此我知道何时触发它，并且可以在 ALB 日志中看到 17:18 时间戳）

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

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

我们认为缺失数据是好的，因此根据指标图，我认为它应该在 17:22 恢复正常（在 17:21 期间出现 0 个错误之后），但仅在 17:27 延迟 5 分钟时恢复正常。

然后我预计它会在 17:24 恢复为“警报”，但直到 17:28 才恢复。

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

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

Answer 1

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

。警报数据泄露和警报状态更改之间存在无法解释的延迟

基本上，警报的评估时间比您设置的时间更长，而不仅仅是 1 分钟。该期限是评估范围，作为用户，您无法直接控制它。

来自论坛：

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

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

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

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