javajumbo

Another Jaeger maintainer here. I would agree, Isaac's statement is not accurate. It's also not very relevant for comparison. Canopy is an internal, close source tracing system, so comparing its instrumentation API with OpenTracing is besides the point. Feature-wise, it's a much more mature project than Jaeger (older too). Just a few features off the top of my head that Canopy has over Jaeger: reverse context propagation for deferred sampling, user-controlled DSL that can be pushed through configuration to the edge to do selective sampling, advanced and user-customizable feature extraction data pipeline, UI that combines different visualizations for frontend and backend performance.

Yes, Jaeger is used in production at Uber and many other companies. Our original blog post on the history of Jaeger: https://eng.uber.com/distributed-tracing/

@necubi I do not disagree with you about the value of tail-based sampling. It has been an item on Jaeger roadmap from day one, but never of high enough priority to implement it. We're planning to do a POC by the end of this year. Jaeger's agent-based architecture was specifically designed to support that use case. If you're interested in collaborating on that, it would be great (https://github.com/uber/jaeger/issues/425).

Having said that, Dapper-style tracing systems with head-based sampling still provide enormous benefits that are often underestimated. In fact, even if we support tail-based sampling in the future, we're still going to run a certain portion of the traffic through probabilistic, head-based sampling, because it allows to reason about statistical patterns observed in the systems at large scale.

There is a section in the CNCF proposal:

https://github.com/cncf/toc/blob/master/proposals/jaeger.ado...