-
Notifications
You must be signed in to change notification settings - Fork 895
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
[Common] Clarify Attribute support based on stable wire protocol definition of Attributes #2581 #2620
Conversation
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
Not stale |
To the extent that this would apply to attributes for traces and metrics I think this goes beyond clarification and changes the specification. To my knowledge there are no trace/metric SDK implementations that allow nested attributes. |
8bb0e81
to
08e3fed
Compare
If you read the spec changes, I believe that I have not specified that trace/metric implementations have to implement or allow for nested attributes. And even the PR comment from above I am stating how it I've now removed the "and some SDK's" based on re-reviewing the JavaScript implementation and removing it from the support matrix. What specific or additional clarification would you suggest? |
52fe194
to
2f9fc47
Compare
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
2fa721d
to
2cbe005
Compare
Please give this PR a more descriptive title. I think the "inconsistency" issue has been explained. It seems to me this is not solving an inconsistency but proposing a new feature. |
Renamed. I don't believe that this PR is identifying any new functionality, it is attempting to properly document what Attribute support is today.
While Spans and Metrics also use "Attributes" their definition of Attributes does not support nesting (from at the spec level), which if not clarified is going to cause confusion not just at the consumer level (using the API vs Protocol) but also at the implementation level when SDK's start to support the proper definition of the Logs Attributes |
In practice, you are proposing a new feature. This is not supported today.
Do note that OTLP is merely a protocol that can be used for transporting (a superset of) OpenTelemetry-generated data. It is not the authoritative definition of the data model. |
That is because none of the SDK's (that I'm aware of) are currently SPEC compliant for LOGS, once they start to correctly implement Attributes for Logs everyone will hit this issue. |
@@ -31,8 +32,15 @@ An `Attribute` is a key-value pair, which MUST have the following properties: | |||
- A primitive type: string, boolean, double precision floating point (IEEE 754-1985) or signed 64 bit integer. | |||
- An array of primitive type values. The array MUST be homogeneous, | |||
i.e., it MUST NOT contain values of different types. | |||
- When specified via semantic conventions it MAY (see [Nested Attributes](#nested-attributes)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not a clarification (as written in the PR title) but allows a new feature. Also what is allowed on the level of the basic attribute definition must not depend on semantic conventions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line explicitly calls out to see the Nested Attribute support which clarifies that this is NOT automatically supported by this line but must be explicitly defined by the semantic conventions (and is supported by Logs).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But it allows semantic conventions to add them, as written now, doesn't it?
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
8b0ba0b
to
fd3e680
Compare
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
Not stale as this is part of a larger issue like #2888 |
Don't have the ability (permissions) to re-open... |
…telemetry#2581 and Support map values and nested values for attributes open-telemetry#376
Use a Permalink Change Support table to yes/no rather than same as Compliance Matrix
dc809f8
to
f5b8f6e
Compare
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
Fixes #
#2581 [Common] Spec inconsistency with proto definition of Attributes
Changes
AnyValue
and clarifies Attribute Collections.Related issues ##376 Supportmap values andnested values for attributes #376