https://skywalking.apache.org/docs/main/v10.1.0/en/setup/backend/zipkin-trace/#lens-ui
skywalking 服务端可以接收 OpenTelmetry sdk 直接上报 OTEL 的格式数据，或者 Zipkin 的数据格式。
但是 Skywalking 服务端接收到这类数据后，只会直接进行存储，以及提供针对这类数据的查询接口；
而不会解析这类数据；针对这类数据可以直接通过，Skywalking 的：http://127.0.0.1:8080/zipkin 这个路径去查看；
这个路径实际是 Skywalking 的 webui 又内嵌了一份 Zipkin 的 ui，由这个 ui 通过 Skywalking 提供的查询接口，去查询原Zipkin 上报的数据格式数据。
由于Skywaling 本身并不会去解析 Zipkin 的数据，所以 Zipkin 的数据是无法和 Skywalking 的链路进行串联的。
比如，我当前采用 Opentelmetry 的 ios sdk，构建完对应的链路，export 导出数据时导出为 jaeger 的数据格式；
此时这批数据，由 Skywalking 的服务端采用 jaeger 的 receiver（接收器）进行了接收。
然后该 APP 端请求服务端应用时，服务端是采用的Skywalking 的 Agent 构建的链路，这部分链路也是会发送到 Skywalking 的服务端进行存储。
但是 Skywalking 只会解析自己的格式数据，在自己的 UI 上进行展示。
此时 APP 端的链路是无法和云端的链路进行串联在一起的。
如果需要将 APP 端链路请求和云端的链路请求全部串联在一起，最好的方案还是统一一套 收集器（server）
如：APP 端采用 Opentelmetry SDK
云端采用 OpenTelmetry Agent
两边的数据都是发给 OpenTelmetry 的 Collect；
此时的数据串联是完全没问题的；
然后由 Jaeger 来提供 UI 展示即可。
https://mp.weixin.qq.com/s/28EkjCIKfWWsdzEBB_Z0Kg
看到这个文章，发现 Opentelmetry 的 collecter 也支持了针对 skywalking 的 receiver
也就是 Skywalking 的 agent 上报的 Skywalking 的数据格式，可以通过这个 receiver 进行解析为 OpenTelmetry 的格式，然后再由 Opentelmetry 将该数据进行解析存储。
我本地的几个 case 路径：
1、/Users/zhihaozhao/IdeaProjects/observable/observable-learn/opentelemetry-java-examples-main
这个是 opentelmetry 的官方示例。
对应的仓库地址是：https://github.com/open-telemetry/opentelemetry-java-examples/tree/main/otlp
2、/Users/zhihaozhao/docker/skywalking-apm-10.1.0/apache-skywalking-apm-bin/bin
本地安装了一个 10.1.0 的版本，路径是这个；
3、/Users/zhihaozhao/IdeaProjects/observable/observable-learn/observable-learn
这个是本地项目接入 Skywalking 的 agent