overhead of rate vs increase

[Johny]

In terms of samples fetched from the DB which is a cost limiting factor in our set up, what is the overhead of rate() compared to increase(). Based on my reading so far, rate() requires all data points within the time range interval thus it will fetch all data points from storage. On the other hand, the increase() function would fetch the first and last data point + penultimate data points for interpolation/extrapolation. Is it correct to state that increase() has lower overhead than rate() in terms of samples fetched with the overhead scaling up with time range interval?

thanks

Johny

[Ben Kochie]

They cost the same, both need to scan all samples in the range for counter resets.

In fact, the code for the two functions is identical. The only difference is when it's `rate()`, the resulting value is divided by the number of seconds in the range.

https://github.com/prometheus/prometheus/blob/291ab4d0bc6ea9f0e61073f303bd3982e9727b8d/promql/functions.go#L152-L154

--
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/c6b65724-696c-4e5a-8606-8e4cfba98b84n%40googlegroups.com.

[Brian Candler]

If you only need to see how a value has changed over a period, and don't have to deal with counter resets, then you can do:

foo - foo offset 24h

That sounds like how you *thought* increase worked (but it doesn't, because it handles counter resets in exactly the same way as rate)

[Johny]

thanks. yes, we decided to go with this approach for now while being aware of shortcomings when counters reset.

in future, we plan to use recording rules to compute rolled up running aggregates.