Counters should be monotonically increasing. A "reset" just means that the
exporter caused the counter to decrease for some reason (typically a
process restart).
If a counter goes 3 ... 7 ... 10 ... 2 ... 5 ... then you have no idea
what happened between the "10" and the "2". Therefore,
Got it. Thanks a lot.
BTW, can a reset happen on a metrics even if it's alive? If that's not the
case, then we may not have much issue as we handle all individual metrics
independently for increase calculation.
With regards
On Tue, Sep 1, 2020 at 7:42 PM Brian Candler wrote:
> On Tuesday, 1
On Tuesday, 1 September 2020 14:55:25 UTC+1, Manish G wrote:
>
> Going by (m1.2-m1.0)/(t2-t0) * 1h, even though m1 played out only for
> period t2-t0, we still multiply by 1h, and same for m3.
> So while increase() is expected to give absolute delta(m1.2-m1.0), it
> seems that's not the case.
>
Thanks for the detailed response.
Going by (m1.2-m1.0)/(t2-t0) * 1h, even though m1 played out only for
period t2-t0, we still multiply by 1h, and same for m3.
So while increase() is expected to give absolute delta(m1.2-m1.0), it seems
that's not the case.
Another concern: when we apply increase
On Tuesday, 1 September 2020 14:03:34 UTC+1, Manish G wrote:
>
> I have a query regarding working of increase function.
>
> Suppose for a query I get multiple metrics in return(a use-case can be
> like an application running in multiple pods in kubernetes, so multiple
> sources for same
5 matches
Mail list logo
