histograms: Render a conventional histogram backed by a native histogram

[beorn7]

A Native Histogram can easily be exposed as a conventional Histogram, if need be in a lower resolution, maybe with configurable bucket selection.

Currently, conventional and native histograms are tracked separately from each other, which might be fine for some use cases. However, it also takes resources for each. Rendering a conventional histogram from the native histogram would have no added cost compared to a pure native histogram. The tricky part is what boundaries to pick for the conventional buckets. Changes in the bucket layout should be avoided, so we could have some reasonable default or make it configurable for the user.

Probably we should only use boundaries exactly representable by the Native Histogram. Interpolation might come with implications, but maybe we should consider it.

[beorn7]

Note that https://github.com/prometheus/prometheus/issues/11277 proposes explicitly configurable bucket boundaries in a Native Histogram with a custom bucket layout. This could be used to perfectly emulate any conventional Histogram. However, that's more attractive to use behind the scenes within the Prometheus server. Using it on the instrumentation side would only save a bit of resources for exposition (in case the scraper supports Native Histograms).

[beorn7]

I'm wondering if we should still go down this path. The reason to still expose classic buckets is to allow scrapes by older backends that are not capable of native histograms. As explained above, this comes at the cost of tracking two separate histograms (the classic and the native one) in the instrumented target. Implementing what's proposed here will avoid that cost, but the classic histogram "rendered for free" will have the "weird" bucket boundaries that result from a native histogram with a standard exponential schema.

So the question is: Is it worth implementing this (which is less trivial than it might look), for a use case that is surely declining over time, and only for a limited cost saving (tracking a moderately sized classic histogram), and resulting in a classic histogram with bucket boundaries that are potentially confusing or annoying for users.

Since there wasn't much noise around this issue over the last 1½ years, my assumption is that it's probably not worth it. I'll close this to signal that, but @kakkoyun @bwplotka @ArthurSens it's ultimately your call. Please just reopen if you think this should be tackled eventually.

[bwplotka]

Sorry for reopen/closing, I thought you talked about custom histograms, but this is for something else. Makes sense!