Prometheus远程写入接收端与主动采集的Stale Metrics行为差异咨询

核心差异根源：两种模式的数据源状态追踪逻辑不同 #

1. 主动采集场景（Prometheus拉取Fluent Bit指标） #

• 当Fluent Bit停止后，Prometheus的采集请求会持续失败，此时Prometheus会将该采集目标标记为down状态。
• 对于处于down状态的目标，Prometheus会立即为该目标下的所有关联指标生成stale标记，不会等待默认的5分钟 stale 周期。
• 这种情况下，查询该指标时，图表会在采集停止的时间点直接中断，不会沿用最后一次采集到的值。

2. 远程写入场景（Fluent Bit推送数据到Prometheus） #

• 远程写入是推送模式，Prometheus作为接收端，无法主动感知数据源（Fluent Bit）的在线状态，只能通过指标的上报时间戳判断有效性。
• 当某指标停止上报后，Prometheus会在query.lookback-delta（默认5分钟）的时间窗口内，继续返回该指标的最后有效值；超过窗口后，才会标记为stale并中断图表。

关于query.lookback-delta的生效范围 #

• query.lookback-delta参数仅针对正常在线的数据源中偶尔缺失的指标点生效：当某个活跃数据源的某指标偶尔一次没上报时，Prometheus会向前回溯这个时间窗口查找最近的有效值。
• 但如果数据源已被标记为down（主动采集场景），该参数不会触发，因为Prometheus直接判定该目标下所有指标已失效。

内容的提问来源于stack exchange，提问作者jellineksara