Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenTelemetry: Support OTEL_SERVICE_NAME and OTEL_RESOURCE_ATTRIBUTES env vars #43712

Open
mmanciop opened this issue Jan 7, 2025 · 6 comments
Labels
for: team-meeting An issue we'd like to discuss as a team to make progress status: feedback-provided Feedback has been provided status: waiting-for-triage An issue we've not yet triaged

Comments

@mmanciop
Copy link

mmanciop commented Jan 7, 2025

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

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Jan 7, 2025
@mhalbritter
Copy link
Contributor

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?

@mhalbritter mhalbritter added the status: waiting-for-feedback We need additional information before we can continue label Jan 7, 2025
@wilkinsona
Copy link
Member

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
Copy link
Author

mmanciop commented Jan 7, 2025

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
Copy link
Author

mmanciop commented Jan 7, 2025

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.

@spring-projects-issues spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Jan 7, 2025
@mhalbritter
Copy link
Contributor

mhalbritter commented Jan 7, 2025

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 mhalbritter added the for: team-meeting An issue we'd like to discuss as a team to make progress label Jan 7, 2025
@mhalbritter
Copy link
Contributor

I'll discuss this with the team.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for: team-meeting An issue we'd like to discuss as a team to make progress status: feedback-provided Feedback has been provided status: waiting-for-triage An issue we've not yet triaged
Projects
None yet
Development

No branches or pull requests

4 participants