What you need is the increase() function, that will calculate the difference between the counter values at the start and at the end of the specified time interval. It also correctly handles counter resets during that time period (if any).
increase(http_requests_total[24h])
If you have multiple counters http_requests_total (e.g. from multiple instances) and you need to get the cumulative count of requests, use the sum() operator:
sum(increase(http_requests_total[24h]))
See also my answer to that part of the question about using Grafana's time range selection in queries.
Answer from Yoory N. on Stack OverflowHello,
I have this graph monitoring the bandwidth of a VLAN on a switch every 1m using SNMP Exporter, but I also what to get the total/sum data over time, so if I select the last hour it will show x amount inbound and x amount outbound.
sum by(ifName) (irate(ifHCInOctets{instance=~"192.168.200.10", job="snmp_exporter", ifName=~".*(1001).*"}[1m])) * 8My current graph:
I'd like to duplicate and create a stat panel show how much data in total has passed over what period I choose that's all.
For the metric I'm not sure whether to use bytes(SI) or bytes(IEC), but are similar if I change to either.
Not sure how to calculate this, but I have this created for the past 1 hour.
by copying the PromQL in Grafana and changing to a stat panel and then editing to use this:
Not sure if this is ok as I'm not sure how to calculate it all, maths was never my best subject.
Any help would be great.
I think something like is close: with sum_over_time
sum by(ifName) (sum_over_time(ifHCInOctets{instance=~"192.168.200.10", job="snmp_exporter", ifName=~".*(1001).*"}[1m])) * 8but it comes back as 85.8 Pib when it should be 85.8 TB with my calculations.
EDIT
Observium:
What Grafana shows
What is the difference between sum_over_time() and sum()?
How does sum_over_time() handle missing data points?
When should I use recording rules with sum_over_time()?
What you need is the increase() function, that will calculate the difference between the counter values at the start and at the end of the specified time interval. It also correctly handles counter resets during that time period (if any).
increase(http_requests_total[24h])
If you have multiple counters http_requests_total (e.g. from multiple instances) and you need to get the cumulative count of requests, use the sum() operator:
sum(increase(http_requests_total[24h]))
See also my answer to that part of the question about using Grafana's time range selection in queries.
SO won't let me comment on Yoory's answer so I have to make a new one...
In Grafana 5.3, they introduced $__range for Prometheus that's easier to use:
sum(rate(http_requests_total[$__range]))
This variable represents the range for the current dashboard. It is calculated by to - from
http://docs.grafana.org/features/datasources/prometheus/
Hi there, I am using the fronius-exporter to scrape metrics from my PV inverter. One of the interesting metrics is
fronius_site_power_grid, this describes the power in Watt that is consumed or supplied to the grid.
Example:
-
fronius_site_power_grid = 4242W --> buying energy from the grid
-
fronius_site_power_grid = -2424W --> selling energy from the grid
Now I want to sum-up all the energy that was bought or sold in one day. The following PromQL came into my mind:
sum_over_time(fronius_site_power_grid[24h]) *15 / 3600
This should give me the Energy in Wh that was transferred to/from grid.
How can I get a summed-up value for consumed or supplied that is not combined?
With PromQL is tried the following code that was failing:
sum_over_time(clamp_max(last_over_time(fronius_site_power_grid[15s]), 0)[24h]) *15 / 3600
Hint: 15s is my scrape interval
Your question isn't 100% clear, but I think you are looking for sum(increase(purchases_total{deviceType='ios'}[1d])) and then use a 1d step to the query_range API with start/end covering 7 days.
The following PromQL query should return the number of purchases for the previous day:
last_over_time(
increase(purchases_total{deviceType='ios'}[1d])[1d:1d]
)
It uses subquery feature over last_over_time and increase functions. The outer last_over_time(...[1d:1d]) is needed in order to align calculations to boundaries between days in UTC time zone.
The query returns results shifted by one day in the past. This can be fixed by adding offset -1d to the query:
last_over_time(
increase(purchases_total{deviceType='ios'}[1d] offset -1d)[1d:1d]
)
Note also that Prometheus may return fractional results from increase() over integer counters because of extrapolation. See this issue for details. Additionally, Prometheus ignores the difference between the last sample on the previous day and the first sample on the current day when calculating increase(). This may lead to incorrect results for slow-changing counters. See this comment and this article for details. Both issues should be addressed soon by Prometheus developers according to this design doc.
In the mean time it is possible to use VictoriaMetrics, which provides increase() function without these issues.