Counter overflowing and wraparound to zero, and Go 2

[jondot]

Hello,
Assuming counters wrap around silently (given a process with a good uptime and a good amount of counter increase), for current Go version - is that by design? and also - how would it fare with this possible change? golang/go#19624

Thanks,

[beorn7]

If you are referring to counters as metric type, Prometheus uses float64 for them, so they don't wrap around like ints do.

In general, it makes more sense to start discussions like this on the prometheus-developers mailing list rather than in a GitHub issue. On the mailing list, more people are available to take part, and the whole community can benefit from the results.

[bcmills]

The thing to watch out for with float64 counters is underflow rather than overflow. Underflow for float64 with integer increments starts at 1<<53.
(https://play.golang.org/p/fHOtTo30XN).

If you're running on a machine clocked at 3GHz and (generously) increment the counter by one at every cycle cycle, that gives an uptime of ~34¾ days until the counter freezes. In more realistic scenarios you're looking at an uptime on the order of years before it becomes a problem.

Of course, if you call Add with values larger than 1 you can end up dropping the smaller increments much sooner...

[matthiasr]

Is there a scenario where one would call the Prometheus client at around a billion times a second? The only places I have seen such fast-increasing counters is in hardware devices (CPUs, switches) and extracted at scrape time. And in this scenario floats are very good because they will support 128-bit integers and beyond naturally.

[matthiasr]

Actually, not beyond. TIL that the largest finite float64 is around 2^128.

[matthiasr]

Anyway, this is all very interesting but I don't think panics from wrapped integers will be a problem.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.