# 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
Brave's SpanHandler can report natively in other formats which have different
constraints than Zipkin and often extensions to the data model.
This change ports all tests away from Zipkin's types so that it is more clear
what's actually recorded vs what's a side-effect of Zipkin conversion.
This removes `BlockingQueueSpanReporter` which was never released, also.
with the current setup we're using the MDC's default interpolation as a default for spring var resolution (which makes no sense)
with this change we're removing the dashes
fixes gh-1396
This does two things: ensures samples don't use Zipkin v1 in any way,
and misaligns the version numbers of zipkin v1 and zipkin v2 apis.
This is an attempt to walk around the gradle plugin issue, which only
exists when someone is using both versions of zipkin.
See https://github.com/spring-projects/spring-boot/issues/10778
