How should other forms of trace/span ids be handled?

[pauldraper]

In OpenTracing, there was no requirement for trace and span ids. It was chosen by the tracer implementation.

For example, Datadog uses 64-bit integers as span and trace ids.

Any preferences/ideas for working with backends that use different ids from OpenTelemetry?

[Oberon00]

64 bit is "easy", pad with zeroes. I think any other forms of span-IDs are not really supported by OpenTelemetry, which I think is a shame but difficult to change now. I recommend you to read open-telemetry/oteps#58 "Unseal SpanContext" and in particular open-telemetry/oteps#58 (comment):

You need to have guarantees of the length and format [of a trace/span ID] in some case, even for logging. I think this was discussed as a requirement for OpenTelemetry from the beginning and cannot be changed.

-- @bogdandrutu

[pauldraper]

64 bit is "easy", pad with zeroes.

Or truncate in the case of 128-bit trace IDs?

[Oberon00]

OpenTelemetry does use 128 bit trace IDs. 128 bit Span IDs on the other hand would be a problem. You can shoehorn them in the tracestate however.

[pauldraper]

Sorry, I meant I need to truncate OpenTelemetry trace IDs (128-bit) when exporting to Datadog (64-bit).

I suppose I could add an attribute trace.id with the full trace id.

I don't see anything necessarily wrong with this; just posting here in case I'm getting it wrong.

[Oberon00]

I could add an attribute

That is not possible in statically typed languages like Java (again, see open-telemetry/oteps#58) and I think that is indeed a problem and may become a serious bottleneck of flexibility for vendors wanting to support the API.

[Oberon00]

I feel like with the OTEP 66 Context API there is an opportunity to elegantly rectify this by removing the whole SpanContext from the API and hiding it away in the context. See

• Unseal SpanContext oteps#58 (aforementioned write-up for issues with SpanContext design; pre-OTEP66) by me
• Consider using Context as the unique way to specify parenthood #510 (comment) ("Consider using Context as the unique way to specify parenthood" would remove the only remaining actual usage of SpanContext)
• Two older, pre-OTEP66 discussions:
  • Proposal: Span Context == Span oteps#73 "Proposal: Span Context == Span" by @jmacd
  • Proposal: remove Span oteps#68 "Proposal: remove Span" by @yurishkuro

EDIT: And the often-mentioned OTEP66: https://github.com/open-telemetry/oteps/blob/master/text/0066-separate-context-propagation.md "Context Propagation: A Layered Approach" (open-telemetry/oteps#66) by @tedsuo, recently mostly driven by @carlosalberto

[Oberon00]

Hi! I see this has the after-ga label. But I think if we have this after-ga, we may as well close it as "wontfix", because I feel like this would be a breaking change. @carlosalberto

[carlosalberto]

@Oberon00 So your take is that we should try to work on this before GA instead?

[Oberon00]

I'm not sure. I think we could make the decision not to support this. Otherwise it would be a pretty fundamental change.

[tonglil]

Is this still something that is being thought on?

I've noticed that DD uses the last 64 bits from the 128 bits OTel uses.
https://docs.datadoghq.com/tracing/connect_logs_and_traces/opentelemetry/
https://go.dev/play/p/pUBHcLdXJNy