Agree, but I wouldn't press this until we have NHCB implemented and stable through the storage.
Nevertheless, I agree with @Bjoern Rabenstein <[email protected]> on the provided sketched plan. Kind Regards, Bartek Płotka (@bwplotka) On Sun, Sep 22, 2024 at 4:02 PM Jesús Vázquez <[email protected]> wrote: > I had this in my queue for a long time, finally got to it! > > We typically write proposals for new things such as features or > modifications but perhaps we could write a proposal for the deprecation of > classic histograms and lay out the different strategies for getting there? > > Regards > > El mié, 12 jun 2024 a las 15:33, Bjoern Rabenstein (<[email protected]>) > escribió: > >> Here is my idea for a deprecation plan: >> >> 1. On the server side, including PromQL: >> >> A future PromQL server should still be able to recognize classic >> histograms when scraped, but only to convert them to native histograms >> with custom buckets (NHCB). From that point on (storage, query, remote >> write), it shoud have no notion of classic histograms anymore. >> >> This is also a reason why I think a "reverse transparency" layer to >> query NHCB as if they were classic histograms is undesirable. We want >> to get rid of the query patterns for classic histograms. (Another >> reason is that it will be really hard to implement such a "reverse >> transparency" layer reliably.) >> >> >> 2. On the instrumentation side, including exposition formats: >> >> In direct instrumentation, if you need a histogram, you should default >> to a native histogram with a standard exponential schema (which >> guarantees mergeability across time and space and is compatible with >> OTel's eponential histogram). Only if you need custom bucket >> boundaries for some reason, you should use an NHCB. Generally, I think >> the libraries can even keep their existing API for that. If you >> instrument a histogram in the classic way, the API doesn't actually >> tell you that this will result in a classic histogram. It just asks >> you for the bucket boundaries, and then you call `Observe` as you do >> for a native histogram, too. Hence, future libraries can just expose >> an NHCB in that case. >> >> If you translate a histogram from a 3rd party source, you use a >> suitable flavor of native histograms as the translation target. In the >> unlikely case that the source histogram fits the exponential bucketing >> schema, use a regular exponential native histogram. For specific types >> of 3rd party histograms (e.g. DDSketch, but there are many more), we >> might implement additional schemas of native histograms that directly >> accommodate them. And finally, if nothing else fits, you do NHCB. >> >> The exposition formats of the future should be able to represent all >> flavors of native histograms, so that we don't need to expose classic >> histograms anymore. >> >> _However_, the existing Prometheus exposition formats are so >> ubiquitious by now, that I don't think they will ever die. For as long >> as technically feasible, Prometheus servers should be able to >> understand old exposition formats. Which circles back to the very >> beginning: Any Prometheus server should still understand classic >> histograms, but convert them into NHCB on scrape. >> >> -- >> Björn Rabenstein >> [PGP-ID] 0x851C3DA17D748D03 >> [email] [email protected] >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Prometheus Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/prometheus-developers/Zmmjs%2BQen6u7brfz%40mail.rabenste.in >> . >> > -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAMssQwauwuA2vs%3DMr9NsNiXhjQ%2BjVdBfrxjAD25EgcHA-YN8bQ%40mail.gmail.com.
