OpenZipkin B3 Header behavior inconsistent to OpenTelemetry Propagator B3

[nidhi171]

Problem Description:
The Opentelemetry B3 Propagtor definition of TraceId says:

{TraceId}

• Required
• Encoded as 32 or 16 lower-hex characters
• 16 character traceIds will be converted to 32 characters by left-padding with 0s to conform with the OpenTelemetry specification

However Openzipkin-B3 suggests that The TraceId is 64 or 128-bit in length and indicates the overall ID of the trace.

Why is there an inconsistency b/w the two? This is causing a slight issue on our end since one of our services uses OpenZipkin and the other Open telemetry. We propagate 64 bit B3 Headers but OpenTelemetry left pads 0s and converts it into 128 bit making us do extra work while searching in the logs. Is there a way to either enable left padding in both vs suppress in both?

Any recommendations are appreciated.

[basvanbeek]

Hi @nidhi171

The make a long story short, the problem here is OpenTelemetry. They have chosen to ignore existing behavior for 64bit trace id's in the Zipkin owned B3 context specification which by far (years!!!) predates OpenTelemetry. Zipkin B3 has actual site owners depend on stability and backward compatibility, just like you, regardless of the existence of OpenTelemetry.

We've made our decisions to also support 128bit trace ids based on very large site owners with high throughput and/or long storage requirement retention rates. Most users really don't need 128 bit and 64 bit keeps payloads and contextual logs smaller.

We went through a very conscious and deliberate effort support 128 bit for those large site owners providing for best operability for 64 bit deployments and hybrid mode transitions. You can see some of the ideas around how we got to that point with our ecosystem here: openzipkin/zipkin#1298

The right thing for OpenTelemetry should have been to support unambiguously the exact spec of B3 as it is a standard with a large ecosystem and existing production users for years prior to OTel.

It makes little sense to implement another non native OTel spec and then not follow the existing spec to the letter as it creates unwanted side effects.

My suggestion is to take it up with the OTel community and request either a change to follow the spec and if they start about "existing users" at least provide a switch for B3 users to have them remove the padding from trace id.

[shakuzen]

one of our services uses OpenZipkin

If the tracer library that service is using can be configured to use 128 bit trace IDs, then there won't be any padding by OTel because it will produce and propagate a 128 bit trace ID. Though as Bas pointed out, it's unfortunate to have to do this when you otherwise don't need 128-bit trace IDs.