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

Clarify that the auto-configured OpenTelemetry Resource will back off if you define your own #39372

Closed
wleese opened this issue Feb 1, 2024 · 3 comments
Labels
status: superseded An issue that has been superseded by another

Comments

@wleese
Copy link

wleese commented Feb 1, 2024

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.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Feb 1, 2024
@wilkinsona
Copy link
Member

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:

SdkTracerProviderBuilder builder = SdkTracerProvider.builder().setSampler(sampler).setResource(resource);

@wilkinsona wilkinsona changed the title Bug: Exposing a Resource bean will negate management.opentelemetry.resource-attributes usage Clarify that the auto-configured OpenTelemetry Resource will back off if you define your own Feb 1, 2024
@wilkinsona wilkinsona added type: documentation A documentation update and removed status: waiting-for-triage An issue we've not yet triaged labels Feb 1, 2024
@wilkinsona wilkinsona added this to the 3.2.x milestone Feb 1, 2024
@wleese
Copy link
Author

wleese commented Feb 2, 2024

@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.

@mhalbritter
Copy link
Contributor

Closing in favor of #39509.

@mhalbritter mhalbritter closed this as not planned Won't fix, can't repro, duplicate, stale Feb 12, 2024
@mhalbritter mhalbritter removed this from the 3.2.x milestone Feb 12, 2024
@mhalbritter mhalbritter added status: superseded An issue that has been superseded by another and removed type: documentation A documentation update labels Feb 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: superseded An issue that has been superseded by another
Projects
None yet
Development

No branches or pull requests

4 participants