Plan to support OpenTracing ?

[cmoulliard]

Spring cloud sleuth actively relies on Zipkin Distributed Tracing project. is there any plan to support also the OpenTracing initiative and by example Uber Jaeger project

http://opentracing.io/
https://github.com/opentracing/opentracing-java
https://github.com/opentracing-contrib/java-spring-web

[devinsba]

What do you mean by support OpenTracing? If you mean making a sleuth io.opentracing.Tracer then I have a project I've already started to that end that I plan to contribute to the opentracing-contrib organization

https://github.com/DealerDotCom/sleuth-opentracing

[cmoulliard]

contribute to the opentracing-contrib organization

Excellent news. I will have a look. Thanks

[d-sauer]

How about https://github.com/opentracing-contrib/java-spring-web ?
Is there some main difference between that one and sleuth-opentracing?

[codefromthecrypt]

java-spring-web is one of the opentracing contrib instrumentation projects. It reproduces a small part of what other libraries do, including sleuth. Brian's project allows you to reuse sleuth with a non-zipkin system. Since sleuth is much more widely used, if the goal is to use a system that isnt OpenZipkin compatible, Brian's library gets you more. Which system are you trying to support?

…

On 4 Jun 2017 19:26, "Davor Sauer" ***@***.***> wrote: How about https://github.com/opentracing-contrib/java-spring-web ? Is there some main difference between that one and sleuth-opentracing? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#599 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD612l_Tsd5N8dg3Zs8yUqxvjo8SzX1ks5sApR9gaJpZM4NqqFD> .

[marcingrzejszczak]

Sorry for the delay in answering the question. Currently adding support for OpenTracing is not on top of our list of priorities. We want to focus more on use cases that the community needs.

[d-sauer]

Actually I appreciate that detailed answer.
I was looking which direction to choose, but if there is any indication to support OpenTracing in the future of Sleuth, then I would rather go with Sleuth.

[codefromthecrypt]

by supporting OpenTracing, you mean make it a core dependency and throw out sleuth's api, right? Considering how often OpenTracing's java api breaks compatibility, and the lack of end-user interest, probably not the right time.

[codefromthecrypt]

PS I've been noticing conflation of OpenTracing and Jaeger when you follow threads to where they lead. Jaeger for example, accepts zipkin data albeit through an awkward endpoint like https://jaeger-http-collector.mydomain.xxx/api/traces?format=zipkin.thrift. This is a much smaller scope request. Moreover allowing users to see OpenTracing apis is different than forcing sleuth to use them. When folks ask for OpenTracing, please be specific what you are asking for? Ex whether your aim is to force sleuth to use OpenTracing api v0.30 under the covers, whether you want to be able to use OpenTracing apis (and for what?), or if you are just trying to send data to jaeger or lightstep.

[pavolloffay]

It's also important to mention that this is not only about sending data to different systems but also sampling and other implementation differences.

[codefromthecrypt]

@pavolloffay so currently sleuth supports different trace context formats using SpanInjector and SpanExtractor. It also supports read-back of baggage.

OpenTracing defines no sampling api, so we can't interact there. There is a sampling priority flag which sometimes is interpreted as a notification of sampling decision and sometimes as a command to sample. It is very confusing... not sure if you are looking for something jaeger-specific or opentracing with regards to sampling. If jaeger-specific, maybe add to a jaeger-specific issue unless we can always assume jaeger==opentracing?

I'd ask, especially as you have many people working on jaeger, to implement sleuth support using the existing hooks in your org. That way, maintenance stays there especially while both jaeger and opentracing are not stable apis.

[marcingrzejszczak]

I'm closing this issue for now due to reasons that @adriancole has mentioned

[pavolloffay]

For people who would like to use OpenTracing with spring cloud https://github.com/opentracing-contrib/java-spring-cloud

[sudr]

Apologies for posting this question on a closed thread since I am not sure where else I could post it. I wanted to check whether the Spring Cloud Sleuth tracing output can be consumed by any monitoring application that can understand OpenTracing tracing payloads.

Reason this isn't clear to me is I see the following blurb on the Spring Cloud Sleuth documentation page: "....Spring Cloud Sleuth is OpenTracing compatible.....". But nowhere in the documentation for the Brave tracer (which I understand in used by Spring Cloud Sleuth) does it state that it generates traces in the OpenTracing format. Instead Brave seams to be purpose built for Zipkin.

[spencergibb]

You're right, questions should go on https://gitter.im/spring-cloud/spring-cloud-sleuth or stack overflow.

[codefromthecrypt]

opentracing has no data format so there is nothing for us to be incomparable with. opentracing defines interfaces for tracers we support one implementation of that and by doing so allow you to use opentracing instrumentation. I personally fix or facilitate fixes for brave-opentracing we do not support switching the tracer itself, instead you can use zipkin-reporter to export data to other systems including stackdriver, xray, etc. in a way similar to the opencensus project which supports multiple backends the same way. Also there are numerous zipkin proxies etc. if you need another backend ask your vendor to implement a zipkin reporter interface. numerous vendors have even if not in open source. if you are not interested in asking them you could write it on your own. there are no plans to change this approach. notably there is also demand for census. the exact same concern is here for both and meanwhile we support a lot of different systems today.