Make the Resource accessible to Logging Library SDK

[vovencij]

What are you trying to achieve?
I want to enrich legacy first-party application logs with resource information. In order to do so, I have to make resource attributes accessible while configuring logging patterns. Logging happens in user code, but the Resource is currently a part of SDK, rather than API, which means that an application must depend on SDK, rather than API, to write resource attributes to a log file.

Additional context.

Related issue in opentelemetry-java: open-telemetry/opentelemetry-java#2466

[Oberon00]

Do you see any other use cases for reading these resource attributes, besides logging?

[vovencij]

At the moment I don't see any other relevant use cases besides logging.

[anuraaga]

Something that comes to mind is bringing in resource information for logic such as determining experiment IDs for a server. For example, if experiment is based on deployment name. Detection logic for the system for use in multiple places would otherwise need to be duplicated. Maybe it's expected though since such logic isn't telemetry.

[vovencij]

@tigrannajaryan what's your take on this?

[carlosalberto]

cc @bogdandrutu

[Oberon00]

Another advantage of making Resources part of the API is that custom resource detectors, etc. could be used by other API implementations beside the default SDK (depending on how we would design the SDK/API-split)

[tigrannajaryan]

Exposing Resources only via SDK never felt quite right to me anyway. Generally, I think everything the end user needs to interact with should be in the API.

With the risk of opening a can of worms a bit more on this.

Historically we limited this to operations that are used by instrumentation and excluded operations that need to be performed by application developers (e.g. the setup and configuration).

I do not think this is the right delineation approach. All end-user callable functionality should be in the API, including what application developers are expected to do for the purpose of setting up telemetry. Resource API falls into this category.

I think we can make this transition of operations from SDK to API gradually, without breaking API or SDK compatibility.

Either way, regardless of what we decide regarding all other SDK features, I think Resource needs to be in the API. We did not yet declare SDK stable so technically we are free to remove the Resource from SDK. However this may clash with our GA plans, so it may be easier to keep it in the SDK and expose what is necessary in the API (will need to think if it may cause any confusion due to exposing the same functionality in 2 places).

[tigrannajaryan]

I think we need to make it clear in the Logging Library SDK proposal how the Resource can be fetched from the SDK by the Logging Library SDK. If we do that then there is no longer a need to make the Resource part of the user-accessible API.