支持异类 trace-id 的集成

[coanor]

背景

目前用户侧可能使用了多个不同的 trace 技术栈，比如有 skywalking/zipkin/ddtrace 混用的情况，这种场景下，用户的 trace 链路会出现断掉的情况（几个不同的 trace 技术栈，都是用各自自己的 trace-id，导致连不起来）。

需求

需在 DDTrace 和 OTEL 的主流 agent SDK 上兼容其它类 trace 的 trace-id，包括 DDTrace 和 OTEL 彼此之间。

解决方案

一种可行的方案是，在几个主流的 trace SDK 上继承其它异类 trace-id，比如，对 ddtrace-java 而言，一旦发现上游数据中有 skywalking 的 trace-id（一般通过 header 信息传递），则直接沿用 skywalking 这个 trace-id，而不是新生成一个 trace-id。

需考察这种 trace-id 在 DDTrace 或 OTEL 上是否兼容，不同的 trace 技术栈，其 trace-id 长得不一样，不确定在 DDTrace 或 OTEL 中是否有 trace ID 的校验逻辑。如果有这样的校验逻辑，需要绕过这种继承来的 trace-id。

[lrwh]

目前只考虑 ddtrace 与 otel 之间的转换，暂不考虑其他 APM 的转换

[songlonqi-java]

dd 尝试做法

从 dd v1.11 开始已经支持 128 位的 traceID，目前 guance 的版本是 1.12.1。启动命令参数

-Ddd.trace.128.bit.traceid.generation.enabled=true
# 设置透传协议
-Ddd.trace.propagation.style=tracecontext

但是，仅仅在 dd 内部能拿到这个 128 长度的 traceID。最后序列化再发送出去的时候其实还是还是一个 uint64，要想将这个 128ID 传递出去必须修改传输协议中的结构体。 这样的后果就是完全版本不兼容，代码也是很大改动，引起的问题会很多。

我想到的做法是：将 "trace_128_bit_id":xxxxxx 放到 span 的 tags 中。在 DK 收到数据包之后发现有这个 key 则替换掉原始的 trace_id

放入的地方 span.build：

    private DDSpan buildSpan() {
      DDSpan span = DDSpan.create(timestampMicro, buildSpanContext());
      if (span.isLocalRootSpan()) {
        EndpointTracker tracker = tracer.onRootSpanStarted(span);
        span.setEndpointTracker(tracker);
      }
      span.setTag("trace_128_bit_id",span.getTraceId().toString()); 
      return span;
    }

这样做之后，所有的 span 都会在初始化的时候，将这个 key 放进去。

datakit 做法：

    if id, ok := dkspan.Tags["trace_128_bit_id"]; ok {
        fields["trace_id"] = id
    }

在 观测云 链路中，所有的链路 id 都会成为 128 位的。

otel to ddtrace

otel 的客户端发送 http 请求到 dd的服务端：otel默认会在请求头上带上 traceparent:00-815cf7a2d315279413e6ceb43971225f-14f64a9c3fb05612-01 （W3C 规范） 为 "version"-"trace-id"-"parent-id"-"trace-flags"

这样 dd 在收到请求并初始化 span 时就会将 trace-id 作为链路 id，parent-id 作为父 spanID。

效果：

[songlonqi-java]

观测云文档 请参考 这个issue 关闭了。