Add support for OpenTelemetry SDK environment variables

[fabienbuss]

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.

[mhalbritter]

Flagging this to talk to the team if this makes sense. Pro: Compliance with the OTel SDK, Cons: a different way of configuring Spring Boot applications.

[wilkinsona]

There's also #47646 in a similar area.

[bclozel]

We have discussed this and we would like to try and support those properties at the system environment level only.

[adathouse]

Reiterating my comment in #49304 , I would love to see this. We run services in multiple frameworks - primarily ASP.NET, some Spring Boot, bits of Python - so having consistent configuration and behavior across these platforms is big benefit. Our environment all goes into a Kubernetes config map, so if we can do this with one entry versus five that simplifies our deployments and reduces our options for errors.

[jisub-dev]

Hi! I'd like to contribute a PR for this feature if it's still available.

I have an implementation ready using EnvironmentPostProcessor that maps the standard OTLP
environment variables to Spring Boot properties as discussed. It includes tests and
follows the existing patterns in the codebase.

Happy to close the PR if the team is already working on this. @mhalbritter

[mhalbritter]

Hey @jisub-dev ,thanks for the offer, but I'm currently working on it already. However, you can open the PR and if that fits the work I already did, I can incorporate your changes (and attribute you on the commit, of course). Thanks!