open-telemetry / opentelemetry-python

OpenTelemetry Python API and SDK
https://opentelemetry.io
Apache License 2.0
1.66k stars 568 forks source link

Improve resource field structure for LogRecords #3972

Closed emdneto closed 1 week ago

emdneto commented 2 weeks ago

Description

In #3547, we suggested the resource field structure be more consistent for LogRecords by making it similar to the representation used in Spans when using a console exporter. This PR extends that by improving the resource field structure for LogRecords using the resource.to_json() method in the same way we have in spans

Type of change

Please delete options that are not relevant.

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

Does This PR Require a Contrib Repo Change?

Checklist:

lzchen commented 2 weeks ago

Are you getting a different output with the current implementation? I seem to get the expected dict representation when printing out the attributes of a resource.

tp = TracerProvider()
print(repr(tp.resource.attributes))

outputs:

{'telemetry.sdk.language': 'python', 'telemetry.sdk.name': 'opentelemetry', 'telemetry.sdk.version': '1.25.0', 'service.name': 'unknown_service'}
emdneto commented 2 weeks ago

Are you getting a different output with the current implementation? I seem to get the expected dict representation when printing out the attributes of a resource.

tp = TracerProvider()
print(repr(tp.resource.attributes))

outputs:

{'telemetry.sdk.language': 'python', 'telemetry.sdk.name': 'opentelemetry', 'telemetry.sdk.version': '1.25.0', 'service.name': 'unknown_service'}

I think this repr is fine, but I was working on some tests with LogRecord and noticed the structure of the resource field is different from the one we have for spans (for example) during the to_json() call in LogRecord.

I found this issue https://github.com/open-telemetry/opentelemetry-python/issues/3547, which was concerned about that too. So I'm suggesting we use resource.to_json() for the resource field in the same way we have in traces sdk instead of repr. I updated the PR description to be more clear.