Fixes https://github.com/spring-projects/spring-boot/issues/38218

Comment From: mhalbritter

Hey, thanks for the issue and the PR.

In the OpenTelemetry SDK, they use this as the default:

  private static final Resource MANDATORY =
      create(Attributes.of(SERVICE_NAME, "unknown_service:java"));

I wonder if we should use our default at all. What do you think of this change?

    SdkTracerProvider otelSdkTracerProvider(Environment environment, ObjectProvider<SpanProcessor> spanProcessors,
            Sampler sampler) {
        String applicationName = environment.getProperty("spring.application.name");
        Resource springResource = Resource.create((applicationName != null) ? Attributes.of(ResourceAttributes.SERVICE_NAME, applicationName) : Attributes.empty());
// ...

That would only set the service name if the application name is set, otherwise it will use OTels SDK defaults.

Comment From: lenin-jaganathan

Micrometer is not using OTEL SDK's so metrics will be using unknown_service as default. If service.name is not set in Resource bean, do you think it will cause inconsistencies between traces and metrics?

Comment From: mhalbritter

Could be, that would be a question for the Micrometer team, I'll point them to that issue. Let's see what they say.

Comment From: mhalbritter

So, OTels default of unknown_service:java is wrong when the application is running as a native image, as the format of service.name is name:process.executable.name.

I lean towards making the Boot default unknown_service, which is correct when running in a native image and is also the same as in Micrometer.

The only thing I'm worried is that this is a breaking change if users haven't set spring.application.name. We have to decide in which version to ship this.

Comment From: wilkinsona

The only thing I'm worried is that this is a breaking change if users haven't set spring.application.name. We have to decide in which version to ship this.

I think it should be 3.2 at the very earliest and probably wait until 3.3 given where we are in 3.2's schedule.

Comment From: lenin-jaganathan

I believe for metric users moving from 3.1 to 3.2 will be a breaking change. As per this code and this code, I believe if service.name was not explicitly set in properties or OTEL_SERVICE_NAME is not an environmental variable 3.1 will use unknown_service as default. OpenTelemetry Resources were made common (between metrics and tracing) only in 3.2.

For tracing yes, it might be a breaking change given that in 3.1 "application" was used a fallback value.

Comment From: mhalbritter

We need to adjust the name in org.springframework.boot.actuate.autoconfigure.metrics.export.otlp.OtlpPropertiesConfigAdapter, too.

Comment From: mhalbritter

Thank you very much and congratulations on your first contribution :tada:!