Proposal
PromQL presently lacks first_over_time() and ts_of_first_over_time() functions to pair with the current last_over_time() and new ts_of_last_over_time() functions.
This makes a variety of operations considerably more difficult, such as
- computing the duration over which a metric existed
- finding the timestamp a metric first appeared
- finding the first value of a metric within a step in a range query; currently it's necessary to use
last_over_time() with offset, and that's only been made possible by the new step() feature
I mostly feel the lack of first_over_time() when I'm trying to do meta-queries that are exploring and characterising metrics themselves.
For example, to find when a metric first appeared I need an inefficient and lower-resolution subquery based approach like:
min by (job) (min_over_time(timestamp(up{job=~"some-job"})[1d:5s]))
where the most recent timestamp can be trivially and considerably more efficiently found with:
max by (job) (ts_of_last_over_time(up{job=~"some-job"}[1d])
VM recognised the need for this and added tfirst_over_time(m[d]) etc.
Related
Proposal
PromQL presently lacks
first_over_time()andts_of_first_over_time()functions to pair with the currentlast_over_time()and newts_of_last_over_time()functions.This makes a variety of operations considerably more difficult, such as
last_over_time()withoffset, and that's only been made possible by the newstep()featureI mostly feel the lack of
first_over_time()when I'm trying to do meta-queries that are exploring and characterising metrics themselves.For example, to find when a metric first appeared I need an inefficient and lower-resolution subquery based approach like:
where the most recent timestamp can be trivially and considerably more efficiently found with:
VM recognised the need for this and added
tfirst_over_time(m[d])etc.Related