解决不再有可用数据的时间序列违反策略时解决堆栈驱动程序事件

如何解决解决不再有可用数据的时间序列违反策略时解决堆栈驱动程序事件

我有关于云运行修订请求等待时间等指标的stackdriver警报/事件。

如果很久以前有几个呼叫具有高延迟，但是此后没有任何新请求具有低延迟，则该事件将永久触发。这是因为当没有新请求传入时，该度量标准就没有数据点。

当基础指标没有最新数据点时，是否有一种方法可以自动阻止事件触发？还是有另一种方式来对云中的高请求延迟发出警报，从而在没有新的高延迟请求出现时自动再次关闭警报？

解决方法

https://stackoverflow.com/a/63997540/6473907的解决方案无法按原样工作，因为当没有更多请求进入时，针对请求计数的google cloud运行内置指标不会变为零。相反，它只是停止了提供任何数据点。我们的解决方案是创建一个基于日志的自定义指标，该指标对云运行为每个请求编写的日志条目进行计数，因为基于日志的指标的确确实为零，然后将其与AND_WITH_MATCHING_RESOURCE结合使用，如下所述在https://stackoverflow.com/a/63997540/6473907

中

图表将从Google预定义指标run.googleapis.com/request_count（以紫色显示）获得的请求计数与由基于日志的自定义指标（以蓝色显示）生成的指标进行比较。没有更多请求进入时，只有后者变为零。

,

编辑：此解决方案将无法正常工作，因为请求计数将停止发送到Stackdriver，而不是降至零。如other (more correct) answer中所述，解决方案是为请求创建基于日志的指标，当没有其他请求时，该指标将适当地降低为零。

---

此行为记录在alerting docs中：

如果缺少测量值（例如，如果没有HTTP） 请求几分钟），该策略将使用最后记录的时间 价值来评估条件。

那里有一些建议可以缓解此问题，但是所有建议都假设您实际上是在收集指标，而不是根本没有指标的情况（因为您停止接收请求）。

这可能是设计使然：即使您没有收到其他请求，您仍可能要检查为什么所有最新请求的延迟都增加了。

要变通解决此功能，您可以尝试在警报策略中使用multiple conditions：

• 与延迟有关的一个条件：如果延迟> X
• 与请求存在有关的一个条件：如果请求计数> 1

如果将它们与AND_WITH_MATCHING_RESOURCE结合使用，则只有在存在高延迟并且存在请求时，它才会触发。如果不满足这两个条件之一，则应解决该事件。即使没有吸收与延迟相关的新指标（因此警报策略仍认为延迟较高），请求计数也将在指定的持续时间之后停止匹配。