Thank you chris for the explanation, this is cristal clear to me now :)
but I feel like there's something missing there. I totally understand why
the delta/increase/rate functions needs extrapolation at boundaries but I
feel like some use cases would need a version of those functions without
extrapolation. That is why I proposed PR #13436
<https://github.com/prometheus/prometheus/pull/13436> to add the
adelta/aincrease/arate functions to promql.
hope this help
++ Jerome
Le vendredi 19 janvier 2024 à 17:53:26 UTC+1, Chris Siebenmann a écrit :
> > I understand that there can be some interpolation at the boundaries, but
> > the value is not changing around the boundaries, it only changes in the
> > middle of the time range. Scrap is done every 15s and the value of the
> > metric is constant more than 1 minute before and after the boundaries. I
> > deliberately chose a range with constant values around the boundaries to
> > prevent any mis-interpolation.
> >
> > I'm using promtool to check values, here are my results:
> [...]
> > promtool query range --start "$(date -d'2024-01-18 14:00:00 UTC' +%s)"
> > --end "$(date -d'2024-01-18 14:15:00 UTC' +%s)" $url 'metric'
> > metric 9732212 @[1705586400]
> > ...
> > metric 9848219 @[1705587300]
> > --> it returns 302 samples
> >
> > promtool query instant --time "$(date -d'2024-01-18 14:15:00 UTC' +%s)"
> > $url 'metric[15m]'
> > 9732212 @[1705586407.092]
> > 9732212 @[1705586422.092]
> > 9732212 @[1705586437.092]
> > 9732212 @[1705586452.092]
> > 9732212 @[1705586467.092]
> > 9732212 @[1705586482.092]
> > 9732212 @[1705586497.092]
> > ...
> > 9848219 @[1705587142.092]
> > 9848219 @[1705587157.092]
> > 9848219 @[1705587172.092]
> > 9848219 @[1705587187.092]
> > 9848219 @[1705587202.092]
> > 9848219 @[1705587217.092]
> > 9848219 @[1705587232.092]
> > 9848219 @[1705587247.092]
> > 9848219 @[1705587262.092]
> > 9848219 @[1705587277.092]
> > 9848219 @[1705587292.092]
> > --> it returns 61 samples
> > The timestamps are a bit different but values are right. But it returns
> way
> > less samples than the range query. I would expect the same number of
> > samples returned by the 2 queries.
>
> This is a (natural) misunderstanding of what range queries do. A range
> query evaluates your query term at every step through the range from
> start to end, and returns a list of those results, each one with the
> timestamp it was evaluated at. If you don't provide a step, Prometheus
> works out a default one based on the time range, and experimentally the
> default step for a 15 minute time range is 3 seconds (you can see this
> in the Prometheus web interface), which gives about the right number of
> answers as you get in your range query. A range query explicitly does
> not restrict itself to the number of time series points that are
> actually in the time range; it will freely re-use the same points across
> multiple instant queries within the range.
>
> (This is commonly visible if you use rate() with a time range larger
> than the step size. If you query for 'rate(metric[2m])' for a range
> query with a step of 3s, you will get a lot of duplicate results.)
>
> The instant query for a time range gives a range vector as the result,
> which contains the true set of time series points with their true
> timestamps. Since you're querying a fifteen minute time range for a
> metric scraped every 15 seconds, 61 samples is about right for what
> you'd expect as the time series points scraped over that amount of time.
> We can also see here that the first point was collected at 14:00:07 UTC
> and the last one at 14:14:52. This means that a delta() of this same
> range will extrapolate out to cover an additional 15 seconds (covering 7
> missing seconds from the start and 8 missing seconds from the end).
>
> > now let's compute the delta:
> > promtool query instant --time "$(date -d'2024-01-18 14:15:00 UTC' +%s)"
> > $url 'metric - metric offset 15m'
> > {} => 116007 @[1705587300]
> > --> this matches to 9848219 - 9732212
> >
> > promtool query instant --time "$(date -d'2024-01-18 14:15:00 UTC' +%s)"
> > $url 'delta(metric [15m])'
> > {} => 117973.22033898304 @[1705587300]
> > --> this does not match
>
> This delta() result is actually very close to the result that 'bc -l'
> gives me for a manual extrapolation of those extra 15 seconds. The true
> difference between the first and last points within the range vector is
> 116007, the entire range vector covers 15 minutes less fifteen seconds,
> or 885 seconds, and we're extrapolating it to 15 minutes:
>
> $ bc -l
> (15*60) / 885
> 1.01694915254237288135
>
> (( 15 * 60 ) / 885 ) * 116007
> 117973.22033898305084676945
>
> It feels weird that a total of a fifteen second gap at the start and end
> of the range can have such a big effect, but as we can see the extra
> time is not trivial at the level of this calculation. If the absolute
> numbers are smaller the absolute difference between them will also be
> smaller, but the relative difference would always be the same.
>
> - cks
>
--
You received this message because you are subscribed to the Google Groups
"Prometheus Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to prometheus-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/prometheus-users/1741d16e-22b4-4cbe-83cb-b002a3aaee9cn%40googlegroups.com.
