Amazon web services AWS Cloudwatch警报状态更改延迟

我有一个警报跟踪单个ALB中负载平衡器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个错误）恢复到OK，但是只在17:27到5min延迟返回到OK。 然后我期望它在17:24回到“警报”状态，但直到17:28才恢复

最后，我希望它在17:31时恢复正常，但它一直持续到17:40——之后整整9分钟

---

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

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

基本上，报警的评估周期比您设定的时间长，而不仅仅是1分钟。这段时间是，你作为一个用户，对它没有直接的控制权

论坛发言：

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

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

因此，CloudWatch报警将查看以前的一些数据点以评估其状态，如果评估范围内的所有数据都丢失，则将使用“将丢失的数据视为”设置在这种情况下，当报警未过渡到正常状态时，它使用评估范围内的先前数据点评估其状态，如预期的那样。

此处详细说明了丢失数据情况下的报警评估，这将有助于进一步了解这一点：

---

谢谢-这解释了为什么OK需要额外5分钟才能切换。但我仍然不清楚为什么警报状态不会立即发生。特别是在评估期内给定--X的1个数据点，1个周期设置（文档中的示例包括3/3），有一个真正的违规数据点，因此它应该将状态设置为报警，没有问题？@TomHarvey没有问题。遗憾的是，我对此没有新的解释。警报评估规则相当复杂，文档在详细说明它们是如何工作的方面做得不好。我从AWS那里得到反馈，他告诉我额外的延迟是cloudwatch ALB度量集合固有的。CloudWatch是一个基于推送的服务，数据是从源服务ELB推送的。预计指标会有一些延迟，这是任何监控系统固有的，因为它们取决于多个变量，例如服务发布指标的延迟、CloudWatch内的传播延迟和摄取延迟等等。我确实理解ALB指标的一致3或4分钟延迟更高。经进一步调查，我发现ALB指标延迟是由于摄入延迟时间为3分钟，此延迟在现阶段无法减少。此外，请注意，CloudWatch OPS和内部服务团队仍在处理此问题，但预计可用时间（ETA）仍然未知。对于由此给您带来的不便，我深表歉意。