-
Notifications
You must be signed in to change notification settings - Fork 889
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify precedence of attributes when exporting to non-OTLP formats #2535
Labels
spec:miscellaneous
For issues that don't match any other spec label
triage:accepted:needs-sponsor
Ready to be implemented, but does not yet have a specification sponsor
triage:accepted:ready
Ready to be implemented. Small enough or uncontroversial enough to be implemented without sponsor
Comments
tigrannajaryan
added
the
spec:miscellaneous
For issues that don't match any other spec label
label
May 12, 2022
Since scope attributes are now part of the spec, we should probably include them in this effort. |
I updated the description to also include the Scope attributes. |
|
austinlparker
added
the
triage:accepted:ready
Ready to be implemented. Small enough or uncontroversial enough to be implemented without sponsor
label
Apr 9, 2024
tigrannajaryan
added
the
triage:accepted:needs-sponsor
Ready to be implemented, but does not yet have a specification sponsor
label
Apr 29, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
spec:miscellaneous
For issues that don't match any other spec label
triage:accepted:needs-sponsor
Ready to be implemented, but does not yet have a specification sponsor
triage:accepted:ready
Ready to be implemented. Small enough or uncontroversial enough to be implemented without sponsor
The specification does not tell what happens when exporting to a format that is not capable of representing attributes separately for the Resource, for the Scope and for Span/Metric/LogRecord.
The exporter implementations have to flatten to one list of attributes and when the same attribute is present in the Resource, in the Scope and/or in the Span/Metric/LogRecord the implementation must make a decision about which attribute value takes precedence.
Existing implementations in Collector, for example Zipkin exporter make this decision on their own (in Zipkin exporter Span attributes have precedence over Resource attributes when converting to Zipkin tags).
I think we need to define this behavior in the specification to make it consistent for all such exporters.
This came up when discussing the precedence of Scope attributes in the OTEP.
The text was updated successfully, but these errors were encountered: