Make AutoConfiguredOpenTelemetrySdk's resource and config readable

[cyrille-leclerc]

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

Authors of OpenTelemetry integrations like the OpenTelemetry Maven Extension and the Jenkins OpenTelemetry Plugin are interested in read-only access to the config and resource loaded by the AutoConfiguredOpenTelemetrySdk during the build() creation method in order to ease troubleshooting and finding produced traces & metrics showing users the noteworthy

• Actual config like the exporters
• Actual resourcelike service.name and service.namespace

Describe the solution you'd like

Accessors to resource and config .

A solution to access the config is already available with i.o.s.autoconfigure.internal.AutoConfigureUtil#getConfig() | getStructuredConfig() .

I imagined:

• Either introduce AutoConfigureUtil#getResource()
• Or make #getResource(), getConfig(), and getStructuredConfig() public on AutoConfiguredOpenTelemetrySdk

This use cas is discussed with @SylvainJuge on

• Load OTel SDK config from environment variables and system properties.… opentelemetry-java-contrib#1434 (review)

Describe alternatives you've considered

Today we rely on Java reflection in the Jenkisn OTel Plugin: https://github.com/open-telemetry/opentelemetry-java-contrib/pull/1434/files#diff-d2ce824d3b67fe3fe10a6aee588ea13e40a93d71743dc2982e2fc1d3ae797b0f

Additional context

[jack-berg]

If its for troubleshooting purposes, have you considered just calling AutoConfiguredOpenTelemetrySdk.getOpenTelemetrySdk().toString()?

We're pretty good about including all the useful config properties in the string output. I think it should be common practice to print out the resolved OpenTelemetrySdk string representation in a logger. Probably at a fine granularity log level so users opt into it. Note that this is what the otel java agent does.

At you've probably noted AutoConfigureUtil and all its methods are internal and subject to breaking change.

The problem with accessing the autoconfigured resource is that in all the cases I've seen so far, its always been the wrong thing to do.

The problem with accessing the autoconfigured config is that we're going in a direction where the config will either be ConfigProperties (if using env vars / system properties), or StructuredConfigProperties (if using declarative config). I'm quite sure even if we document that only one or the other is non-null, callers will still open issues frustrated that ConfigProperties is null.

[cyrille-leclerc]

Thanks Jack, I'll try the toString() solution.