If you are not worried too much about what happens if the counter resets
during that period, then you can use:
(metric - metric offset 15m) >= 0
On Friday 19 January 2024 at 05:26:42 UTC+8 Chris Siebenmann wrote:
> > 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/822fc17e-4d7f-4cf6-9774-ceef360ce53cn%40googlegroups.com.
