5 ms·

Most folks will choose either Zipkin or Jaeger, but both are OpenTracing-compatible distributed tracing systems. You might find the Cloud Native Landscape usefu

Most folks will choose either Zipkin or Jaeger, but both are OpenTracing-compatible distributed tracing systems. You might find the Cloud Native Landscape useful for thinking about the options: https://github.com/cncf/landscape/blob/master/README.md https://github.com/cncf/landscape/blob/master/README.md Disclosure: I’m the executive director of CNCF, which just adopted Jaeger 2 weeks ago, and I’m an author of the landscape.

muninn_ 9y ago
I have used that landscape document as a very informative point of reference for the last couple of months. Thank you for creating it.
- dankohn1 9y ago
  You're very welcome. You cannot imagine the amount of criticism it has engendered.
  - dastbe 9y ago
    How do you plan on keeping it sane over time? Even disregarding paring down the number of times managed major providers appear on the list (which is super sensible imo), won't it start to get quite crowded with all the open source competitors appearing?
    - dankohn1 9y ago
      The guidelines we're following are at: https://github.com/cncf/landscape#cloud-native-landscape-project https://github.com/cncf/landscape#cloud-native-landscape-pro... The CNCF storage WG is also looking at creating a "zoomed in" version of the storage section with higher fidelity information. That's one model of providing more detail. We also have an interactive version of the landscape coming that will provide filtering, zooming, etc.
yoshuaw 9y ago
Last I checked "OpenTracing-compatible" only went as far as using common terminology. Tbh I was a bit disappointed by this; has more been defined since? E.g. are there now shared schemas, APIs of sorts?
- dankohn1 9y ago
  Yes, OpenTracing is an API, with bindings currently available in 9 languages. Please take a look. http://opentracing.io/ http://opentracing.io/
  - AYBABTME 9y ago
    Only the semantics and libraries implementing them are there. The wire format is not specified, which is a pretty annoying problem to deal with.
    - jpkrohling_jpk 9y ago
      There are discussions about it happening. If you haven't yet, join the community and make your opinion heard :)
    - paulddraper 9y ago
      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 https://github.com/opentracing/specification/issues/34
- el_bhs 9y ago
  "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 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.

muninn_ 9y ago

I have used that landscape document as a very informative point of reference for the last couple of months. Thank you for creating it.

dankohn1 9y ago
You're very welcome. You cannot imagine the amount of criticism it has engendered.
- dastbe 9y ago
  How do you plan on keeping it sane over time? Even disregarding paring down the number of times managed major providers appear on the list (which is super sensible imo), won't it start to get quite crowded with all the open source competitors appearing?
  - dankohn1 9y ago
    The guidelines we're following are at: https://github.com/cncf/landscape#cloud-native-landscape-project https://github.com/cncf/landscape#cloud-native-landscape-pro... The CNCF storage WG is also looking at creating a "zoomed in" version of the storage section with higher fidelity information. That's one model of providing more detail. We also have an interactive version of the landscape coming that will provide filtering, zooming, etc.

yoshuaw 9y ago

Last I checked "OpenTracing-compatible" only went as far as using common terminology. Tbh I was a bit disappointed by this; has more been defined since? E.g. are there now shared schemas, APIs of sorts?

dankohn1 9y ago
Yes, OpenTracing is an API, with bindings currently available in 9 languages. Please take a look. http://opentracing.io/ http://opentracing.io/
- AYBABTME 9y ago
  Only the semantics and libraries implementing them are there. The wire format is not specified, which is a pretty annoying problem to deal with.
  - jpkrohling_jpk 9y ago
    There are discussions about it happening. If you haven't yet, join the community and make your opinion heard :)
  - paulddraper 9y ago
    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 https://github.com/opentracing/specification/issues/34
el_bhs 9y ago
"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 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.