3 ms·
I 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 d
by sa46 6y ago
I 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.