Sub query support for range selection.

[fabxc]

Currently one can only do range selection on vector selectors and has to use recording rules to range-select expressions.

[brian-brazil]

An interesting question is how we choose the interval for this, currently it's not needed as everything in calculated at a point. We should also look at how to discourage/prevent use of this in rules/alerts on performance grounds.

[grobie]

👍

[Andor]

Currently we can run query like rate(hit[1m]) + rate(miss[1m]), which is not very convenient.
IMHO better syntax is something like this: rate(hit+miss [1m]) or rate((hit+miss) [1m])

[brian-brazil]

That's incorrect usage, you need to do the rate separately first or you'll get the wrong answer around counter resets. I'd also suggest that the exporter do either total&hit or total&miss, as that's a bit easier to work with.

[guoshimin]

Being able to run range queries on arbitrary expressions is valuable for ad-hoc explorations, either for sanity checking before making recorded rules, or for analyzing past data where you didn't already have recorded rules.

[roman-vynar]

Will leave one of the references with discussion on this topic https://groups.google.com/forum/#!topic/prometheus-users/JOVfqQsVRl8

[virusdave]

Is there any ticket tracking this feature request (historical function evaluation)?

[brian-brazil]

This is the issue for it. I wouldn't be too hopeful of it ever getting implemented.

[virusdave]

OK. Is that due to a philosophical issue, or a eng-resource-scarcity problem?

[brian-brazil]

It's a semantic issue, and an operational one. It's unclear how to do this correctly, and even then its use would have to be greatly limited for safety.