Buckets should be defined at instrument level

[moorara]

Context

Currently, when using Prometheus exporter, buckets are set when creating and initializing a Meter and we have to know ahead of time if we want buckets to use Int64 boundaries or Float64 boundaries.

Problem

The boundaries we define is a function of the instrument we measure. Depending on the type of instrument and what the instrument measures, we need to define different buckets. So, we should be able to define buckets per instrument basis.

When defining buckets at Meter level, it means:

• We can only define one type of instruments, either Int64 or Float64.
• And we can only define one instrument (different instruments require different bucket configurations)

And since Meter is supposed to be singleton based on OpenTelemetry specifications, I can make a similar argument that quantiles should also be defined at instrument level. We may not necessary want the same quantiles for every instrument that uses summary aggregation.

[jmacd]

There are several questions and answers here.

---

OpenTelemetry Metrics is explicitly moving away from instruments named for the action they perform, and moving toward instruments named for how they are used. There is no Histogram instrument, which is part of the reason buckets can't be configured at the instrument level. In the forthcoming 0.4 metrics specification, there will be two instruments that will translate into Prometheus histograms by default, those are going to be named ValueRecorder and ValueObserver.

---

I'm not sure I understand what you mean about Int64 vs Float64. The choice here is for what kind of numbers you want to put in, there is not a semantic difference, only the domains are different in a way that does not meaningfully affect the default aggregation. If you have both int64 and float64 measurements, it would be appropriate to use a float64 instrument. It looks like Prometheus supports only float64 bucket boundaries. https://godoc.org/github.com/prometheus/client_golang/prometheus#HistogramOpts

---

About defining bucket boundaries, our intention is to support a Views API for configuring specific outputs based on the metric name and exporter, such as specific label dimensions, histogram boundaries or other aggregation options. See here: open-telemetry/oteps#89. I'm personally expecting to prototype a Views API in the Go SDK in May, after OpenTelemetry releases the 0.4 specification.

To get us to OpenMetrics compatibility, we should have support for linear, log-linear, and arbitrary bucket configurations for histogram aggregators. We've discussed this in the past in the context of the Prometheus exporter: #534

That being said, OpenTelemetry is also pushing away from the use of fixed histogram boundaries. We have better options available today--DDSketch, T-digest, and other mergeable summarization techniques--which work without explicit bucket configuration. These are better options than explicit percentiles as well.

---

So I think the Views API proposed above is the answer, but just a technical note:

Meter is supposed to be singleton based on OpenTelemetry specifications

It is true that there is a singleton global instance, it is provided as a convenience which allows metric instruments to be configured statically. (Note that Prometheus clients use a global registry, with the same benefit.) The default SDK can be used without being installed as the global. Multiple can co-exist in a process.