metrics/counter: wrap values over 2^53#139
Conversation
This implements Prometheus reset semantics for counters, in order to preserve precision when deriving rate of increase. Wrapping is based on the fact that Prometheus models counters as `f64` (52-bits mantissa), thus integer values over 2^53 are not guaranteed to be correctly exposed. Signed-off-by: Luca Bruno <luca.bruno@coreos.com>
3c87461 to
a3df62a
Compare
|
@lucab nice! |
|
@olix0r late followup to this. Derived metrics are now precise but this is discarding the actual counter magnitude when the counter reaches ~8 Pebi-units. For comparison, Go Prometheus library tries to tackle this in a peculiar way, which is still going to loose precision at exposition time due to the Speaking with some other monitoring folks in the office today, it looks like it would make sense for the counter to store two values internally (current wrapping-integer and number of wraps), and serialize two metrics at exposition time (normal counter metric plus a |
|
@lucab That sounds reasonable, though I'm not sure if the storage overhead is worth it. Specifically, it would be unfortunate to have to export a |
|
No indeed. My bad, I didn't see histograms reuse this exposition path, let's leave it as is for the now then. This doesn't concern much the single-increments counters, but more the "quantity adding" ones (data-transfer counters and similar metering). |
This implements Prometheus reset semantics for counters, in order to
preserve precision when deriving rate of increase.
Wrapping is based on the fact that Prometheus models counters as
f64(52-bits mantissa), thus integer values over 2^53 are not guaranteed to
be correctly exposed.