OpenTelemetry 指标 vs Prometheus 指标：数据模型的深度对比
OpenTelemetry 与 Prometheus 的指标数据模型在时间戳语义、累加方式、直方图结构上存在本质差异，直接影响速率计算与查询结果。本文深入对比两者数据模型，帮助你在迁移或混用时避开数值误读的坑。
OpenTelemetry 指标与 Prometheus 指标的核心差异在于数据模型：OTel 数据点携带起止时间戳并区分 Delta/Cumulative 累加语义，Prometheus 只有抓取时刻的单点时间戳与单调计数器——同一组测量值在两种模型下的查询语义不同，混用时若不理解差异，速率、占比计算都可能出错。
核心要点速览
- OTel 区分 Delta（间隔内增量）与 Cumulative（累计总量），Prometheus 只有 Cumulative；
- OTel 数据点带起止时间戳，速率计算无需依赖抓取间隔；
- OTel 指数直方图（Exponential Histogram）比 Prom 固定边界直方图更省更准；
- 属性命名规则不同：OTel 点分层级（
http.server.duration），Prom 下划线（http_server_duration_seconds）。
累加语义：Delta vs Cumulative
Prometheus 的 counter 只记录「自启动以来的累计值」，速率由 rate() 在查询时基于两个抓取点估算。
OTel 支持两种 temporality：
- Cumulative：与 Prom 类似，记录累计总量；
- Delta：记录「上个周期内的增量」，速率就是数值本身，无需查询期再算。
Delta 对push 模型与多跳管道更友好（每个间隔的数据独立完整），Cumulative 对断点续传更宽容。观测云对两种语义都能正确解析。
时间戳模型的影响
Prometheus 数据点只有抓取时刻的时间戳，「这个值覆盖哪个时间段」依赖抓取间隔推断——抓取抖动会污染速率计算。OTel 数据点显式携带 start_time 与 time，聚合区间精确可知，在管道多次转发后依然保真。
直方图：固定桶 vs 指数桶
Prometheus 直方图在埋点时固定边界桶（如 0.1/0.5/1/5s），跨实例聚合没问题，但边界选错无法事后补救。
OTel 除兼容固定桶外，提供指数直方图：桶边界按指数自动划分，任意分位数都能事后计算，且体积随精度对数增长——高延迟分布场景更省更准。
命名与单位约定
- OTel：
http.server.request.duration，单位秒（UCUM 标准），属性点分； - Prometheus：
http_server_request_duration_seconds，单位编码进指标名。
混用体系时建议在入库前统一命名，避免同一含义两套指标并存。
观测云落地：双模型统一
- OTLP 指标：原生接收并正确解析 Delta/Cumulative 语义；
- Prometheus 指标：DataKit 抓取或 remote write 接入，文本协议自动转换；
- 统一查询：DQL 对两类数据提供一致的速率与聚合语义；
- 迁移建议：存量 Prom 指标直接接入，新埋点按 OTel 规范（语义约定）实施，渐进统一。
常见问题（FAQ）
Q：Delta 和 Cumulative 查询结果会不一样吗？ 语义正确实现下结果一致；差异在于管道可靠性：Delta 丢一个点只影响一个周期，Cumulative 丢点后速率会毛刺。
Q：OTel 直方图能转成 Prom 直方图吗？ 固定桶直方图可以转换；指数直方图需按目标桶边界重聚合，会有精度损失，建议平台侧原生支持（观测云支持）。
Q：迁移期两套指标并存会不会混乱？ 用命名规范区分（如老指标保留 prom 风格，新指标用 OTel 风格），并在视图中统一别名，过渡期后逐步下线老指标。
Q：Gauge 在两种模型下有区别吗？ Gauge 语义一致（瞬时值），是迁移中最省心的类型；注意 OTel 的 Observable Gauge 是回调读取，Prom 的 Gauge 可直接 set。
