V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
drymonfidelia
V2EX  ›  程序员

有人能解释一下 OpenTelemetry 这类遥测方案解决了什么问题,和自己写两个 API 把数据存进 MongoDB 有什么区别吗?

  •  1
     
  •   drymonfidelia · 160 天前 · 1780 次点击
    这是一个创建于 160 天前的主题,其中的信息可能已经有所发展或是发生改变。
    10 条回复    2024-05-27 22:14:24 +08:00
    mooyo
        1
    mooyo  
       160 天前
    你数据存了,打算怎么展示?自己写个 dashboard 么?
    你自己的代码能写 API 存进去,其他的组件呢?中间件全自己写一遍么?
    RoccoShi
        2
    RoccoShi  
       160 天前
    主要还是一个规范的统一, 比如传输的数据格式, 传输协议
    BeautifulSoap
        3
    BeautifulSoap  
       160 天前 via Android
    你自己手撸追踪吗,你确定能解决好下面这个问题?
    请求从进入服务器代码那一刻开始,算一个周期 A ,然后进入 controller 到出 controller 是一个周期 B 。B 是 A 的子周期,同时 controller 里调用 service 从开始到结束是另一个周期 C ,周期 C 是周期 B 的子周期。随着你服务的复杂,各种父子周期嵌套,你怎么处理记录这些数据,然后怎么写一套机制让 trace 能比较简单地能在你对应记录的起始和结束部分打点

    最后一个请求里各种父子周期请求你怎么处理展示。这些都不是把数据塞进数据库就能解决的

    而且 OpenTelemetry 除了展示,统一标准接口,还能和 aws xray 这些良好结合。我负责的几个项目就用了 xray ,挺不错的
    RedisMasterNode
        4
    RedisMasterNode  
       160 天前   ❤️ 4
    1. OpenTelemetry 本质是技术标准,对数据设立规范,当然它也一并提供了很多工具,包括 SDK / Collector...
    2. OpenTelemetry (暂时还)没有提供数据展示,因此不管你是自己直接 api 写数据,还是借助 OpenTelemetry Collector 中转,最终都需要一个 Backend 存储和展示数据,例如 Elasticsearch + Jaeger ,Tempo + Grafana ,MongoDB + ?
    3. 当直接将数据写入 MongoDB 时,为了展示,你可能需要自己设计查询服务,也就是放弃了现成的说你上面各种方案;
    4. 如果你用 OpenTelemetry ,它支持以 OTLP 协议(中转、)输出数据,也支持以 Jaeger 、Zipkin 等等各种协议输出数据,它是个万能的转换器;而 Jaeger 、Zipkin 等服务也同时支持了接收 OTLP 协议的数据,所以任何时候你不喜欢某个 Backend 时都可以切换;
    5. OTLP 是 OpenTelemetry 定义的标准,所以它除了在开源项目中使用,也可以对接到云厂商,如果哪天你不想自建 Tracing 平台,想用云商的,OpenTelemetry Collector 输出的数据可以直接到云商,不用二次调整;如果你原来是用 API 写 MongoDB ,那你很显然要改,或者砸钱让云商帮你兼容。

    一句话,OTel 是标准,是协议,是工具集。它存在的意义是让所有可观测性基础设施都对它支持和兼容,不仅仅是 Tracing ,还包括 Metrics 和 Logs 。换个例子,这与数据库为什么要和 SQL 配对是一个道理,你完全可以造一套自己的查询语言,不用 SQL ,但是当你未来想做些什么的时候会举步维艰。
    drymonfidelia
        5
    drymonfidelia  
    OP
       160 天前
    @mooyo 可是 OpenTelemetry 也没有提供 dashboard 也没有提供中间件呀
    mooyo
        6
    mooyo  
       160 天前
    @drymonfidelia 有这样一个标准,自然有人去写 dashboard ,别人写的中间件只要遵循这个标准或者有相应的插件,也能无缝接入观测系统,难道你真打算全部手搓一遍?
    arloor
        7
    arloor  
       160 天前 via Android
    可观测是一个宏大的主题,远远不止存到某个地方。类比数据库吧,反正是 crud ,直接写文件也可以搞,为什么有这么多数据库,还不同类型的数据库
    gazi
        8
    gazi  
       160 天前
    我们这两年在搞这个,使用 OpenTelemetry 可以灵活的接入第三方的比如 prometheus 和 zipkin 之类的监控系统,可以把前端,后端,网络,数据源等相关的符合 open 规范的可观测性数据 都结合起来。目前业界主流的开源监控系统和常用库 都逐渐对 open 提供了支持。主打的就是 灵活,扩展性高,支持组件广泛,开源社区活跃。
    crackidz
        9
    crackidz  
       159 天前
    OpenTelemetry 提供的是统一标准,并且通过生态提供可复用的开源项目。没有这个的话意味着你需要自己手工搓一遍
    RockChinQ
        10
    RockChinQ  
       157 天前
    我最近也在学这个,我是要给我的开源项目的使用量做遥测。之前是自己写了一个[接收、存储、提供接口给 Grafana 的服务端]( https://github.com/RockChinQ/qcg-center)。最近想给其他项目也加上遥测,就不想重复造轮子了,研究 otel 。但感觉 otel 生态非常复杂:我接收到的是 trace spans (比如用户进行了一次请求),而我要展示的是 metrics (比如过去 7 天有多少请求),并且我还需要把 trace spans 存到 mongodb 里,如果用 otel 就得开好几个容器( jaeger/alloy/collector 、prometheus 、grafana ),对于我一个刚起步的项目来说实在是有点庞大了。我也在思考能不能做一个轻松一点的 收、存、展示接口 的 all-in-one 。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5934 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 06:22 · PVG 14:22 · LAX 23:22 · JFK 02:22
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.