specification

I don't believe this is a solved problem, and it's been around since OpenTracing days[0]. I do not think that the Span links, as they are currently defined, would be the best place to do this, but maybe Span links are extended to support this in the future. Right now Span links are mostly used to correlate spans causally _across different traces_ whereas as you point out there are cases where you want correlation _within a trace_. [0]: https://github.com/opentracing/specification/issues/142

"OpenTracing-compatible" is strict API compatibility in any supported language. The cross-language spec is "terminology-based" since it's, well, cross-language. There is an open issue about Envoy/linkerd/Istio support here: https://github.com/opentracing/specification/issues/86 (as well as in a number of other locations) As an OpenTracing contributor, the core value prop still seems quite strong in that instrumentation of OSS dependencies is a massive pain point and should not be tracing-system-specific since it doesn't need to be. There is also value in common protocols and formats, and in that spirit there is interest in broadening scope to include those... though from seeing many companies adopt tracing tech, I haven't observed protocol compatibility as the main pain point or blocker.

It's weird for most people. We're used to cross-language wire protocols. OpenTracing is different. An analogy is SLF4J for Java logging. All libraries, etc use the same interface and the final user determines the backend: java.util, Logback. This makes sense if you have many authors of libraries with a cross-cutting concern. This really makes OpenTracing half a dozen different standards, one per language, with common semantics. Should it be about a wire protocol instead? Discussion at https://github.com/opentracing/specification/issues/34

Mm it's a little sparse right now - had to dig into the opentracing spec, dig in to the implementations and make it piecemeal. OpenTracing is for everyone - both tracing implementors (eg. Jaeger engineers) and for you implementing tracing in your system. As an implementor in your system you mainly care about the "vocabulary" and "standards" opentracing defines. So, if you've got two functions (A which calls B) opentracing defines: - Syntaxes to say that the span for "B" is a "childOf" "A". This gives you the graph I had above. - Syntaxes to attach errors and other information to spans in a standard way (this lets any opentracing-compatible UI display/search errors etc): https://github.com/opentracing/specification/blob/master/sem... OpenTracing also allows you to define functions that follow each other: https://github.com/opentracing/