Spring Boot 3.2.0 exposes Resource as a Bean, as a way to specify attributes to be included in tracing exports.

There is also a property map management.opentelemetry.resource-attributes, which allows the same via property configuration.

In the documentation, one can read:

Additionally, it provides a Resource bean. The attributes of the Resource can be configured via the management.opentelemetry.resource-attributes configuration property.

The documentation does not describe that exposing a Resource bean, will prevent the property from being able to provide attributes (unless the newly exposed Resource bean, implements it).

It would be more logical if the property was always used when provided by the user.

May I also suggest moving from Resource to Supplier<Resource>, with an ObjectProvider being used to consume multiple user-defined beans? That way the user is more flexible with how and where things are set up.

Comment From: wilkinsona

The problem that you've described is a feature of how Spring Boot works. If the bean that you have replaced is the bean that was consuming and using the configuration properties, it is to be expected that those configuration properties will no longer have an effect. We can clarify this in the documentation by noting that the Resource bean that it's describing will back off if you define your own.

It would be more logical if the property was always used when provided by the user.

Unfortunately, we can't do that. By defining your own Resource you have told the auto-configuration that you do not want its Resource bean. I think it would be confusing if we ignored that and defined the bean anyway.

May I also suggest moving from Resource to Supplier, with an ObjectProvider being used to consume multiple user-defined beans? That way the user is more flexible with how and where things are set up.

Unfortunately, I don't think we can do that. The Resource is applied to OpenTelemetry's builder which only takes a single resource:

https://github.com/spring-projects/spring-boot/blob/f9363569abbbce80c2c4f318d936365d9a7678ea/spring-boot-project/spring-boot-actuator-autoconfigure/src/main/java/org/springframework/boot/actuate/autoconfigure/tracing/OpenTelemetryAutoConfiguration.java#L95

Comment From: wleese

@wilkinsona Thanks for the swift response. Indeed, if the logic to do something useful with the management.opentelemetry.resource-attributes property is handled by the provided Resource bean, this makes sense. I'm mostly getting at the confusion that can arise if not properly conveyed to the user.

Unfortunately, I don't think we can do that. The Resource is applied to OpenTelemetry's builder which only takes a single resource:

We simply merge multiple Resources like so (we provide a SdkTracerProviderBuilderCustomizer, but this can be done elsewhere of course):

    @Bean
    SdkTracerProviderBuilderCustomizer axleSdkTracerProviderBuilderCustomizer(ObjectProvider<Supplier<Resource>> resourceProviders) {
        return builder -> {
            var additionalResource =
                    resourceProviders.orderedStream()
                            .map(Supplier::get)
                            .reduce((mergedResource, newResource) -> newResource.merge(mergedResource));

            additionalResource.ifPresent(resource -> {
                logger.debug("OpenTelemetry tracer added resource: {}", resource);

                builder.addResource(resource);
            });
        };
    }

SdkTracerProviderBuilderCustomizer also wasn't documented btw, while it provides a more powerful way to influence trace exports. I can create a new issue if desirable.

Comment From: mhalbritter

Closing in favor of #39509.