Spring-cloud-sleuth: Does Spring Cloud has a plan to support CNCF OpenTelemetry at future?

[HaojunRen]

OpenTelemetry will be produced by CNCF, Google and MicroSoft, it will integrate Opentracing & OpenCensus to support tracing, metrics and log.So any plan? Thanks a lot

[andreasschmid-genopace]

The Spring Framework has a LONG history of supporting common standards vs own implementations. OpenTelemetry (https://opentelemetry.io/) is not only an API, but also a proper implementation. For me, the Spring way to go would be to provide an ADAPTER to OpenTelemetry.

@marcingrzejszczak Marcin added the _discussion_ tag some months ago, but I don't see any discussion here yet.

What do you think?

[codefromthecrypt]

this is a beta library, designed by several people. I'm not sure the "common standards" is warranted here, quite yet.

[codefromthecrypt]

For example, it is only less than a month ago that 0.3 was released, which the group decided to call Beta. https://github.com/open-telemetry/opentelemetry-java/tree/v0.3.0

Similar to other discussions, brand words are secondary to stability when considering A. if something is standard or not and B. if it is stable enough to consider thrashing existing users over.

[codefromthecrypt]

I'd like to also fix the description as there are some things not obvious about this.

• OpenTelemetry integrates with the canceled OpenTracing project via a bridge
  
  
  
  • We have a bridge to OpenTracing for years
  
  
• OpenTelemetry does not integrate with OpenCensus and will not
  
  
  
  • See https://github.com/open-telemetry/opentelemetry-java/pull/341
  
  

More importantly, OpenTelemetry is trying to reinvent many wheels, not just Tracing. This repository only scopes tracing and correlation

• Ex they have an evolving metrics api (with far less backends than micrometer)
• Ex they want to make their own logging model and apis

Let's consider that there are years of features in the current libraries not possible in the 0.3 apis. What are some potential outcomes?

Well, it is possible that if the tracing apis stabilize, Brave can forward data into them which would allow the years of code end users have written to continue to work. This would be the same way we handle OpenTracing today.

Data formats are not a concern at the moment, as Otel not only supports B3 headers, but (soon) will support Zipkin data anyway. There is talk about w3c trace-context and that is already in scope for Sleuth 3.0, though there are issues in the spec which remain unaddressed and prevent portable implementations.

At the point that OTel ends up with stable formats, a decoupled feature could be written to do that in the same way we have decoupled features to report data into Google and Amazon cloud formats. Even without that, they have a project aiming to convert into their format https://github.com/open-telemetry/opentelemetry-collector

Regardless of any of these potential outcomes, it is certainly the case that Sleuth 3.0 will not make a hard dependency on any 0.3 versioned library. Sleuth has no scope to change the underlying logging infrastructure used by apps for the last decades (log4j sl4fj etc). It also has neither value to gain from, nor scope to try to swap out well designed and used metrics libraries for a 0.3 alternative.

[codefromthecrypt]

It is probably less intuitive how much damage is caused by unstable apis. Even though OpenTracing support is optional, there is rev lock caused by it. Sleuth 2.1.x is pinned and we can't change it to the more recent OpenTracing libraries because people in 2.1 got locked into the older versions.

The summary is we know this path, we've been down it before, and it hurt.

This is compounded by a focus of instrumentation work done with java agents. This sort of integration can hide problems that hurt dependency injection, such as reliance on static initialization of things like tracers.

https://github.com/open-telemetry/opentelemetry-auto-instr-java

My advice is to let this group stabilize their code. When the thrashing dies down a bit, consider it again. Consider more than the version number, what precise value is being brought. It may be that folks are taking a lot of features present here for granted!

I suspect it will be at least the end of the year before even the tracing aspect of Otel will be near 1.0, if then. It would certainly be fair to re-assess towards the year end.

Hope this helps.

[spencergibb]

We can reopen when it is more stable

[andreasschmid-genopace]

Kudos to you @adriancole @spencergibb for the fast, exhaustive and in-depth discussion!
Yes, this makes sense.

[marcingrzejszczak]

Done via https://github.com/spring-cloud/spring-cloud-sleuth/commit/6e306e594d20361483fd19739e0f5f8e82354bf5

[sardorn]

@adriancole and @spencergibb Can we revisit this topic? Otel spec for tracing is close to GA, as well as .NET library. There is also serious support from cloud community (eg. AWS distro of OpenTelemetry). Would be good to revisit and discuss potential support for openTelemetry.

[spencergibb]

We have plans. The project is in incubator until it goes GA. We're in regular meetings with their team. https://github.com/spring-cloud-incubator/spring-cloud-sleuth-otel