Support OTEL_SERVICE_NAME and OTEL_RESOURCE_ATTRIBUTES environment variables

[mmanciop]

The OTEL_SERVICE_NAME and OTEL_RESOURCE_ATTRIBUTES environment variables are a fundamental mechanic of configuring applications that generate OpenTelemetry data [^1].

The OpenTelemetryAutoConfiguration however, does not honor these env vars. Instead, it sets the service.name attribute to be the Spring Application name (which, by the way, is a pretty solid default), and additionally sets the non-standard service.group attribute (which does not exist in the OpenTelemetry semantic conventions for the service.* namespace [^2]) using the application group (if anything, the right attribute to set is service.namespace).

The behavior of OpenTelemetryAutoConfiguration should be changed as follows:

1. The resource attributes coming in through the management.opentelemetry should be right-merged with (i.e., should override in case of attribute key conflict) the default resource. (this is already current behavior)
2. Right-merge the OTEL_RESOURCE_ATTRIBUTES
3. Right-merge the service.name attribute if OTEL_SERVICE_NAME is set
4. If no service.name and service.namespace are set, right-merge the current Spring Boot-specific attributes.

For explanatory purposes, I prepared this branch: https://github.com/mmanciop/spring-boot/tree/opentelemetry-resource-env-vars

I am happy to finalize it (mostly: write the missing tests) if there is interest.

Note: I initially raised the issue on Micrometer Tracing (Issue #931).

[^1] https://opentelemetry.io/docs/specs/otel/configuration/sdk-environment-variables/#general-sdk-configuration
[^2] https://opentelemetry.io/docs/specs/semconv/resource/#service

[mhalbritter]

The linked document states:

Implementations MAY choose to allow configuration via the environment variables in this specification, but are not required to. If they do, they SHOULD use the names listed in this document.

We chose not to use the environment variables and instead use the configuration system from Spring Boot. What's the reason that you want to set OTEL_SERVICE_NAME instead of spring.application.name?

[wilkinsona]

We chose not to use the environment variables and instead use the configuration system from Spring Boot

Did we forget about OtlpMetricsPropertiesConfigAdapter when we made that decision? As far as I can tell it does honour OTEL_SERVICE_NAME, only using spring.application.name when OTEL_SERVICE_NAME is not set.

[mmanciop]

The linked document states:

Implementations MAY choose to allow configuration via the environment variables in this specification, but are not required to. If they do, they SHOULD use the names listed in this document.

We chose not to use the environment variables and instead use the configuration system from Spring Boot. What's the reason that you want to set OTEL_SERVICE_NAME instead of spring.application.name?

Because it is the standard OpenTelemetry way of doing things that people know from all other supported runtimes and languages. It avoids surprises when looking at applications through the lenses of deployment descriptors (like Kubernetes resources) and would work consistently in polyglot systems.

[mmanciop]

We chose not to use the environment variables and instead use the configuration system from Spring Boot

Did we forget about OtlpMetricsPropertiesConfigAdapter when we made that decision? As far as I can tell it does honour OTEL_SERVICE_NAME, only using spring.application.name when OTEL_SERVICE_NAME is not set.

I think so, but it is IMO a happy coincidence: the OtlpMetricsPropertiesConfigAdapter behaviour worked out of the box for me without having to read Spring Boot or Micrometer specific documentation. I just did what I do for all other OpenTelemetry-based setups, and it worked as I expected. So much so, that I perceived the Spring Boot behaviour as a bug or oversight.

[mhalbritter]

We chose not to use the environment variables and instead use the configuration system from Spring Boot

Did we forget about OtlpMetricsPropertiesConfigAdapter when we made that decision? As far as I can tell it does honour OTEL_SERVICE_NAME, only using spring.application.name when OTEL_SERVICE_NAME is not set.

True. That's because it uses OtlpConfig.super::resourceAttributes from Micrometer, which reads the environment variables.

[mhalbritter]

I'll discuss this with the team.

[mmanciop]

@mhalbritter hi, any update?

[mhalbritter]

We haven't talked about it yet.

[wilkinsona]

We discussed this today and decided that we'd like the OTLP tracing and logging support to consider OTEL_SERVICE_NAME and OTEL_RESOURCE_ATTRIBUTES in the same way as the metrics support already does.