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

32 天前
 drymonfidelia
1468 次点击
所在节点    程序员
10 条回复
mooyo
32 天前
你数据存了,打算怎么展示?自己写个 dashboard 么?
你自己的代码能写 API 存进去,其他的组件呢?中间件全自己写一遍么?
RoccoShi
32 天前
主要还是一个规范的统一, 比如传输的数据格式, 传输协议
BeautifulSoap
32 天前
你自己手撸追踪吗,你确定能解决好下面这个问题?
请求从进入服务器代码那一刻开始,算一个周期 A ,然后进入 controller 到出 controller 是一个周期 B 。B 是 A 的子周期,同时 controller 里调用 service 从开始到结束是另一个周期 C ,周期 C 是周期 B 的子周期。随着你服务的复杂,各种父子周期嵌套,你怎么处理记录这些数据,然后怎么写一套机制让 trace 能比较简单地能在你对应记录的起始和结束部分打点

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

而且 OpenTelemetry 除了展示,统一标准接口,还能和 aws xray 这些良好结合。我负责的几个项目就用了 xray ,挺不错的
RedisMasterNode
32 天前
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
32 天前
@mooyo 可是 OpenTelemetry 也没有提供 dashboard 也没有提供中间件呀
mooyo
32 天前
@drymonfidelia 有这样一个标准,自然有人去写 dashboard ,别人写的中间件只要遵循这个标准或者有相应的插件,也能无缝接入观测系统,难道你真打算全部手搓一遍?
arloor
32 天前
可观测是一个宏大的主题,远远不止存到某个地方。类比数据库吧,反正是 crud ,直接写文件也可以搞,为什么有这么多数据库,还不同类型的数据库
gazi
32 天前
我们这两年在搞这个,使用 OpenTelemetry 可以灵活的接入第三方的比如 prometheus 和 zipkin 之类的监控系统,可以把前端,后端,网络,数据源等相关的符合 open 规范的可观测性数据 都结合起来。目前业界主流的开源监控系统和常用库 都逐渐对 open 提供了支持。主打的就是 灵活,扩展性高,支持组件广泛,开源社区活跃。
crackidz
31 天前
OpenTelemetry 提供的是统一标准,并且通过生态提供可复用的开源项目。没有这个的话意味着你需要自己手工搓一遍
RockChinQ
29 天前
我最近也在学这个,我是要给我的开源项目的使用量做遥测。之前是自己写了一个[接收、存储、提供接口给 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 。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1043751

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX