Spring Cloud Sleuth 3.0.0 released
With the release of the Spring Cloud 2020.0.0 (aka Ilford) release train we’re more than happy to announce the general availability of Spring Cloud Sleuth 3.0.0. In this blog post I’ll describe the most notable released features (in order of their release dates).
Removes Deprecated Modules
Removes ribbon, zuul, hystrix and Spring Cloud Aws support. Check this PR for more information.
Removes Zipkin Dependencies from Core
Zipkin is no longer a part of core of Sleuth. You can check out more in this PR.
Added MANUAL Reactor Instrumentation
Up till now we’ve been supporting ON_EACH
and ON_LAST
Reactor instrumentation modes. That means that we would wrap every single Reactor operator (ON_EACH
) or the last operator (ON_LAST
). Those wrappings would do their best to put trace related entries in such a way that thread local based instrumentations would work out of the box (e.g. the MDC context, Tracer.currentSpan()
etc.). The problem was that on each wrapping downgraded performance drastically and worked most of the time. The on last operator wrapping downgraded performance a lot and worked sometimes. Both had their issues when flatMap
operators were called and thread switching took place.
With this commit we’ve introduced the manual way of instrumenting Reactor. We came to the conclusion that the thread local based paradigm doesn’t work well with Reactor. We can’t guess for the user what they really want to achieve and which operators should be wrapped. That’s why with the MANUAL
instrumentation mode you can use the WebFluxSleuthOperators
or MessagingSleuthOperators
to provide a lambda that should have the tracing context set in thread local.
MANUAL Reactor Instrumentation Default in Spring Cloud Gateway
With this issue we’re setting the manual instrumentation as the default one for Spring Cloud Gateway. The performance gets drastically improved and the tracing context still gets automatically propagated. If you need to do some customized logging etc. just use the WebFluxSleuthOperators
.
Remove The Legacy MDC Entries
This issue introduces a change in the MDC keys (no more X-B3-...
entries in MDC).
Before
2019-06-27 19:36:11,774 INFO {X-B3-SpanId=e30b6a75bcff782b, X-B3-TraceId=e30b6a75bcff782b, X-Span-Export=false, spanExportable=false, spanId=e30b6a75bcff782b, traceId=e30b6a75bcff782b} some log!
After
2019-06-27 19:36:11,774 INFO {spanId=e30b6a75bcff782b, traceId=e30b6a75bcff782b} some log!
Code Refactoring
Removing Zipkin Starter
The spring-cloud-starter-zipkin
dependency is removed. You need to add spring-cloud-starter-sleuth
and the spring-cloud-sleuth-zipkin
dependency.
New Tracer Abstraction
OpenZipkin Brave was there in Sleuth’s code as the main abstraction since Sleuth 2.0.0. We’ve decided that with Sleuth 3.0.0 we can create our own abstraction (as we do in each Spring Cloud project) so that OpenZipkin Brave becomes one of the supported tracer implementations.
With this PR we’ve introduced a new abstraction that wraps Brave. We also added support for another tracer - OpenTelemetry.
Aligning with Spring Boot
With this PR and that PR we’ve refactored Spring Cloud Sleuth to reflect Spring Boot’s module setup. We’ve split the project into API, instrumentations, auto-configurations etc. Also the documentation layout was updated to look in the same way the Spring Boot one does.
OpenTelemetry support
Initially, with this commit, we’ve added a spring-cloud-sleuth-otel
module inside Spring Cloud Sleuth that introduced OpenTelemetry support.
With this PR we’ve decided to move Spring Cloud Sleuth and OpenTelemetry integration to an incubator project. Once OpenTelemetry & OpenTelemetry Instrumentation projects become stable we will consider next steps.
Links
- Spring Cloud Sleuth 3.0.0 docs
- Spring Cloud Sleuth OpenTelemetry project
- Spring Cloud Sleuth OpenTelemetry docs
- Spring Cloud Sleuth 3.0.0 release notes
- Spring Cloud Sleuth 3.0.0 migration guide
Stay in touch!
In case of any questions don’t hesitate to ping us
- On Github
- On Gitter
- On Stackoverflow