I don't use any of their libraries, but follow the spec closely.
At the very least, it's forcing some standardization among APM vendors (DataDog 64b trace_id, I'm looking at you).
Also, related: https://www.w3.org/TR/trace-context/
At the very least, it's forcing some standardization among APM vendors (DataDog 64b trace_id, I'm looking at you).
Also, related: https://www.w3.org/TR/trace-context/
I also don't understand the purpose of the 16 bytes for the trace_id in the spec. That's a huge range of numbers. Anyone know the rationale?
Many tracing solutions settled on 128bits/16 bytes trace ids. Here is Jaeger's rationale: https://github.com/jaegertracing/jaeger/issues/858
It is also recommended by W3C: https://www.w3.org/TR/trace-context/#trace-id
Dapper used 64b IDs for span and trace, but being locked inside the Googleplex probably limited its influence on compatibility issues.
My point is that 128b is the common standard now, and that’s all that I really care about - that the standard exists and APM systems conform to it. To that end, I am very pro-otel.
Thanks for your work.