AWS Cloudwatch警报状态更改的延迟

如何解决AWS Cloudwatch警报状态更改的延迟

我有一个警报，在单个ALB中跟踪LoadBalancer 5xx错误的度量标准。如果过去1个数据点的2个阈值以上，则应处于“处于警报状态”。该时间段设置为1分钟。查看警报详细信息：

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

但是在警报日志中，“处于警报中”状态仅在UTC 17:22触发-17:18期间内有2个以上错误后4分钟。这并不是收到通知的延迟-与我的预期相比，状态更改有所延迟。在状态更改后的几秒钟内正确接收到通知。

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

我们认为丢失的数据为“良好”，因此根据指标图，我认为它应该已在17:22恢复到正常（在17:21周期后出现0个错误），但仅在17:27才恢复为正常-延迟5分钟。

然后我希望它在17:24返回“处于警报状态”，但是直到17:28才恢复。

最后，我希望它在17:31恢复正常，但直到17:40才完成-整整9分钟。

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

解决方法

我认为在以下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