Problem Statement

Spring Boot 4's spring-boot-starter-opentelemetry supports OTEL_RESOURCE_ATTRIBUTES (general configuration) but doesn't support standard OTLP exporter environment variables defined in the OpenTelemetry specification:

• OTEL_EXPORTER_OTLP_ENDPOINT
• OTEL_EXPORTER_OTLP_PROTOCOL
• Signal-specific variants (OTEL_EXPORTER_OTLP_{LOGS|TRACES|METRICS}_*)

Business Impact

Our organization is standardizing on OpenTelemetry with these environment variables for all applications. This works seamlessly with the OpenTelemetry Java Agent but requires custom adaptation for spring-boot-starter-opentelemetry.

Migration challenge: Applications must choose between:

1. Using the OpenTelemetry agent (standard variables work)
2. Using Spring Boot SDK starter (requires Spring-specific properties)

This creates friction for teams wanting to migrate from agent to SDK-based instrumentation.

Current Workaround

We implemented an EnvironmentPostProcessor that maps OTEL standard variables to Spring Boot properties (see OtelExporterPropertiesEnvironmentPostProcessor.java). Thomas Vitale has a similar and more exhaustive implementation in Arconia, suggesting this is a common need.

Our implementation handles:

• Endpoint mapping with signal-specific precedence
• Protocol auto-detection from port (4318=HTTP, 4317=gRPC)
• HTTP-specific path appending (/v1/{signal})
• Metrics HTTP-only limitation with automatic fallback
• Compression value mapping

Questions

1. Is there a deliberate decision not to support these standard variables?
2. Is this on the roadmap for a future release?
3. Would a pull request implementing this feature be welcome?

Benefits

• Standards compliance: Align with OpenTelemetry specification
• Easier migration: Seamless transition from agent to SDK
• Configuration portability: Same variables across languages/frameworks
• Reduced complexity: No need for organization-specific adapters

I'm happy to contribute a PR if this aligns with Spring Boot's direction.