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/CAO0Y1hfM%2B%3DkRcnA%3D1Uoj6z40zgGULBQi4WLGh9W6DDStL1wcSg%40mail.gmail.com.
