You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There have been a few different ways to model histogram buckets proposed, which are largely equivalent.
From a Prometheus standpoint we don't have flexibility here as we process every time series independently and already have this built into our language, so things need to follow what we already do to avoid us having to introduce a openmetrics_histogram_quantile function which would be both ugly and breaking for our users.
We need cumulative buckets which are named based on their inclusive upper bound, including a mandatory +Inf bucket which serves as overflow. There's no explicit underflow, as the first bucket includes everything below it.
For systems other than Prometheus which will be parsing whole Childs at once, converting to upper+lower bounds, de-cumulating or providing midpoints instead should all be a simple transformation.
Do we want to support negative buckets? Prometheus technically supports this, but I've never seen it used in practice and it can cause problems.
The text was updated successfully, but these errors were encountered:
Relevant discussion about negative bucket boundaries: #126 (review)
While practical uses are rare, it is easy to support negative buckets, so we should do it. Both Circonus and Datadog support negative buckets (as examples for hosted metrics providers that have decent implementations of histograms).
There have been a few different ways to model histogram buckets proposed, which are largely equivalent.
From a Prometheus standpoint we don't have flexibility here as we process every time series independently and already have this built into our language, so things need to follow what we already do to avoid us having to introduce a
openmetrics_histogram_quantile
function which would be both ugly and breaking for our users.We need cumulative buckets which are named based on their inclusive upper bound, including a mandatory +Inf bucket which serves as overflow. There's no explicit underflow, as the first bucket includes everything below it.
For systems other than Prometheus which will be parsing whole Childs at once, converting to upper+lower bounds, de-cumulating or providing midpoints instead should all be a simple transformation.
Do we want to support negative buckets? Prometheus technically supports this, but I've never seen it used in practice and it can cause problems.
The text was updated successfully, but these errors were encountered: