On Sun, 9 Feb 2020 at 18:11, Frederic Branczyk <[EMAIL PROTECTED]> wrote:
I don't think that the tediousness of a given task is sufficient to
determine adding new features, particularly if it's not something that a
human that has to type it completely by hand. Novel things that are
completely impractical to represent (not merely some repetition) are more
interesting from that standpoint.
I'd have a few concerns on this. Firstly there's the syntax question, this
would be adding brand new semantics to the PromQL language just to avoid
using templating from your configuration management system (or being smart
with round and count_values, or quantile/quantile_over_time depending on
what output you want).
Secondly, this would be a significant cardinality explosion risk. Right now
the most you can ever increase cardinality with PromQL is via absent, and
that's only from 0 to 1. This would allow you to multiply the cardinality
of the input by the number of buckets - and that could get big fast,
especially if we've fancier histograms in future. From a general
safety/resilience standpoint I consider this an important property of
Thirdly if the concern is indeed tediousness, then what if the user isn't
happy with explicitly listing each individual bucket and wants
linear/exponential options? That'd add even more functions to PromQL, and
even more of a cardinality risk.
I can see the potential uses of this, but the overall complexity plus the
cardinality risks do not seem like a good tradeoff for something that's
already completely possible today. I don't think trying to remove all
repetition/tedium from PromQL queries via changes at the PromQL level is a
good strategy, and solving such things at a higher level on top of PromQL
is a better option.