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

Support for a histogram buckets api #452

Open
0xForerunner opened this issue Feb 22, 2024 · 1 comment
Open

Support for a histogram buckets api #452

0xForerunner opened this issue Feb 22, 2024 · 1 comment
Labels
C-core Component: core functionality such as traits, etc. E-complex Effort: complex. T-request Type: request.

Comments

@0xForerunner
Copy link

0xForerunner commented Feb 22, 2024

Doesn't look like this has been asked here before. One thing my team is looking for is the ability to specify histogram buckets when registering a histogram. This can currently be done at the exporter level, but there are a few reasons why this would be useful at the registration level. One reason being ease of configuration. A library should be able to suggest an appropriate bucket distribution that a consumer can then accept by default or override. This would also provide a unified interface for exporters to support which can help with making exporters more compatible with each other. Not sure exactly what the api should look like, perhaps:

describe_histogram!("my_hist", "histogram with exponential buckets").with_exp_buckets(0.1, 1.5, 25);
@tobz tobz added C-core Component: core functionality such as traits, etc. E-complex Effort: complex. T-request Type: request. labels Feb 28, 2024
@tobz
Copy link
Member

tobz commented Feb 28, 2024

👋🏻

This is not the first time this request has been made, but in general, I've consciously avoided providing an API like this because it forces particular decisions around using histograms that I believe are better left as an exporter concern.

At a high level, doing this right now would mean changing the recorder API in a way that I'm not willing to do. This change would only benefits Prometheus users, and that's too much of an idiosyncrasy to bake into the core API. I do have thoughts/plans around a future API change to support for generic/arbitrary metric metadata, one that could potentially support defining exporter-specific details that doesn't force the API to take on such Prometheus-specific details... but that's a ways off.

This is hopefully something that can be addressed before that by Prometheus finally releasing native histogram support as GA.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-core Component: core functionality such as traits, etc. E-complex Effort: complex. T-request Type: request.
Projects
None yet
Development

No branches or pull requests

2 participants