DataDog 到 OpenTracing ID - 将 64 位无符号整数转换为 128 位无符号和 64 位无符号十六进制

Question

我正在尝试关联源自 DataDog 的 RUM SDK 的跟踪，这些跟踪由配备 OpenTelemetry 的 BE 命中。基本上试图在Connect OpenTelemetry Traces And Logs上实现DD文档的逆向

OpenTelemetry TraceId 和 SpanId 属性与 Datadog 约定不同。因此，有必要将 TraceId 和 SpanId 从它们的 OpenTelemetry 格式（分别表示为 32 位十六进制字符和 16 位十六进制字符的小写字符串的 128 位无符号整数和 64 位无符号整数）转换为它们的 Datadog 格式（64 位无符号整数） .

在我的 BE 中通过以下方式设置上下文；

(event:any) => {
      if(event.headers) {
        const traceId = event.headers['x-datadog-trace-id']
        const spanId = event.headers['x-datadog-parent-id']
        if(traceId && spanId) {
          const convertedTraceId = convertToOtelId(traceId, 32);
          const convertedSpanId = convertToOtelId(spanId, 16);
          const spanContext: SpanContext = {
            traceId: convertedTraceId,
            spanId: convertedSpanId,
            traceFlags: 1,
            isRemote: true,
          };
    
          return propagation.extract(context.active(), spanContext);
        }
      }
      return ROOT_CONTEXT;
    }

convertToOtelId 正在产生这些结果；

trace id - In: 2245099779221068633, Out: 00000000000000001f28325aa9c79b59

span id - In: 4011377516575614177, Out: 37ab46991f7a64e1

很明显，trace_id 的 128 位 uint 与它的前导零看起来不正确。我是否正确理解了这种转换？

Answer 1

是的，你做得对。额外的前导零表示剩余的未使用位。这是python中的简单交叉检查。

>>>
>>> format(2245099779221068633, "032x")  # The trace ID as 32-byte hexadecimal string
'00000000000000001f28325aa9c79b59'
>>>
>>> format(4011377516575614177, "016x")  # The span ID as 16-byte hexadecimal string
'37ab46991f7a64e1'