问题描述
我有关于云运行修订请求等待时间等指标的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结合使用，则只有在存在高延迟并且存在请求时，它才会触发。如果不满足这两个条件之一，则应解决该事件。即使没有吸收与延迟相关的新指标（因此警报策略仍认为延迟较高），请求计数也将在指定的持续时间之后停止匹配。
