I have been watching this group since its inception, waiting for something that I can treat as a standard.
They’re trying—and I am rooting for them—but from the outside it seems piecemeal and scattered, like a side project that is nobody’s real priority. Meanwhile, other initiatives have so much movement as to be unfollowable: Zipkin! No, Jaeger! No, OpenTracing! No, OpenCensus! No, OpenTelemetry!
I am beginning to doubt that we will ever have a standard for distributed tracing.
FWIW the OpenCensus website says: OpenCensus and OpenTracing have merged to form OpenTelemetry, which serves as the next major version of OpenCensus and OpenTracing. You'd never know it if you just looked at the other two websites, though...
And Jaeger has always been on top of OpenTracing. So I guess there's more unity than it seems.
Yeah, it’s all getting stitched together. I would expect v1.0 of OpenTelemetry coming in March, with W3C Trace-Context headers as the default format for context propagation.
Thanks for rooting! I’m sorry it looks confusing. It took several iterations for the humans to converge on a single project, and achieve something like consensus about what we wanted. But it feels like we are there - there’s ~100 working on it now, and I don’t see any remaining blockers.
From the inside, it’s felt like steadily rolling up a larger and larger katamari ball, if you remember that game.
I think it’s incredibly important that a top priority be to put a very clear banner on the OpenCensus and OpenTracing pages explaining that they are becoming OpenTelemetry.
I don't know if the Get Started section is supposed to have links, but I want to click on some of those subjects but don't have the patience to look elsewhere for the content.
FYI for all, the W3C TraceContext specification will become a Proposed Recommendation later this week. I'm one of the co-chairs of the group and am happy to answer questions about our W3C work or OpenTelemetry.
Just curious, what was the rationale for randomizing the spanId at each hop? (As opposed to a more structured format that could let you track the request tree without relying on another field like timestamp)
Existing tracing systems (Dapper, Zipkin, Dynatrace, Stackdriver, etc.) already randomize with each hop, and there was a desire to be consistent with the models that they already used. It's also more straightforward to implement.
There's a discussion about "correlation context" inside of this W3C group called , which maps to what you're describing. It'd be worth reaching out to Sergey (one of the other co-chairs) if you want to find out more.
Timestamps across distributed systems don't work well as correlation tools as time tends not to be accurate enough to order application retries particularly but also fan out type requests. You really want parent / child or follows from relationships to collect and represent the graph correctly.
Source: Working on distributed tracing at Twilio and Stitch Fix
W3C Trace Context defines an HTTP header format for traced requests, and OpenTelemetry implements this format by default. While this project is technically distinct from OpenTelemetry, it's effectively composed of the same people (including me).
Actually, OpenTelemetry is compatible with OpenTracing, so the boom is still relevant. The distributed tracing APIs are very similar, but OpenTelemtry also includes metrics.
They’re trying—and I am rooting for them—but from the outside it seems piecemeal and scattered, like a side project that is nobody’s real priority. Meanwhile, other initiatives have so much movement as to be unfollowable: Zipkin! No, Jaeger! No, OpenTracing! No, OpenCensus! No, OpenTelemetry!
I am beginning to doubt that we will ever have a standard for distributed tracing.