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 (<bjo...@rabenste.in>) 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] bjo...@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 prometheus-developers+unsubscr...@googlegroups.com. > 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 prometheus-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAO0Y1hfM%2B%3DkRcnA%3D1Uoj6z40zgGULBQi4WLGh9W6DDStL1wcSg%40mail.gmail.com.
