> I have a counter and I want to counter the number of occurences on a
> duration (let's say 15m). I'm using delta() or increase but I'm not getting
> the result I'm expecting.
>
> value @t0: 30242494
> value @t0+15m: 30609457
> calculated diff: 366963
> round(max_over_time(metric[15m])) - round(min_over_time(metric[15m])):
> 366963
> round(delta(metric[15m])): 373183
> round(increase(metric[15m])): 373183
>
> increase and delta both return the same value but it appears to be wrong
> (+6220) while max_over_time - min_over_time return the expected value.
>
> I do not understand this behaviour. I must have miss something.
I suspect that you may be running into delta() and increase() time range
extrapolation. To selectively quote from the delta() documentation
(there's similar wording for increase()):
The delta is extrapolated to cover the full time range as
specified in the range vector selector, so that it is possible
to get a non-integer result even if the sample values are all
integers.
As far as I know, what matters here is the times when the first and last
time series points in the range were recorded by Prometheus. If the
first time series point was actually scraped 35 seconds after the start
of the range and the last time series point was scraped 20 seconds
before its end, Prometheus will extrapolate each end out to cover those
missing 55 seconds. As far as I know there's currently no way of
disabling this extrapolation; you just have to hope that its effects are
small.
Unfortunately these true first and last values and timestamps are very
hard to observe. If you ask for the value at t0, the start of the range,
as a single value (for example issuing an instant query for 'metric
@<time>'), Prometheus will actually look back before the start of the
range for the most recently scraped value. The timestamp of the most
recently observed value is 'timestamp(metric)', and you can make that
'the most recently observed metric at some time' with 'timestamp(metric
@<time>)' (and then use 'date -d @<number>' to convert that to a
human-readable time string; 'date -d "20234-01-18 13:00" +%s' will go
the other way). If you know your scrape interval, it's possible to
deduce the likely timestamp of the first time series point within a
range from getting the timestamp of the most recent point at the start
of the range (it's likely to be that time plus your scrape interval,
more or less).
(The brute force way to find this information is to issue an instant
query for 'metric[15m]', which in the Prometheus web interface will
return a list of measurements and timestamps; you can then look at the
first and last timestamps.)
- 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/3105303.1705613195%40apps0.cs.toronto.edu.
