-
Notifications
You must be signed in to change notification settings - Fork 893
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
Exempt resources from attribute limits #1892
Exempt resources from attribute limits #1892
Conversation
cb50353
to
0b93524
Compare
0b93524
to
f560401
Compare
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.
+1
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.
From the metric perspective, resource attributes also need to be exempt from limits because they are part of the metric stream identity https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/datamodel.md#opentelemetry-protocol-data-model
f560401
to
44b38e5
Compare
Ping @iNikem @open-telemetry/specs-metrics-approvers |
Related issue for metrics: #1782 |
Spec modification as proposed by this PR nicely described why resource attributes CAN be excluded from attribute limits. But it does not explain why they SHOULD or why do we want to have such an exception. PR description has some justification:
Are current attribute limits specific/scoped into |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
44b38e5
to
8a2aee6
Compare
@iNikem Yes, I can confirm at least Java, Python, Go and Node/JS do this. |
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.
@owais I still think we should add some justification about "Why" from PR description into the text added
Resources are not susceptible to scenarios where excessive attributes can be recorded unlike Spans. Resources are also immutable and it can be hard for some SDKs to apply the limits at source at the time the attributes are added to a resource. Furthermore, limits and Resources both are generally defined and passed on to a TracerProvider which forces a TracerProvider to either mutate the resource or generate a new one with duplicate attributes in order to apply the limits to it.
8a2aee6
to
998ba83
Compare
@iNikem added. |
Ping @jsuereth |
Reviewers, please respond to unresolved comments. If you want to block merging then request changes, otherwise I am going to merge this since it has the required number of approvals. |
No further comments, merging. |
Resources are not susceptible to scenarios where excessive attributes can be recorded unlike Spans. Resources are also immutable and it can be hard for some SDKs to apply the limits at source at the time the attributes are added to a resource. Furthermore, limits and Resources both are generally defined and passed on to a TracerProvider which forces a TracerProvider to either mutate the resource or generate a new one with duplicate attributes in order to apply the limits to it. Co-authored-by: Tigran Najaryan <[email protected]>
Resources are not susceptible to scenarios where excessive attributes
can be recorded unlike Spans. Resources are also immutable and it can be
hard for some SDKs to apply the limits at source at the time the
attributes are added to a resource. Also Limits and Resources
both are generally defined and passed on to a TracerProvider which
forces a TracerProvider to either mutate the resource or generate a new
one with duplicate attributes in order to apply the limits to it.
I propose we explicitly exempt Resources from attribute limits.
Changes
Exempt Resources from attribute limits.