Hey there, let's dig into this issue you're facing with Spring Boot 4.0.1 and OpenTelemetry. I've run into similar quirks when migrating from Micrometer Tracing to the native OpenTelemetry support, so let's break down why this is happening and how to fix it step by step.

Why You're Still Seeing Connection Attempts #

Even after excluding dependencies and setting properties, there are a few common culprits here:

• Incomplete Dependency Exclusions: OTLP splits exporters into granular modules for traces, metrics, and logs (like opentelemetry-exporter-otlp-trace under the parent opentelemetry-exporter-otlp). Your current exclusions might be missing these specific variants.
• Wrong Configuration Properties: The management.tracing.export.otlp.enabled=false property targets Micrometer Tracing's OTLP bridge, not Spring Boot 4.0's native OpenTelemetry support. You're using the wrong namespace for OpenTelemetry-specific settings.
• Lingering Auto-Configuration: Spring Boot's OpenTelemetry auto-config might still try to create export-related beans even if dependencies are excluded, especially if the SDK auto-extension is still present.

Step-by-Step Fixes #

1. Lock Down Dependency Exclusions #

First, let's make sure we exclude all OTLP exporter variants and the SDK auto-config extension that might trigger default export behavior. Update your build.gradle.kts like this:

dependencies {
    // Monitoring, tracing, and logging
    implementation("org.springframework.boot:spring-boot-starter-actuator")
    implementation("org.springframework.boot:spring-boot-starter-opentelemetry") {
        // Exclude ALL OTLP exporter variants
        exclude(group = "io.opentelemetry", module = "opentelemetry-exporter-otlp")
        exclude(group = "io.opentelemetry", module = "opentelemetry-exporter-otlp-trace")
        exclude(group = "io.opentelemetry", module = "opentelemetry-exporter-otlp-metrics")
        exclude(group = "io.opentelemetry", module = "opentelemetry-exporter-otlp-logs")
        exclude(group = "io.opentelemetry", module = "opentelemetry-exporter-otlp-common")
        exclude(group = "io.opentelemetry.instrumentation", module = "opentelemetry-exporter-otlp")
        // Exclude SDK auto-config that enforces default export logic
        exclude(group = "io.opentelemetry", module = "opentelemetry-sdk-extension-autoconfigure")
    }
    implementation("io.micrometer:micrometer-observation")
}

// Global exclusion to catch any stray OTLP dependencies
configurations.all {
    exclude(group = "io.opentelemetry", module = "opentelemetry-exporter-otlp")
    exclude(group = "io.opentelemetry", module = "opentelemetry-exporter-otlp-trace")
    exclude(group = "io.opentelemetry", module = "opentelemetry-exporter-otlp-metrics")
    exclude(group = "io.opentelemetry", module = "opentelemetry-exporter-otlp-logs")
    exclude(group = "io.opentelemetry", module = "opentelemetry-sdk-extension-autoconfigure")
}

2. Fix Your Configuration Properties #

Swap out the old Micrometer-focused properties for native OpenTelemetry settings. Your application.properties should look like this:

# Enable OpenTelemetry internal tracing
management.opentelemetry.tracing.enabled=true
# Disable ALL OpenTelemetry exports (traces + metrics)
management.opentelemetry.trace.export.enabled=false
management.opentelemetry.metrics.export.enabled=false
# Optional: Set 100% sampling to ensure all traces are captured internally
management.opentelemetry.trace.sampling.probability=1.0

3. Force a No-Op Exporter (Fallback) #

If the above steps still don't stop connection attempts, explicitly override the span exporter with a no-op implementation to guarantee no export logic runs. Create this config class:

import io.opentelemetry.sdk.trace.export.SpanExporter
import io.opentelemetry.sdk.trace.export.NoopSpanExporter
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration

@Configuration
class OpenTelemetryInternalConfig {

    @Bean
    fun spanExporter(): SpanExporter {
        // This ensures no traces are ever exported
        return NoopSpanExporter.getInstance()
    }
}

4. Disable Troublesome Auto-Configuration Classes #

If all else fails, directly exclude the auto-config classes that handle OTLP export. Add this to your application.properties:

spring.autoconfigure.exclude=org.springframework.boot.actuate.autoconfigure.tracing.opentelemetry.OpenTelemetryTraceExportAutoConfiguration,
org.springframework.boot.actuate.autoconfigure.metrics.export.otlp.OtlpMetricsExportAutoConfiguration

Answers to Your Exact Questions #

1. Why is OpenTelemetry still trying to connect to a collector? #

Most likely a combination of:

• Missing exclusions for granular OTLP trace/metrics exporters that are still on your classpath
• Using the wrong property namespace (Micrometer vs. native OpenTelemetry) to disable exports
• Residual SDK auto-config logic that's trying to set up default export behavior

2. What's the correct way to use OpenTelemetry for internal-only tracing in Spring Boot 4.0.1? #

Stick to this workflow:

1. Exclude all OTLP exporter and SDK auto-config dependencies completely
2. Use native OpenTelemetry properties to disable exports and enable internal tracing
3. Optionally, explicitly define no-op exporters to eliminate any accidental export logic
4. Keep micrometer-observation to tie OpenTelemetry into Spring's observation framework

3. Are there additional autoconfiguration properties I need to disable? #

Yes, if you're still seeing issues, exclude the export-focused auto-config classes mentioned in step 4. You can also double-check if any third-party instrumentation dependencies are bringing in OTLP bits, but the global configuration exclusion should catch most of those.

Let me know if you hit any snags after trying these steps – it's easy to miss a tiny dependency or config nuance when switching tracing frameworks!