前传

我司（前司）之前有个前辈（叫新一，没有工藤）打算搞Skywalking，被老板拒绝了。

今年业务复杂度骤升，系统间调用太复杂了，出一个生产事故就是排查一整天。

到了我的时间线，观测大厂的大佬来~~交流技术~~（推销），拿着他们的链路demo+指标数据看板一波演示，老板就被说服了，咧着个大嘴笑着拍拍我肩膀说“这个好啊，咱（zǎn）们搞个一模一样的”。

下面摘抄一段自己的简历

背景（2022.12-2023.02）

1024PaaS产品接棒ShowMeBug之后，架构发生极大变化，新场景下业务复杂度骤升，一旦出现线上问题，排查定位问题难、海量数据难以分析。

各产品部门原本采用的观测性方案有差异(1024PaaS采用的是Grafana+Loki+Prometheus，ShowMeBug采用的是ELK)，且观测性能力参差不齐，数据难以打通，逐渐暴露出了“数据孤岛”问题。

new OpentelemetrySDK()

经过我的观测性工具调研与demo搭建团队试用，最终敲定采用Opentelemetry框架+观测云数据看板的方式来实施改造。

改造过程

Trace: 在Java、NodeJS、JavaScript、Ruby各个语言的产品/组件之间，通过最少代码侵入来实现数据埋点与全链路操作的串联
Log: 所有服务调整改造日志组件，在日志注入Trace上下文
Metric: 除了原生的JVM信息，主机/容器的CPU/MEM信息等指标外，还额外添加了公司业务关注的指标信息

业绩:

最终效果满足预期设计（我的技术角度预期，不是老板的乐呵呵心里预期），极大方便了日常的问题定位和性能瓶颈分析，

实现在 Trace 面板可以根据用户 id 、昵称等信息，快速筛选所有相关的 Span (接口/方法调用);
实现通过日志找到对应 Trace 链路，以及实现 Trace 链路可跳转到关联的日志上下文;
通过 Metrics 中加入一些满足规则的 Trace 作为 exampler ，实现了指标数据异常时快速分析关联链路;
通过接入观测云的 RUM ，实现了用户在浏览器中一次会话期间所有操作可溯源，所有报错可查看，所有 Trace 链路可查询可以看到，我们建立了一个较为完整的观测性系统。

附：接入方案调研

可选方案

~~OpenTracing~~

已停止维护，并入OpenTelemetry
OpenTelemetry
- 优点 👍：
  1. 开源、MTL（Metrics + Traces + Logs）数据统一
  2. 生态繁荣，蓬勃发展
- 缺点 👎（缺点貌似都不是它的错，~~是我太菜~~，要多看文档多实践）： >
  1. 技术比较新，需要啃螃蟹
  2. 中文资料较少，缺乏可借鉴的生产落地经验
- 已知问题：
  1. Span自定义属性无法在父子级间传递/继承（目前没有该特性，有两种曲线方案。
  2. a.代码中可以使用Baggage传递业务信息
  3. b.或者如下方issue中提出的，自定义SpanProcessor?）
  How to stamp a "tenant id" attribute on all spans? · Issue #3456 · open-telemetry/opentelemetry-java
  
  Inheritable Attributes · Issue #1337 · open-telemetry/opentelemetry-specification
  
  Inheritable Attribute · Issue #14026 · open-telemetry/opentelemetry-collector-contrib
  1. 基于自动检测生成的tracing链路可读性不高？
  2. 基于自动检测生成的tracing链路不完整？（使用姿势有问题？）
dd-trace(datadog)
1. 优点：成熟的商业公司开源出来的产品。落地案例较多
2. 缺点：没有直接支持Socket.io等技术组件，同时go sdk缺乏更多文档支持？