rate() vs irate() functions

5,045 views
Skip to first unread message

Peter Zaitsev

unread,
Dec 30, 2015, 8:41:30 PM12/30/15
to Prometheus Developers
Hi,

Looking at manual for irate() funstion I see

==============

irate()

irate(v range-vector) calculates the per-second instant rate of increase of the time series in the range vector. This is based on the last two data points. Breaks in monotonicity (such as counter resets due to target restarts) are automatically adjusted for.

The following example expression returns the per-second rate of HTTP requests looking up to 5 minutes back for the two most recent data points, per time series in the range vector:

irate(http_requests_total{job="api-server"}[5m])

irate should only be used when graphing volatile, fast-moving counters. Use rate for alerts and slow-moving counters, as brief changes in the rate can reset the FOR clause and graphs consisting entirely of rare spikes are hard to read.


==============

This looks confusing. It  says it calculate rate in  two last data points  yet it says it looks up to 5 minutes back.

Do I understand correctly these [5m] only make a difference if data points are sparse  but if I have capture setup  for every 5seconds   the irate()  over  [5m]    or [30s]   will give the same value ?

This is different from rate() function which  would  look at the average rate for  specified interval so  [5m] and [3m] can be significantly different ?

Do I miss something ?


Brian Brazil

unread,
Dec 31, 2015, 4:55:29 AM12/31/15
to Peter Zaitsev, Prometheus Developers
On Thu, Dec 31, 2015 at 1:41 AM, Peter Zaitsev <p...@percona.com> wrote:
Hi,

Looking at manual for irate() funstion I see

==============

irate()

irate(v range-vector) calculates the per-second instant rate of increase of the time series in the range vector. This is based on the last two data points. Breaks in monotonicity (such as counter resets due to target restarts) are automatically adjusted for.

The following example expression returns the per-second rate of HTTP requests looking up to 5 minutes back for the two most recent data points, per time series in the range vector:

irate(http_requests_total{job="api-server"}[5m])

irate should only be used when graphing volatile, fast-moving counters. Use rate for alerts and slow-moving counters, as brief changes in the rate can reset the FOR clause and graphs consisting entirely of rare spikes are hard to read.


==============

This looks confusing. It  says it calculate rate in  two last data points  yet it says it looks up to 5 minutes back.

Do I understand correctly these [5m] only make a difference if data points are sparse  but if I have capture setup  for every 5seconds   the irate()  over  [5m]    or [30s]   will give the same value ?

It's to gracefully handle a missed scrape. For continuous data it'll make no difference.

Brian
 

This is different from rate() function which  would  look at the average rate for  specified interval so  [5m] and [3m] can be significantly different ?

Do I miss something ?


--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--

Björn Rabenstein

unread,
Jan 1, 2016, 5:11:24 PM1/1/16
to Peter Zaitsev, Prometheus Developers
On Thu, Dec 31, 2015 at 2:41 AM, Peter Zaitsev <p...@percona.com> wrote:
>
> Do I understand correctly these [5m] only make a difference if data points
> are sparse but if I have capture setup for every 5seconds the irate()
> over [5m] or [30s] will give the same value ?

The range for `irate` is essentially how far you want to look back to
find the two latest samples. You probably want to set it to some small
multiple of the scrape interval to defend against a missed scrape (as
Brian said). If you set it to a much longer range, you'll also include
samples of series that are already ended (and only have samples at the
beginning of the interval), and that's probably not what you want.

--
Björn Rabenstein, Engineer
http://soundcloud.com/brabenstein

SoundCloud Ltd. | Rheinsberger Str. 76/77, 10115 Berlin, Germany
Managing Director: Alexander Ljung | Incorporated in England & Wales
with Company No. 6343600 | Local Branch Office | AG Charlottenburg |
HRB 110657B
Reply all
Reply to author
Forward
0 new messages