Closed coanor closed 1 year ago
目前只考虑 ddtrace 与 otel 之间的转换,暂不考虑其他 APM 的转换
从 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 的客户端发送 http 请求到 dd的服务端:otel默认会在请求头上带上 traceparent:00-815cf7a2d315279413e6ceb43971225f-14f64a9c3fb05612-01 (W3C 规范) 为 "version"-"trace-id"-"parent-id"-"trace-flags"
这样 dd 在收到请求并初始化 span 时就会将 trace-id 作为链路 id,parent-id 作为父 spanID。
效果:
观测云文档 请参考 这个issue 关闭了。
背景
目前用户侧可能使用了多个不同的 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。