feat: Add OpenTelemetry migration recipes for Spring Boot applications

[sandy2008]

What's changed?

Add comprehensive OpenTelemetry migration recipes to help Spring Boot applications migrate from legacy tracing solutions to OpenTelemetry.

New YAML Recipes (opentelemetry.yml):

• AddOpenTelemetryAutoInstrumentation - Add OpenTelemetry auto-instrumentation with opentelemetry-spring-boot-starter
• MigrateToOpenTelemetryFromSleuth - Migrate from Spring Cloud Sleuth to OpenTelemetry
• MigrateBraveToOpenTelemetry, MigrateFromZipkinToOpenTelemetry - Migrate from Brave/Zipkin
• ConfigureOpenTelemetryForSpringBoot - Configure OTLP exporter and service name
• OpenTelemetryCompleteMigration - Complete end-to-end migration recipe
• MigrateSleuthToMicrometerTracing - Migrate Spring Cloud Sleuth API types to Micrometer Tracing
• MigrateSleuthAnnotationsToOpenTelemetry - Migrate @NewSpan, @SpanTag, @ContinueSpan to @WithSpan, @SpanAttribute
• MigrateOpenTracingToOpenTelemetry - Migrate OpenTracing API to OpenTelemetry API
• MigrateDatadogToOpenTelemetry - Migrate Datadog tracing API and @Trace annotation to OpenTelemetry

What's your motivation?

OpenTelemetry has become the industry standard for observability. Spring Cloud Sleuth is deprecated in favor of Micrometer Tracing, and many organizations are migrating from vendor-specific solutions (Datadog, Zipkin, Brave) to OpenTelemetry for vendor-neutral observability.

These recipes automate the migration process, handling:

• Dependency management (BOM, starter dependencies)
• API type changes (Tracer, Span, SpanContext, Scope)
• Annotation migrations (@Newspan → @WithSpan, @trace → @WithSpan)
• Property configuration for OTLP exporters

Anything in particular you'd like reviewers to focus on?

• The OpenTelemetry version used is 2.23.0 (latest as of January 2026) with SDK 1.57.0
• The recipes follow the official OpenTelemetry Spring Boot documentation
• Using opentelemetry-spring-boot-starter for zero-code auto-instrumentation approach

Have you considered any alternatives or workarounds?

• Considered using classpathFromResources for tests but used dependsOn with stub types for better test isolation
• The YAML recipes delegate to existing OpenRewrite recipes (AddDependency, ChangeType, ChangeSpringPropertyKey) for maintainability

Any additional context

Uses OpenTelemetry Java Instrumentation 2.23.0 which includes:

• Auto-instrumentation for Spring Web, WebFlux, JDBC, Kafka, etc.
• OTLP exporter for traces, metrics, and logs
• Support for @WithSpan and @SpanAttribute annotations

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've used the IntelliJ IDEA auto-formatter on affected files

[timtebeek]

Great to see @sandy2008 ! I'll try to get a proper review & merge in before the release tomorrow.

[timtebeek]

Should this recipe be included in any larger composite such as a particular Spring Boot version migration? I'm not sure at which point it might have become a required migration.

[sandy2008]

Thank you! I added This is an optional migration for users who want to adopt OpenTelemetry as their observability solution. It is not included in standard Spring Boot version migrations because those use Micrometer Tracing (which can work with either Brave or OpenTelemetry as a backend). Use this recipe if you want to fully embrace OpenTelemetry's native instrumentation and exporters.

Since Sleuth → Micrometer Tracing + Brave is already in UpgradeSpringBoot_3_0, is it better to make it optional..?

[timtebeek]

I had a couple quick questions pop up during the initial reading; would be good to get clarity on those before we continue.

[sandy2008]

I had a couple quick questions pop up during the initial reading; would be good to get clarity on those before we continue.

@timtebeek Thank you for reviewing.. fixed those mistakes!

[sandy2008]

@timtebeek Hi! I replaced w/ yml recipes & tested.