-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Add cardinality limiting to the metric SDK as an experimental feature #4457
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #4457 +/- ##
=====================================
Coverage 82.2% 82.2%
=====================================
Files 225 226 +1
Lines 18315 18342 +27
=====================================
+ Hits 15058 15085 +27
Misses 2975 2975
Partials 282 282
|
This comment was marked as outdated.
This comment was marked as outdated.
The Attribute method is still inlinable.
The tests for the exponential histogram create their own testing fixtures. There is nothing these new fixtures do that cannot already be done with the existing testing fixtures used by all the other aggregate functions. Unify the exponential histogram testing to use the existing fixtures.
This comment was marked as outdated.
This comment was marked as outdated.
I'm concerned about the performance of this patch, as it potentially adds another map lookup in the hot path. Have you checked that it doesn't have an impact on the disabled path at least, and what the effect might be on the eventual default config (e.g., large enough that all attributes will fit) Other than that, I think this will work. |
Given a map lookup is on the order of 10s of nanoseconds I'm not sure the overhead of this operation is going to be too impactful. I'm also not sure how to implement this feature in a more performant way. At some level we will need to determining from some saved memory location if the attributes have been seen. Did you have an alternate proposal? |
Given this is gated with a conditional the expected performance impact is a slight. With branch prediction being a thing, I imagine this is going to be negligible. Targeted benchmarking have validated this assumption, i.e.
|
The default is defined to be 2000: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk.md#configuration-1 I'm not aware of any objective data validating this number, but it is something we will adopt from the specification. The current PR does not use this default. The current default is unlimited as the feature is disabled by default. |
Part of #4095