6 ms·
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,
by bitbckt 6y ago
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/ https://www.w3.org/TR/trace-context/
- jeffbee 6y agoEven 32 bytes is completely over the top for trace ID. Even the 16 bytes in this spec is pretty much just wasted space.
- sa46 6y agoI think Datadog's trace_id is 64 bits which I thought was a good balance between efficiency and uniqueness. Pretty sure Dapper used 64 bits as well. 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?
- tignaj 6y agoDisclaimer: I work on OpenTelemetry spec. Many tracing solutions settled on 128bits/16 bytes trace ids. Here is Jaeger's rationale: https://github.com/jaegertracing/jaeger/issues/858 https://github.com/jaegertracing/jaeger/issues/858 It is also recommended by W3C: https://www.w3.org/TR/trace-context/#trace-id https://www.w3.org/TR/trace-context/#trace-id
- jeffbee 6y agoNeither Jaeger nor W3C seem to present any justification for 16 byte trace identifiers, just FUD.
- bitbckt 6y agoBigBrotherBird (now OpenZipkin... thanks legal, sigh) used 128b trace_ids when we first built it at Twitter. I don’t recall the reasoning, but that’s the first system I know of which chose that size. 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.