Prometheus 如何用 created-timestamp-zero-ingestion 特性注入起始时间戳零值样本【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheus如果你的监控目标在启动后开始上报 counter 类指标但 Prometheus 拿不到该指标“从何时开始累计”的信息那么第一段数据的 rate 计算就会因为缺少起点而不准确。created-timestamp-zero-ingestion特性就是为这个场景设计的在 Prometheus 启动参数中启用它之后当被抓取的应用通过支持的格式暴露 start timestamp起始时间戳时Prometheus 会在合适的时机把起始时间戳以 0 值样本的形式注入 TSDB。要完成这个任务需要满足一个前提条件除了启用特性本身被抓取的应用必须真正暴露 start timestamp。文档中列出的支持范围只有两种抓取格式PrometheusProtoPrometheus Protobuf 协议OpenMetrics1.0.0启用特性启动参数说明该特性属于默认关闭的 feature flag实验性功能通过--enable-feature传入逗号分隔的特性名来启用这一点在 feature flags 文档 和 命令参考 中都有记载——--enable-feature的合法选项列表里包含created-timestamp-zero-ingestion。结合命令参考中--config.file的默认值prometheus.yml启用该特性的启动命令为prometheus --config.fileprometheus.yml --enable-featurecreated-timestamp-zero-ingestion需要说明两点该 flag 的名字沿用的是旧的CreatedTimestamp命名特性本身后来被更名为StartTimestampflag 名称保持不变是为了稳定性见 feature flags 文档 中的 NOTE。作为默认关闭的实验性特性其行为可能在后续版本中变化变化会通过 CHANGELOG 发布。启用前建议确认所用版本支持该 flag可执行prometheus --help查看--enable-feature的合法选项列表中是否包含created-timestamp-zero-ingestion。启用后 scrape_protocols 的默认值会变化启用created-timestamp-zero-ingestion会连带改变一个默认配置全局scrape_protocols的默认值变为[ PrometheusProto, OpenMetricsText1.0.0, OpenMetricsText0.0.1, PrometheusText0.0.4 ]结果是抓取时优先协商 Prometheus Protobuf 协议——除非你在配置中显式把scrape_protocols设置成了别的值见 feature flags 文档 与 抓取配置说明。这个默认值调整直接服务于当前任务start timestamp 只有走PrometheusProto或OpenMetrics1.0.0才能传到 Prometheus。因此如果你在 配置文档 描述的global或 scrape config 中显式配置了scrape_protocols需要确认列表中仍包含PrometheusProto推荐或OpenMetricsText1.0.0否则起始时间戳信息无法传递。为什么文档推荐 PrometheusProto在两种支持格式之间文档明确推荐PrometheusProto原因是OpenMetrics 1.0 的 Start Timestamp 是通过metric_created这样的独立 metric 来携带的解析这类 metric 容易出错且开销较大如果处理不当Prometheus 会被额外的_created系列指标污染。这一点在 CHANGELOG 中也有对应记录当created-timestamp-zero-ingestion启用时Prometheus 不再为 start timestamp 创建额外的_created时间序列#14738。也就是说启用该特性后你不需要也不应该看到一堆独立的_created序列——起始时间戳直接体现为注入的 0 值样本。验证注入是否生效文档给出的可核对点有两个特性开关状态。API 文档 的示例响应中包含如下字段文档示例false对应特性未启用的状态scrape: { start_timestamp_zero_ingestion: false, extra_metrics: false }启用 flag 并重启后查看该响应中scrape.start_timestamp_zero_ingestion是否变为true可以确认 Prometheus 已经按新配置运行。0 值样本的行为。文档对该特性的描述是“Start timestamps are injected as 0 valued samples when appropriate”——即只有当目标确实暴露了 start timestamp 且通过支持的格式传输时才会在起始时间戳处出现 0 值样本。若你的目标没有暴露 start timestamp启用该 flag 不会产生任何注入效果这属于预期行为。另外可以按上文说明检查_created系列启用特性后TSDB 中不应出现由 start timestamp 派生的额外_created时间序列。已知限制与相关特性特性当前只覆盖PrometheusProto和OpenMetrics1.0.0两种格式其他文本格式的 target 无法传递起始时间戳。feature flags 文档 中同时介绍了st-storage特性它通过 WAL、TSDB/Agent 和 Remote-Write 2.0 按样本存储精确的 start timestamp 值文档称其在未来将取代当前这种“注入合成 0 样本”的方式。st-storage目前标注为实验性且带有限制例如引入了仅 Prometheus 3.11 或更高版本才能回放的新 WAL 记录类型两者的适用范围不同本文只涉及created-timestamp-zero-ingestion的 0 值样本注入路径。该特性是实验性 flag未来版本行为可能调整升级 Prometheus 时应以 CHANGELOG 中created-timestamp-zero-ingestion相关条目为准核对行为变化例如 OTLP 路径在启用该 flag 后也会把 metric 的 start time 作为 created-time 0 值样本写入 TSDB#16951。【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考