# Modules
* New modules: `spring-cloud-sleuth-autoconfigure`, `spring-cloud-sleuth-api`, `spring-cloud-sleuth-instrumentation`
`spring-cloud-sleuth-core` removed and changed to `spring-cloud-sleuth-instrumentation` & `spring-cloud-sleuth-api`
* Removed `spring-cloud-starter-sleuth-otel`
To add OpenTelemetry support you need to add `spring-cloud-starter-sleuth` (adds Brave by default), exclude Brave and add `spring-cloud-sleuth-otel` dependency
* Except for the tests, `spring-cloud-sleuth-autoconfigure` is the only module that can have access to `@Configuration`, `@ConfigurationProperties` classes.
Tests have been added to ensure such separation.
## Package moving
* `org.springframework.cloud.sleuth.api` -> `org.springframework.cloud.sleuth`
* `org.springframework.cloud.sleuth.brave.autoconfig` -> `org.springframework.cloud.sleuth.autoconfig.brave`
* `org.springframework.cloud.sleuth.otel.autoconfig` -> `org.springframework.cloud.sleuth.autoconfig.otel`
* `org.springframework.cloud.sleuth` -> `org.springframework.cloud.sleuth`
* Instrumentation: `org.springframework.cloud.sleuth.annotation` -> `org.springframework.cloud.sleuth.instrument.annotation`
* All the autoconfiguration classes were moved under `org.springframework.cloud/sleuth.autoconfig` package
## Global class modifications
* Any class registered as a bean is now public
## Classes
* `RateLimitingSampler` constructor changed
* Merged a lot of auto configuration classes into one (e.g. `BraveAutoConfiguration` now imports various other configurations)
* Renamed `TraceBraveAutoConfiguration` to `BraveAutoConfiguration`
* Renamed `TraceOtelAutoConfiguration` to `OtelAutoConfiguration`
* Removed all `NoOp` implementations of the API
Spring Cloud Sleuth currently is an autoconfiguration over Brave. It also consists of various instrumentation mechanisms for libraries that are not supported by Brave (e.g. Spring Cloud Circuitbreaker).
We would like to abstract Brave so that Spring Cloud Sleuth becomes an autoconfiguration for any tracer implementation that is compatible with Spring Cloud Sleuth. That way Spring Cloud Sleuth in its core module would consist of an API and various tracer implementations would implement that API which would also allow automatic instrumentation of libraries that are supported by Spring Cloud Sleuth.
## OpenTelemetry Support
Thanks to doing this abstraction we are able to support new tracer implementations, not only Brave. We've decided to add support for the OpenTelemetry SDK as the second one. If in the future if we decide to add new tracers then it will be just a matter of adding a new module that bridges to the Spring Cloud Sleuth one. Thanks to abstraction of tests as well we will be easily able to plug that tracer mechanism into our current suite of tests.
- adds Spring Cloud Function instrumentation
- adds Operators to manually provide instrumentation for Fluxes
- introduces Manual instrumentation mode for Reactor
TODO: Documentation (will add it soon)
related gh-1684
Previously, sleuth logged more data than necessary. This led to issues
including spans approaching megabytes each. This pares down default keys
to a minimal set, but allows users to opt-into logging more by extending
`TraceFilter`.
- Changed Random instantiation to a shared Random
- Changed the name of the converter
- Changed generator into random
- Span id is now non-nullable.
- it gets generated in the http filter if it's not there
- it's generated in the spring-integration channels if it wasn't set
Instrumentation should be able to get by with only 2
interfaces: TraceManager and TraceAccessor (the former is
not needed if you aren't starting a new Span). No explicit
access to thread locals or manipulation of thread context
is required (except locally where necessary).
A Span is enclosed by a Trace (actually a view of the complete
Trace that would be constructed remotely).
