GoForum🌐 V2EX

有了 Prometheus,还有必要让指标数据经过 OpenTelemetry 一趟,不是很反人类吗?

Proposal · 2026-04-24 15:35 · 0 次点赞 · 2 条回复

一直有个疑问:明明已经在用成熟的 Prometheus 做指标监控,为什么还要强行让指标数据多走一层 OpenTelemetry 呢?

最奇怪的地方,OpenTelemetry Collector 根本就不支持 Remote Write (仅支持新版本的 Remote Write ,然而很多地方 Remote Write 都只停留在 v1 )。


老板给的理由(我不赞同但是想列出来讨论):

1 、OpenTelemetry 是标准,有 OpenTelemetry ,以后想切换云服务提供商(我们现在数据写到 New Relic )就不需要担心不兼容。

2 、所有数据(日志、指标等等)都经过 OpenTelemetry Collector ,可以统一做编辑修改,打标签等等。


我想反对的理由:

1 、云服务提供商支持 OpenTelemetry ,那都是最近几年的事情,你一眼看去哪个供应商不支持 Prometheus Remote Write ?这不是一样没有兼容的顾虑吗,大部分指标监控的服务商都用 Prometheus 那套,最大兼容性要说也是 Prometheus ,何时轮到 OpenTelemetry ?(要说日志和 trace 那我不了解不做评判)

2 、全部经 OTel 中转就是个笑话。多一层中转,多一层资源需求,多出来这么多数据、流量请求、编解码压缩,就为了统一打标签? Prometheus 自己 relabeling 不是一样的吗而且一直都是这么用的。


我们的数据量大概每天指标流量开销 400GB 左右( gzip 压缩后),说多不多,说少也不能算玩具规模了起码有点数据。

那么问题来了,

  1. 各位大佬在生产里面指标数据走 OpenTelemetry 吗?有什么明显的好处呢?
  2. OpenTelemetry Collector 不支持 Remote Write v1 这个毛病你们是怎么解决的呢?
  3. 有人真的用了 Remote Write v2 了吗收益大吗?
2 条回复
Proposal · 2026-04-24 15:40
#1

大佬们,要是你们的指标数据不经过 OpenTelemetry Collector ,或者没有在任何环节变成 OpenTelemetry 的数据类型,回个“没有”可好?

我很想直接把这个帖子(希望是清一色的“没有”)糊在老板脸上。

zhoulouzi · 2026-04-24 16:16
#2

看场景

添加回复
你还需要 登录 后发表回复

登录后可发帖和回复

登录 注册
主题信息
作者: Proposal
发布: 2026-04-24
点赞: 0
回复: 0