-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Add drop_histogram_buckets function #40281
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
base: main
Are you sure you want to change the base?
Conversation
processor/transformprocessor/internal/metrics/func_drop_bucket.go
Outdated
Show resolved
Hide resolved
processor/transformprocessor/internal/metrics/func_drop_bucket.go
Outdated
Show resolved
Hide resolved
processor/transformprocessor/internal/metrics/func_drop_bucket.go
Outdated
Show resolved
Hide resolved
processor/transformprocessor/internal/metrics/func_drop_bucket.go
Outdated
Show resolved
Hide resolved
processor/transformprocessor/internal/metrics/func_drop_bucket.go
Outdated
Show resolved
Hide resolved
processor/transformprocessor/internal/metrics/func_drop_bucket.go
Outdated
Show resolved
Hide resolved
processor/transformprocessor/internal/metrics/func_drop_bucket.go
Outdated
Show resolved
Hide resolved
processor/transformprocessor/internal/metrics/func_drop_bucket.go
Outdated
Show resolved
Hide resolved
processor/transformprocessor/internal/metrics/func_drop_bucket.go
Outdated
Show resolved
Hide resolved
Signed-off-by: Israel Blancas <[email protected]>
This seems to break the Histogram data model, particularly removing sum. Why not (when removing buckets) place the removed data into some single bucket or 'overflow' bucket? I'm not really sure I understand the use case at all, but I'd be afraid this would break many metric backends and generally be a large footgun. Can you describe that more either in this PR or in the issue? |
I'm not sure about that solution, to be honest. One of the benefits is to reduce unused data.
Just if they use it and don't know what they are doing (as the rest of features we have in the OpenTelemetry Collector). Don't see the issue adding more flexibility.
It is common for Prometheus users doing this: metric_relabel_configs:
- source_labels: [__name__, le]
regex: 'example_latency_seconds_bucket;0\.0.*'
action: drop I want to replicate this feature in OpenTelemetry Collector. One ref, for instance https://www.robustperception.io/why-are-prometheus-histograms-cumulative/ |
Ah, so if you're removing buckets prometheus style, you have the benefit that buckets are just If you do the same in opentelemetry you NEED to add the counts from previous buckets into future buckets or you have literally lost data. I.e. if you use this function as it is defined, you just have a broken histogram, you wouldn't wind up with the same value as prometheus dropped buckets gives you. At a minimum you should:
Then you'd get the prometheus behavior. |
Any idea about how to do this? Because per my understanding Thanks for your comments @jsuereth |
Description
Add
drop_histogram_buckets
function.Link to tracking issue
Fixes #40280
Testing
Documentation
README.md