Expose Request per Second to Prometheus

[benediktwetzel]

Is there a way to calculate and expose requests per second?

I want to calculate request per second for each second precisely and not just by use of the total count and rate() function from Prometheus. This is because the rate() interval must be larger than the scrape interval and I don't want to scrape every second.

[chiabre]

What about using irate:

irate(v range-vector) calculates the per-second instant rate of increase of the time series in the range vector.

https://prometheus.io/docs/prometheus/latest/querying/functions/#irate

Il sab 11 lug 2020, 13:58 Benedikt Wetzel [email protected] ha scritto:

Is there a way to calculate and expose requests per second?

I want to calculate request per second for each second precisely and not just by use of the total count and rate() function from Prometheus. This is because the rate() interval must be larger than the scrape interval and I don't want to scrape every second.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/johrstrom/jmeter-prometheus-plugin/issues/83, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB2WL4BHM2F7FGTJTXJAKLLR3BHUZANCNFSM4OXIVVKA .

[benediktwetzel]

Thanks for the quick answer. I think that I also have to scrape every second for irate() so that the metric gives accurate values per second. Irate() calculates the per-second rate based on the last two points:

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.

So I have to scrape every second to ensure that the precision is one second.
Or am I wrong?

[chiabre]

If prometheus scrapes every x sec you can't gather accurate value below x sec resolution.

Irate provide an easy way to the most accurate value for a 1 sec resolution but with x>1 that will be an estimation.

You can play around with other stats (avg, max, min, stddev, pct) to better understand what happened during the interval.

Luca

Il sab 11 lug 2020, 14:10 Benedikt Wetzel [email protected] ha scritto:

Thanks for the quick answer. I think that I also have to scrape every second for irate() so that the metric gives accurate values per second. Irate() calculates the per-second rate based on the last two points:

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.

So I have to scrape every second to ensure that the precision is one second. Or am I wrong?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/johrstrom/jmeter-prometheus-plugin/issues/83#issuecomment-657054372, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB2WL4B42OEFUHQYB4KMHZLR3BJDTANCNFSM4OXIVVKA .

[benediktwetzel]

Yes you are right.

For this reason I am looking for a way to calculate the metric request per second and expose it with a gauge.

But I am not sure how to calculate this metric.

[GiovanniPaoloGibilisco]

Not really sure how to address this. Do you have any pointers to other exporters exposing metrics at sub-scraping granularity?

The only way I can think of is exposing multiple metrics (or adding labels) doing bucketing in the exporter code. This pose a couple of issues.

• not knowing scraping frequency a priory would make it hard to know how many buckets to create
• would increase number of metrics or labels which is discouraged by prometheus.
• would probably increase overhead due to the increased number of samples required to generate the metrics.

If there are other exporters addressing this issues it would be nice to see how they did it

Il Sab 11 Lug 2020, 14:28 Benedikt Wetzel [email protected] ha scritto:

Yes you are right.

For this reason I am looking for a way to calculate the metric request per second and expose it with a gauge.

But I am not sure how to calculate this metric.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/johrstrom/jmeter-prometheus-plugin/issues/83#issuecomment-657056150, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNQ756VAOHSDGBKTTS3TPDR3BLHPANCNFSM4OXIVVKA .

[benediktwetzel]

I'm not sure what the best solution is either. I think with a counter metric, sub-query granularity is not possible (apart from approximation with rate(), irate() or other PromQL functions).

So I thought that maybe a gauge metric can be used, which provides the request per second metric as a time series. Do you think this is possible? I am not sure how to implement that.