There's a.now out of date but working proof of concept PR from August last year that added TYPE, HELP and UNIT to the WAL and also to Prometheus Remote Write payloads (on a per TimeSeries samples basis): https://github.com/prometheus/prometheus/pull/7771
Once it's added to the WAL there's no reason it can't be put into both (A) any new Remote API and (B) extending the existing Remote Write API v1 as a minor release (e.g. Remote Write 1.1). There was a 20%-30% increase in network traffic with sending it with every single remote write request (on every series): https://github.com/prometheus/prometheus/pull/7771#issuecomment-675956119 We arrived with another solution over the course of discussion on the PR which would be to "send type and unit every time (since so negligible) but help only every 5 minutes" with perhaps some way to tweak this behavior via config or some other means. Rob On Fri, Nov 26, 2021 at 1:23 AM 'Fabian Reinartz' via Prometheus Developers <prometheus-developers@googlegroups.com> wrote: > > As maintainer of Prometheus server, in general, I am worried that >> getting a wal that'd be more "able" than the actual Prometheus TSDB >> would weaken the Prometheus server use case in favor of SaaS platforms. >> >> It does not sound great for the users who rely on Prometheus >> alone, which I think will continue to represent a large part of our >> community in the future. >> > > Where do you see the downside for these users? It doesn't seem that a > structured remote-write API would take anything away from > users using the Prometheus server with local storage. > > >> Additionally, the Query Engine should take advantage of those new >> properties as well: until we do not support that in Prometheus TSDB, >> it's harder to take advantage of the OpenMetrics types in the language. >> > > True, though I don't understand why this is an argument against the > remote-write protocol supporting the instrumentation data model. > > Tailing whatever structure TSDB currently supports, which will probably be > a moving target for some time, seems like it would cause unnecessary > change frequency to the API or require waiting a few years before making > any changes at all. > Or is the goal to not give service offerings access to more structure than > Prometheus itself can make use of? > > > I should say that I'm primarily speaking from technical curiosity here. > Our own offering doesn't need such fundamental changes, though > they would make some things a bit simpler of course. > > > On another front, from an efficiency standpoint, don't we want to batch >> samples from exact same ts in many cases (e.g network partition)? >> > > Could you elaborate with an example? > > -- > 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/CAG97UEmPzxB5Sr1rOpjYOrRURBuU%3DFP4YsWM-0mk6o9XZt4xBQ%40mail.gmail.com > <https://groups.google.com/d/msgid/prometheus-developers/CAG97UEmPzxB5Sr1rOpjYOrRURBuU%3DFP4YsWM-0mk6o9XZt4xBQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CABakzZb5hY3aKN7r-6Xq2andGhmeTEhLsyy%2BUAbHgigUhJL9nQ%40mail.gmail.com.
