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. On Monday, April 3, 2023 at 12:12:35 PM UTC-4 Brian Candler wrote: > 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) > > On Monday, 3 April 2023 at 15:14:49 UTC+1 Johny wrote: > >> 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 >> >> -- 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-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/2738d214-ba42-42ca-b876-cf9578884289n%40googlegroups.com.
