Expose resource attributes as system properties

[vovencij]

Is your feature request related to a problem? Please describe.
Resource attributes, like service.name or environment can be also useful outside of traces. For example, having these attributes in logs can help correlate logs with traces. However, to access those attributes I need a dependency on the SDK. If I use auto-instrumentation, I don't have any source-code dependencies on the SDK. Moreover, if I need access to resource attributes I have to write custom code to expose those attributes for consumption.

Describe the solution you'd like
If resource attributes were exposed as system properties, then I have a vast amount of standard existing solutions to read them. Proposed solution would expose Resource attributes as system properties with opentelemetry. prefix.

In case of logging, most of logging frameworks allow referencing system properties in a pattern configuration, e.g. log4j property file:

appender.console.layout.pattern = service: ${sys:opentelemetry.service.name}, env: ${sys:opentelemetry.environment} %m%n 

or logback.xml:

<pattern>service: %property{opentelemetry.service.name}, env: %property{opentelemetry.environment}: %m%n</pattern>

[anuraaga]

@vovencij This is an interesting example. Do you mind filing an issue in the spec repo? I'm curious what others think about making Resource more accessible.

Otherwise, I feel like adding to system properties is a bit weird and this could be a first good example of a method to present to users as part of a agent-specific API. Actually we already had one, forceFlush which also is currently not possible to do for agent users I believe.

[vovencij]

System properties are quite java specific. I'm not quite sure I know how to rephrase the issue to be technology agnostic. From the spec perspective, attributes are there, just use the API. I just want to avoid adding a code-level dependency if I otherwise use auto-instrumentation.

[Oberon00]

For logging specifically, this might be covered by the planned logging specification.
But in general, I think it might be helpful to have resources on the API level somewhere. Maybe then we could also rethink how they are "associated" with TracerProviders and MeterProviders (which is currently unclear, see open-telemetry/opentelemetry-specification#1294 (comment)).

[jkwatson]

System properties are quite java specific. I'm not quite sure I know how to rephrase the issue to be technology agnostic. From the spec perspective, attributes are there, just use the API. I just want to avoid adding a code-level dependency if I otherwise use auto-instrumentation.

I think @anuraaga was suggesting to bring up the general topic of exposing Resource attributes in some way to logging instrumentation, rather than system properties in particular.

[jkwatson]

@vovencij I'm going to close this issue. We now expose the Resource in the auto-configure module explicitly and for your use-case, that will work.