Updated service.name resource attribute logic in Plugin #219
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of changes:
Previously, there was an issue where the service.name attribute is the resource attributes for Traces and Metrics would be different when the service name is not set in the
OTEL_RESOURCE_ATTRIBUTES
env var. Turns out upstream has fallback logic that sets the service.name attribute to the assembly name if it's not set instead of usingunknown_service
.However, since we create our own MeterProvider for application signals, the fallback logic doesn't apply for those resources created outside of the opentelemetry instrumentation pkg. This PR adds this logic locally so that if service.name is empty, it calls the fallback function to get the assembly name or the process name. If either of that fail, then we default to
UnknownService
.Testing:
Enabled unknown_service_name_test.py and updated it to check for the assembly name because of the fallback logic instead of unknown_service.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.