Declarative config: extract Resource correctly

[zeitlinger]

Is your feature request related to a problem? Please describe.

When using declarative config, getResource() (it's protected) returns an empty instance.

In the agent, we access this instance.

Describe the solution you'd like

Possible solutions

• populate the resource in the SDK
• extract the resource from the tracer provider using reflection
• use some plugin from the SDK (not sure which)

Describe alternatives you've considered

No response

Additional context

No response

[zeitlinger]

@robsunday this is the resource issue

[robsunday]

I faced the issue of non populated resource when working on agent listener needing access to the resource when declarative config is used. I did some fix for this already but it awaits approvals. See open-telemetry/opentelemetry-java#7418
@jack-berg - it looks like Gregor also needs access to the resource.

[trask]

Java Declarative Config meeting notes:

One use case: Resources are currently used by MDC instrumentations to add resources to MDC attributes when user configures otel.instrumentation.common.mdc.resource-attributes

Another use case:

• Validating resources (e.g. giving user a warning about misconfigured service.name)
  • Possible in autoconfigure via addResourceCustomizer
  • In declarative config, resource detectors run after model customization

One option: OpenTelemetrySdk.getResources()

• Doesn't solve MDC instrumentation since that's API-based, but does align with keeping SDK concepts on the SDK side

Open question: does upcoming Entity work help this problem?

• Will EntityProvider be exposed to API?
• Will it be write only, or provide read access to Entities?

[jack-berg]

One use case: Resources are currently used by MDC instrumentations to add resources to MDC attributes when user configures otel.instrumentation.common.mdc.resource-attributes

If instrumentation needs access to the resource, doesn't that imply this needs to be an API concept rather than an SDK concept since we say that instrumentations shouldn't depend on the SDK?

Validating resources (e.g. giving user a warning about misconfigured service.name)

Is this the only SDK validation that users / distributions might want? I would imagine similar goals to validate and possibly warn about export and attribute limit configuration.

Open question: does upcoming Entity work help this problem?
Will EntityProvider be exposed to API?
Will it be write only, or provide read access to Entities?

👍 These are the right questions.

[trask]

If instrumentation needs access to the resource, doesn't that imply this needs to be an API concept rather than an SDK concept since we say that instrumentations shouldn't depend on the SDK?

yeah, the problem is that in the Java agent we hacked around this by grabbing the Resources at startup:

• SdkAutoconfigureAccess

and exposing them to instrumentation via our own API:

• ConfiguredResourceAttributesHolder

Here's an example of how MDC instrumentation uses that:

• OpenTelemetryContextDataProvider

what we're looking for is just a way to hack this again in declarative configuration

but agree that fundamentally this is a hack, and we should look into whether EntityProvider will give us a non-hacky solution in the future