Support for OpenTelemetry resource detectors

Context

Spring Boot today builds OpenTelemetry resource attributes only from static sources:

• OTEL_RESOURCE_ATTRIBUTES / OTEL_SERVICE_NAME environment variables
• management.opentelemetry.resource-attributes.* properties
• spring.application.* defaults

There is no extension point for detecting resource information from the runtime environment like host name, OS, process ID, container metadata, cloud provider, etc. — which the OpenTelemetry spec calls resource detectors..

Use case

The motivating use case is Micrometer's OTLP metrics export. Resource attributes are currently built independently at two call sites:

1. OpenTelemetrySdkAutoConfiguration → io.opentelemetry.sdk.resources.Resource bean (traces & logs)
2. OtlpMetricsPropertiesConfigAdapter.resourceAttributes() → Map<String,String> for Micrometer's OtlpMeterRegistry

Because Micrometer's OTLP registry is its own implementation (not the OTel SDK), it can't consume an OTel Resource directly. This means dynamically detected attributes need to flow into both consumers consistently, or signals will disagree on resource identity.

Question for the community

Is this something Spring Boot would want to support? If so, what would be the preferred approach? A few directions come to mind:

• A Spring-native callback interface (similar to how Boot exposes other extension points), collected as beans and merged into
  OpenTelemetryResourceAttributes
• Adopting the OTel ResourceProvider SPI (`opentelemetry-sdk-extension-autoconfigure) — brings ecosystem compatibility but adds a heavier dependency and requires a lossy bridge for the Micrometer Map path
• Something else entirely

Happy to put together a more detailed proposal or a proof of concept if the team thinks this is worth pursuing.

Start by reading OpenTelemetrySdkAutoConfiguration and OtlpMetricsPropertiesConfigAdapter.resourceAttributes(), then compare how resource attributes reach the OTel Resource bean and Micrometer's OtlpMeterRegistry. Review the OpenTelemetry resource-detector specification and the issue's proposed extension points. Done means an agreed approach or a detailed proposal/POC that keeps detected attributes consistent across both consumers.