> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAG97UEmPzxB5Sr1rOpjYOrRURBuU%3DFP4YsWM-0mk6o9XZt4xBQ%40mail.gmail.com.
