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-feature=otlp-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-feature=otlp-native-delta-ingestion启用后，Prometheus 以 delta 形式原样存储收到的样本值，不做任何转换。文档同时给出了当前阶段的限制：
StartTimeUnixNano字段被忽略；- delta 指标会被赋予 unknown 的指标元数据类型；
- delta 支持处于非常早期的开发阶段，摄取和查询流程在未来版本中可能变化。
两者互斥
两个 flag不能同时启用：otlp-deltatocumulative文档写明 "This cannot be enabled in conjunction withotlp-native-delta-ingestion"，otlp-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]) / 1m（step 为 1m），图上会显示为每 10 分钟一个高值点，而不是 10 个较低的恒定值点。选 native delta 时，把查询窗口对齐到采集周期。
配置与启动
以下两条命令分别对应两种选择，二者只能启用其中一条（--enable-feature本身接受逗号分隔的多个 feature，但这两个 delta 选项不可并存）。
方式一，delta 转 cumulative：
prometheus \ --config.file=prometheus.yml \ --web.enable-otlp-receiver \ --enable-feature=otlp-deltatocumulative方式二，原生 delta 摄取：
prometheus \ --config.file=prometheus.yml \ --web.enable-otlp-receiver \ --enable-feature=otlp-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 后，对应的字段应变为true（otlp-deltatocumulative对应delta_conversion，otlp-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.md：OTLP 接收器端点、
/api/v1/features端点与示例输出。 - docs/command-line/prometheus.md：
--web.enable-otlp-receiver与--enable-feature的合法取值列表。 - docs/configuration/configuration.md：
otlp:配置段的其他翻译与提升选项。
【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheus
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
