Skip to content
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

deltatocumulative: Number of buckets in exponential histograms should be capped #33277

Open
euroelessar opened this issue May 29, 2024 · 6 comments
Assignees
Labels
bug Something isn't working processor/deltatocumulative

Comments

@euroelessar
Copy link

Component(s)

processor/deltatocumulative

What happened?

Description

Currently size of an individual histogram is unbounded and can grow until OOM is reached.
This is prominent if an application has large distribution of data overall but only relatively small in an individual delta datapoint. In this case cumulative aggregation keeps the scale but keeps growing number of buckets to fit all the data.

Steps to Reproduce

Send two histogram datapoints with the same scale but drastically different offsets.

Expected Result

Cumulative exponential histogram is downscaled to keep around ≈160 buckets.

Actual Result

Exponential histogram grows number of buckets instead, leading to OOM.

Collector version

v0.101.0

Environment information

Environment

OS: Linux
Compiler(if manually compiled): go 1.22.2

OpenTelemetry Collector configuration

No response

Log output

No response

Additional context

No response

@euroelessar euroelessar added bug Something isn't working needs triage New item requiring triage labels May 29, 2024
Copy link
Contributor

Pinging code owners:

See Adding Labels via Comments if you do not have permissions to add labels yourself.

Copy link
Contributor

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

See Adding Labels via Comments if you do not have permissions to add labels yourself.

@github-actions github-actions bot added the Stale label Jul 30, 2024
@sirianni
Copy link
Contributor

sirianni commented Aug 7, 2024

Hitting this issue as well
image

@github-actions github-actions bot removed the Stale label Aug 8, 2024
@edma2
Copy link
Contributor

edma2 commented Aug 29, 2024

#34157 should address it, we've been using it in production for over a month. Can someone please review?

Copy link
Contributor

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

See Adding Labels via Comments if you do not have permissions to add labels yourself.

@github-actions github-actions bot added the Stale label Oct 29, 2024
@edma2
Copy link
Contributor

edma2 commented Nov 5, 2024

This problem is still relevant and we would not be able to use deltatocumulative in production without #34157.

@sh0rez @RichieSams @jpkrohling please review 😄

@github-actions github-actions bot removed the Stale label Nov 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working processor/deltatocumulative
Projects
None yet
Development

No branches or pull requests

5 participants