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
prometheus - Get Total requests in a period of time - Stack Overflow
Possible to sum counter increase within range of hours, every day? - PromQL - Prometheus Monitoring System
promql - Which prometheus querying function must be used to get values per day from total? - Stack Overflow
Sum of a Prometheus metric over the current day - Stack Overflow
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/
Prometheus doesn't provide the ability to query counter increase for the current day (e.g. since 00:00 of the current day). Prometheus provides the ability to query counter increase over the fixed lookbehind window (aka sliding window) though. For example, the following query returns the counter increase over the last 24 hours:
increase(ifen02[24h])
If you need counter increase since the beginning of the current day, then the following MetricsQL query can be used:
running_sum(
increase(ifen02)
if (
time()+timezone_offset("Europe/Kiev")
> (now() - now() % (24*3600))
)
)
It is expected that this query is used for building a graph on a time range covering the current day.
This query works in the following way:
It calculates the
increase()forifen02between adjacent points on the graph. VictoriaMetrics automatically convertsincrease(ifen02)into the equivalent ofincrease(ifen02[$__interval])). See increase docs and implicit query conversion docs.Then it calculates
time()+timezone_offset("Europe/Kiev") > (now() - now() % (24*3600)). This query returns unix timestamps inEurope/Kievtime zone for the current day. It drops all the timestamp for the previous days. See docs for the used functions: now(), timezone_offset() and time().Then the
ifoperator leaves the calculatedincrease()values only for the current day starting at 00:00 Europe/Kiev timezone, while dropping all the values for previous days. See docs aboutifoperator here.Then the remaining
increase()values are summed over the current day with running_sum function. Sometimes it is possible to use range_sum instead ofrunning_sum.
Why don't you simply use this?
sum(increase(ifen02[2h]))
And from the visualization tools (i.e. Grafana or Prometheus graph) select last 1 day or last 24 hr, it will show the data of last 1 day relative to current time.
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.