前言
Opentelemetry 是一款开源的可观测项目，经常被开发人员使用。然而真的想在生产环境上线、将其大规模推广使用，会遇到各种想象不到的挑战。
Databuff 作为一款商业化的可观测工具，为此专门开发了相关特性、用以接管 opentelemetry，能够真正实现 零改造 opentelemetry collector、并直接给出云网空间地图的效果。今天就给大家揭开这层面纱，看看实现后的效果如何。
01 从一个危险的认知说起
“用了 OpenTelemetry，就等于拥有了可观测性”
一个危险的认知在运维圈内悄然蔓延：用了 opentelemtry，就等于拥有了可观测性，这几乎成了一种技术迷信。正是在这种认知下，很多甲方为了运维、研发部门的实际生产需求，敲着会议室白板上复杂的技术架构图，兴奋的上线了 opentelemetry 自研项目。
然而随着开发的逐步深入，一堆问题显现出来：
- 开源探针不稳定，经常把业务“干宕”。
- 银行系统各种专有协议/组件，没有探针开发人员做适配。
3. 架构设计像 “大杂烩”，来一个需求、上一套组件，研发表示 carry 不动。
4. 自研后端性能不行，业务高峰一来，平台直接 “躺平”。
5. 没有产品设计，功能设计支离破碎、前言不搭后语，业务部门疯狂 diss。
6. 日常工作从“业务保障”变成了“自研项目保障”，维护成本比购买商业软件高太多。
接下来，笔者就带大家见识一下，如何优雅的把 opentelemetry 项目接管过来。
02 零改造原项目，10 分钟见证奇迹
甲方原有 opentelemetry 项目做了大量的工作，如探针部署实施、协议改造适配、与 prometheus 等数据的清洗关联。
本次方案在保留原有 opentelemetry 采集端工作的既有基础上，引入 databuff 平台，只需 10 分钟、两个步骤，立马见到因果可观测的落地。
两个步骤：
1）collecotr 接入 datahub 可视化编排管道；
2）daemonset 控制器在每个 Node 上部署一枚 oneagent 探针；
接下来，让我们一起了解配置详情及实现效果。
2.1 datahub 接收 opentelemetry collector 的数据
创建 Pipeline
- 在部署配置 -> 安装部署 -> 数据接入 选择管道模版，创建一个可以接收调用 OTLP 调用链的 Pipeline，直接启动该 Pipeline 即可
点击“新建管道”
点击 OpenTelemetry 算子，右侧详情内容，复制<监听 URL>
配置 Opentelemetry Collector
在 Opentelemetry Collector 运行的 yaml 配置文件中，添加如下 exporter:
exporters: # 添加otlphttp exporter otlphttp: traces_endpoint: "<监听URL>/v1/traces" metrics_endpoint: "<监听URL>/v1/metrics"receivers: # 客户现场自定义，无需修改 otlp: protocols: grpc: endpoint: "0.0.0.0:14317" http: endpoint: "0.0.0.0:14318"processors:service: # 无需修改 pipelines: # 在需要转发的Pipeline中，添加 otlphttp exporter traces01: receivers: - otlp processors: [] exporters: - jiangsuexport01 - otlphttp metrics01: receivers: - otlp processors: [] exporters: - otlphttp
自此，接入 opentelemetry collecotr 的 pipeline 管道配置完成。
2.2 daemonset 控制器一键部署 oneagent
databuff 平台选择环境，部署配置-> 安装部署 -> OneAgent，选择操作系统，直接复制安装命令，一键安装
自此，oneagent 探针部署完成。接下来就登录 databuff 后端查看数据效果。
2.3 因果可观测效果
我们查看该数据管道的状态，发现已经有数据量上来了。
点击“空间地图”，实现的效果如下：
1）这种方案依然实现了空间地图的系统性展示，各 service 节点的基础依赖能够在垂直拓扑中关联起来；
2）除了服务调用，host 相互调用、process 相互调用，能够在水平拓扑中实时绘制起来；
我们继续点击标红的主机节点：host154，查看其资源信息以及服务信息：
点击“系统拓扑”，实现的效果如下：
可查看服务间、系统间调用关系，访问量，以及请求响应指标。
结语：如上，我们通过 datahub、oneagent 两个组件，实现了 opentelemetry 自研项目的数据接管，同样也实现了因果可观测中的空间地图特性，打通了服务与基础资源之间的依赖关系，各基础资源的水平拓扑。我们将这些因果观测数据吐给专门的 aiops 中台（或内置的 aiops 引擎），可以更好的进行运维智能场景的开发落地。
后面的文章，我们会更多的分享，databuff 如何基于开源项目、实现运维智能。
