Prometheus 接收 OTLP Delta 指标时 otlp-deltatocumulative 与 otlp-native-delta-ingestion 怎么选【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheus如果你的应用通过 OTLP 协议上报 delta 时间性delta temporality的指标而接收端是 Prometheus 内置的 OTLP 接收器就会遇到一个选择Prometheus 提供了两个互斥的实验性 feature flag——otlp-deltatocumulative和otlp-native-delta-ingestion前者把 delta 指标转换成累计cumulative形式再入库后者直接把原始 delta 样本存下来。本文基于 Prometheus 仓库中的 feature flags 文档 和 查询 API 文档说明两者的行为差异、各自的限制以及如何配置启动参数并验证生效结果。前提先确认你的场景是否适合 OTLP 接收器根据 API 文档Prometheus 可以作为 OTLP Metrics 协议的接收器但文档明确指出这不被认为是高效的样本摄取方式只建议用于特定低流量场景不适合用来替代基于 scrape 的摄取。如果你的指标量大优先评估 scrape PrometheusProto 路径。OTLP 接收器默认关闭需要--web.enable-otlp-receiver启用见 命令行参数文档默认值为false。启用后接收端点是/api/v1/otlp/v1/metrics。版本方面OTLP 接收器自 v2.47 引入delta 到 cumulative 的转换能力otlp-deltatocumulative自v3.2引入。两个 flag 各自做什么otlp-deltatocumulative把 delta 转换成 cumulative 后入库--enable-featureotlp-deltatocumulative启用后Prometheus 会把 delta 时间性的 OTLP 指标转换为对应的 cumulative 形式而不是丢弃它们。转换复用的是 OpenTelemetry Collector 的deltatocumulative处理器并且使用其默认设置。文档列出了几个必须知道的行为特征见 feature_flags.md转换过程需要内存状态来按时间序列聚合 delta 增量。Prometheus 重启后该状态丢失聚合从零点重新开始这会导致 cumulative 序列上出现一次 counter reset。该状态会定期清理不活跃的序列对应 deltatocumulative 处理器的max_stale配置。启用它可能带来性能负面影响因为内存状态由 mutex 保护纯 cumulative 的 OTLP 请求不受影响。otlp-native-delta-ingestion不做转换直接存原始 delta--enable-featureotlp-native-delta-ingestion启用后Prometheus 以 delta 形式原样存储收到的样本值不做任何转换。文档同时给出了当前阶段的限制StartTimeUnixNano字段被忽略delta 指标会被赋予 unknown 的指标元数据类型delta 支持处于非常早期的开发阶段摄取和查询流程在未来版本中可能变化。两者互斥两个 flag不能同时启用otlp-deltatocumulative文档写明 This cannot be enabled in conjunction withotlp-native-delta-ingestionotlp-native-delta-ingestion文档也对称地写明了这一点。选一个不要两个都写进--enable-feature。怎么选选择依据集中在一点你希望入库后的指标是什么时间性你的 PromQL 查询按什么语义写。判断条件选择希望指标入库后是 cumulative后续查询沿用标准的rate()、increase()等 counter 函数otlp-deltatocumulative希望保留原始 delta 值能接受用sum_over_time()改写查询且能接受早期阶段的行为变化otlp-native-delta-ingestion需要特别注意的是选 native delta 意味着查询方式要改变文档明确说明rate()、increase()这类标准 counter 函数是为 cumulative 指标设计的用在 delta 指标上会得出错误结果。在 native delta 下要得到近似结果需要改用见 feature_flags.md 的 Querying 一节# 时间范围内的 delta 值求和 sum_over_time(delta_metric[range]) # 每秒速率 sum_over_time(delta_metric[range]) / range其中range是你查询时替换的实际时间窗口例如5m。文档提醒如果range不是指标采集周期collection interval的整数倍结果可能不理想——例如指标每 10 分钟采集一次而查询写sum_over_time(delta_metric[1m]) / 1mstep 为 1m图上会显示为每 10 分钟一个高值点而不是 10 个较低的恒定值点。选 native delta 时把查询窗口对齐到采集周期。配置与启动以下两条命令分别对应两种选择二者只能启用其中一条--enable-feature本身接受逗号分隔的多个 feature但这两个 delta 选项不可并存。方式一delta 转 cumulativeprometheus \ --config.fileprometheus.yml \ --web.enable-otlp-receiver \ --enable-featureotlp-deltatocumulative方式二原生 delta 摄取prometheus \ --config.fileprometheus.yml \ --web.enable-otlp-receiver \ --enable-featureotlp-native-delta-ingestion如果你的实例已经通过--enable-feature启用了其他 feature把所选 flag 追加到逗号分隔列表中即可但不要同时追加两个 delta 选项。与 OTLP 摄取相关的其他选项otlp:配置段如translation_strategy、promote_all_resource_attributes等在配置文件里配置见 配置文档。这些选项与上面两个 flag 独立不影响时间性选择本身。验证 flag 是否生效Prometheus 提供GET /api/v1/features端点返回当前实例已启用/禁用的 feature 列表其中otlp_receiver分类下就有对应字段。执行curl http://localhost:9090/api/v1/features响应中关注data下的otlp_receiver部分。API 文档给出的示例输出文档示例此处两个字段均为 false表示都未启用{ status: success, data: { otlp_receiver: { delta_conversion: false, native_delta_ingestion: false } } }按上面的启动参数启用某个 flag 后对应的字段应变为trueotlp-deltatocumulative对应delta_conversionotlp-native-delta-ingestion对应native_delta_ingestion另一个保持false。数据层面可以再做一步检查向/api/v1/otlp/v1/metrics发送一个 delta 指标后用查询 API 或 PromQL 查该序列。选方式二native delta时文档给出的查询路径就是上面的sum_over_time(...)形式选方式一deltatocumulative时序列是 cumulative 形式按常规 counter 语义查询。使用中的已知限制以下限制来自文档两种方案各自适用选择前确认你的场景能接受重启导致的状态问题otlp-deltatocumulative的聚合状态在重启后丢失cumulative 序列上会表现为一次 counter reset。native delta 的元数据缺失StartTimeUnixNano被忽略delta 指标被赋予 unknown 元数据类型且该功能处于早期阶段摄取与查询行为可能随版本变化。无法从指标名或标签判断时间性delta 和 cumulative 指标在名称与标签上没有区分标识。如果你同时摄取两种时间性的指标文档建议显式添加自己的标签来区分官方计划未来引入 type labels并可能让 PromQL 函数具备类型感知能力。同一时间戳的重复样本同一时间戳收到多个样本时只保留其中一个不会相加这是 Prometheus 对重复时间戳样本的通用行为。如需聚合必须在发送到 Prometheus 之前完成。federation 场景delta 指标若通过 federation 暴露且摄取间隔与联邦端点的 scrape 间隔不一致时数据可能被错误采集。容量定位整个 OTLP 接收器面向低流量场景不作为 scrape 的替代。相关文档docs/feature_flags.md两个 flag 的完整行为说明与当前 gotchas。docs/querying/api.mdOTLP 接收器端点、/api/v1/features端点与示例输出。docs/command-line/prometheus.md--web.enable-otlp-receiver与--enable-feature的合法取值列表。docs/configuration/configuration.mdotlp:配置段的其他翻译与提升选项。【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考