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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/prometheus-users/822fc17e-4d7f-4cf6-9774-ceef360ce53cn%40googlegroups.com.
