Why does increase() return fractional results for integer-valued metrics?

[John Dexter]

increase(messages_total{direction='send'}[1m])

I am finding that queries like this are frequently return fractional values, even though these metrics are only ever incremented.

I am expecting increase() to show me the difference in the metric value between two time-stamps and both of those will be integral values so what is going on? Some interpolation perhaps?

I want to graph how how many messages were actually sent in each actual minute e.g. I should be able to corroborate the value on the graph with a log of each minute's activity in a log in testing.

[Ben Kochie]

Take a look at this blog post:

https://promlabs.com/blog/2021/01/29/how-exactly-does-promql-calculate-rates

--
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-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/CAGJRanhc27CwtOiX-s-qn1SFk%3DigsA3V%2BH5VB6ttdgW%2BrO8JNQ%40mail.gmail.com.

[Aliaksandr Valialkin]

Prometheus extrapolates `increase()` results - see https://github.com/prometheus/prometheus/issues/3746 for more details. There is an implementation, which returns exact results from increase() without extrapolation - https://victoriametrics.github.io/MetricsQL.html .

--
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-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/CAGJRanhc27CwtOiX-s-qn1SFk%3DigsA3V%2BH5VB6ttdgW%2BrO8JNQ%40mail.gmail.com.

--

Best Regards,

Aliaksandr Valialkin, CTO VictoriaMetrics

[John Dexter]

Thanks,

I don't think we want to change provider and we can live with it, but it is a shame we don't have both options - extrapolation being a feature many don't want.

I didn't read all that link but I am going to assume there is a technical reason PromQL doesn't just provide both?

John

[Julien Pivotto]

On 23 Mar 14:10, John Dexter wrote:
> Thanks,
>
> I don't think we want to change provider and we can live with it, but it is
> a shame we don't have both options - extrapolation being a feature many
> don't want.
> I didn't read all that link but I am going to assume there is a technical
> reason PromQL doesn't just provide both?

Hello,

We are working on a solution for this - and a PR should land soon.

What I am thinking about is a nincrease() function that does not do
interpolation.

The question then is what do we do with rate when samples don't
cover the majority of the range? Do we still return something?

Regards

>
> John
>
> On Mon, 22 Mar 2021 at 16:45, Aliaksandr Valialkin <val...@gmail.com>
> wrote:
>
> > Prometheus extrapolates `increase()` results - see
> > https://github.com/prometheus/prometheus/issues/3746 for more details.
> > There is an implementation, which returns exact results from increase()
> > without extrapolation - https://victoriametrics.github.io/MetricsQL.html .
> >
> > On Fri, Mar 19, 2021 at 4:55 PM John Dexter <jo...@jdxsolutions.com> wrote:
> >
> >> increase(messages_total{direction='send'}[1m])
> >>
> >> I am finding that queries like this are frequently return fractional
> >> values, even though these metrics are only ever incremented.
> >> I am expecting increase() to show me the difference in the metric value
> >> between two time-stamps and both of those will be integral values so what
> >> is going on? Some interpolation perhaps?
> >>
> >> I want to graph how how many messages were actually sent in each actual
> >> minute e.g. I should be able to corroborate the value on the graph with a
> >> log of each minute's activity in a log in testing.
> >>
> >> --
> >> 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-use...@googlegroups.com.
> >> To view this discussion on the web visit
> >> https://groups.google.com/d/msgid/prometheus-users/CAGJRanhc27CwtOiX-s-qn1SFk%3DigsA3V%2BH5VB6ttdgW%2BrO8JNQ%40mail.gmail.com

> >> <https://groups.google.com/d/msgid/prometheus-users/CAGJRanhc27CwtOiX-s-qn1SFk%3DigsA3V%2BH5VB6ttdgW%2BrO8JNQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> >> .

> >>
> >
> >
> > --
> > Best Regards,
> >
> > Aliaksandr Valialkin, CTO VictoriaMetrics
> >
>

> --
> 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-use...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/CAGJRangqMCPdQggQa2uEbGFz26dY_YZ0miatLKByR6vom5zUpw%40mail.gmail.com.

--
Julien Pivotto
@roidelapluie

[Stuart Clark]

On 23/03/2021 14:10, John Dexter wrote:
> Thanks,
>
> I don't think we want to change provider and we can live with it, but
> it is a shame we don't have both options - extrapolation being a
> feature many don't want.
> I didn't read all that link but I am going to assume there is a
> technical reason PromQL doesn't just provide both?

I think the main problem with not using extrapolation is that the answer
is often misleading. Samples will basically never correspond to the
times a query is requesting (e.g. you are querying at 11:34:07 but the
last sample was at 11:34:02) so you are then in a position to make a
good estimate of what the value should be. If you just took the last
sample without extrapolation it could be very old (for example 2 minutes
for a slowly scraped endpoint). For the majority of cases looking at how
things have been changing and extrapolating the forwards/backwards to
when you need values is often sensible and gives you a better idea of
what is going on.

Prometheus itself doesn't know what values are valid for a particular
metrics - all values are actually floats, so could have fractional
parts. If wanted you could use one of the rounding functions to force
the returned value to be an integer.

--
Stuart Clark