Alerting: Recording rules do not write stale markers

概述

在基于 Prometheus 的可观测性体系中，数据的新鲜度和准确性是系统可靠性的基石。录制规则（Recording Rules）用于预计算常用或复杂的查询结果，以提升查询性能和为告警提供稳定的指标。当录制规则所依据的源指标消失时，理想的行为是该规则生成的时间序列也应标记为过期并最终停止。本文描述了 Grafana 托管的录制规则在此场景下的一个缺陷：它不会向目标数据源写入过期标记，导致已过期的数据可能被错误地持续使用。

核心概念

时间序列过期（Staleness）

在 Prometheus 数据模型中，当一个时间序列不再产生新的样本点时，Prometheus 引擎会将其视为“过期”。这是数据生命周期管理的重要机制，确保查询不会无限期地返回陈旧或已终止的指标值。

过期标记（Stale Marker）

过期标记是一种特殊的 NaN 值（具体表现为 __name__="..." 标签被移除），它通过远程写入（Remote Write）协议发送到接收数据源（如 Thanos、Cortex 或另一个 Prometheus 实例）。其核心作用是显式通知下游系统：“这个时间序列已经结束”。收到过期标记的系统会将该序列的状态更新为过期，从而在查询时正确处理。

Prometheus 的默认行为

原生 Prometheus 在录制规则停止输出某个时间序列时，会主动生成并写入一个过期标记。这确保了指标的连续性正确反映了其生命周期。例如，一个每两分钟产生一次数据的指标，如果在两次生成之间源数据消失，Prometheus 会在评估时发送过期标记，使得该时间序列在图表上表现为断开或结束，而不是一直显示上一次的值。

实践

根据问题报告，可以通过以下步骤复现 Grafana 与原生 Prometheus 在过期标记行为上的差异：

准备相同的源指标：确保有一个源指标（例如通过远程写入或应用暴露）会间歇性地产生数据，例如“每两分钟产生一次”。
在 Grafana 中创建录制规则：在 Grafana 的告警/录制规则界面中，使用与 Prometheus 相同的查询表达式创建一个录制规则。
在 Prometheus 中创建相同的录制规则：在原生 Prometheus 实例中，配置并创建一个完全相同的录制规则。
观察结果：
- Prometheus 录制规则：当源指标在两次预期生成之间消失时，对应的录制规则生成的时间序列会正确写入过期标记，其数据点间会出现明显的间隙。
- Grafana 录制规则：即使源指标已消失，Grafana 托管的录制规则生成的时间序列仍会持续存在，不会收到过期标记。这意味着该时间序列会一直保留最后一次的值，并可能在图表上显示为一条连续的、永不结束的直线，造成数据持续存在的假象。

问题影响：这种行为差异会导致使用 Grafana 录制规则的下游消费者（如仪表板、告警规则）基于错误的数据进行决策。例如，一个依赖于指标变化率的告警可能永远不会触发，因为指标值看起来是“稳定”的，而实际上源数据早已停止。

SRE 要点

与可靠性、可观测性、事件响应的关联

数据完整性：此问题直接破坏了监控数据的完整性。SRE 依赖准确、及时的数据来评估系统状态（SLO）和做出运维决策。错误的数据可能导致误报（False Positive）或漏报（False Negative）。
事件响应：在故障排查期间，SRE 可能会查看录制规则的历史数据以追溯问题。如果时间序列没有正确结束，可能会误导工程师，认为某个服务或指标在故障期间仍“正常”运行。
告警准确性：许多告警规则基于录制规则的输出。过期标记的缺失会使告警规则无法感知指标的终止，可能导致告警逻辑失效。

最佳实践与常见反模式

最佳实践：理解并验证你的监控管道中每个环节对时间序列过期的处理能力。对于关键的录制规则，建议在测试环境中模拟指标消失的场景，验证其行为是否符合预期。
常见反模式：盲目信任所有监控管道中数据的“新鲜度”，而没有进行端到端的验证。认为“数据一直存在”就等于“系统一直健康”，忽略了数据流本身可能存在的故障（如本次的过期标记缺失）。
规避方案：在 Grafana 修复此问题前，SRE 团队可能需要考虑使用原生 Prometheus 的录制规则作为核心监控数据的来源，或在 Grafana 录制规则输出之上添加额外的“心跳”或“存活”检测逻辑来间接判断时间序列是否活跃。