prometheus staleness对PromQL查询的影响

1、prometheus staleness

官方文档的解释：
在这里插入图片描述
概括：

运行查询时，将独立于实际的当前时间序列数据选择采样数据的时间戳。这主要是为了支持聚合（sum、avg 等）等情况，其中多个聚合时间序列在时间上不完全对齐。由于它们的独立性，Prometheus 需要在这些时间戳处为每个相关时间序列分配一个值。它通过简单地获取此时间戳之前的最新样本来实现。
如果目标抓取或规则评估不再返回以前存在的时间序列的样本，则该时间序列将被标记为陈旧。如果一个目标被删除，它之前返回的时间序列将很快被标记为过时的。
如果在时间序列标记为陈旧后在采样时间戳处评估查询，则不会为该时间序列返回任何值。如果随后为该时间序列摄取新样本，它们将照常返回。
如果在采样时间戳前 5 分钟未找到样本（默认情况下），则此时不会为该时间序列返回任何值。这实际上意味着时间序列在其最新收集的样本早于 5 分钟或被标记为陈旧之后从图表中“消失”。
对于在其数据中包含时间戳的时间序列，不会标记过时。在这种情况下，将仅应用 5 分钟阈值。
如果您评估像 my_counter_total[10m] 这样的范围向量，它总是返回
评估时间和之前 10 分钟之间的所有数据点。
如果您评估像 my_gauge 这样的即时向量，它将返回之前的最新值
评估时间，但回头看不会超过 5 分钟。
也就是说，当时间序列在过去 5 分钟内没有样本时，它就会“过时”。
这 5 分钟由 -query.staleness-delta 标志控制。改变它很少是个好主意。

2、prometheus staleness data的判定原理

如果一次抓取失败，那么前一次抓取的所有时间序列都将被标记为陈旧；

需要这个的原因是：如果有目标已经消失，不再从服务发现中出现了，此时该目标前五分钟的符合告警的数据应该全部标记为过时数据，不再参与告警评估，否则如果对象已经消失，但还持续查其前五分钟的数据来做告警就不合理，那么将会一直发出五分钟的无效告警，这就会导致垃圾告警的产生。
如果评估前 5 分钟内没有样本，时间序列将被标记为陈旧。

3、prometheus staleness对非范围向量和范围向量的不同处理方式

对于非范围向量选择器则不返回陈旧的数据
对于范围向量选择器则完全忽略陈旧标记

4、example及分析

example：

一个样本在一次scrape上曝光一个时间序列，但在下一次scrape时不曝光，然后再次曝光。时间序列现在的值为 t0=7，t10=stale，t20=9。

分析：

如果在 t=0 到 t=10 之前对即时向量选择器求值，则将返回 7。如果在 t=10 或直到 t=20 之前评估即时向量选择器，则不会返回该时间序列。从 t=20 开始，将返回 9。通过这种方式，时间序列的出现和消失得到了正确处理。也就说t10时刻没有曝光此目标，那么t10之前的数据都会被当作staleness data，被隐藏起来，不返回

范围向量选择器的情况：

范围向量完全忽略陈旧标记，因此 avg_over_time 和 rate 等函数将仅作用于非陈旧样本。例如，对上述数据的 count_over_time 将返回 2

scrape失败的情况：

如果刮擦失败，无论出于何种原因，那么前一次刮擦的所有时间序列都将被标记为陈旧。这避免了当一个目标失败时聚合重复计数，一个新的目标被提出来取代它，但原始目标仍在服务发现中。然而，这确实意味着您在使用 Prometheus 2.x 对即时向量发出警报时需要小心，以确保一次失败的抓取不会中断您的警报

当目标从服务发现中消失时的情况：

目标可能会在下一次抓取被安排之前重新出现，所以不能只写下一个目标消失时下一次抓取的陈旧标记。相反，我们所做的是等到这样一个重新创建的目标已经摄取数据（大约 2 个抓取间隔）之后，然后摄取那些陈旧的标记。如果目标被重新创建，那么这些陈旧的标记将被拒绝，因为 TSDB 只允许附加数据——而不是替换最新或以前时间戳的样本。

目标消失的这种行为取决于 Prometheus 在目标消失后继续运行一段时间，以便可以摄取延迟的陈旧标记。如果普罗米修斯要重启或崩溃，那么它们就会丢失。在这种情况下，如果在评估时间之前的 5 分钟内没有样本，则行为会回退到考虑系列陈旧的 2.0 之前的逻辑。这个逻辑并不完美（这就是现在有陈旧标记的原因），但是对于普罗米修斯重新启动的奇怪时间来说已经足够了。 5 分钟通常适用，因为 PromQL 仅回顾 5 分钟以查找样本。在前面的示例中，只有在 t=320 之前的评估才会返回 9。这样做的一个结果是要避免大于大约 2 分钟的刮擦和评估间隔，因为单个失败的刮擦会遇到这种情况。