is counter macro supports floating point values?

[dzmitry-lahoda]

as i see openmetrics are u64 or f64 https://github.com/OpenObservability/OpenMetrics/issues/262 .

for me allow f64 in counter! and may be casting u128 to f64 behind scenes is good option to try to support fintech/crypto domains

[tobz]

No, it does not.

This is an intentional choice to ensure that counters are monotonically increasing, which would not be guaranteed if floating-point values were accepted, as negative values could be given, leading to the overall counter value decreasing.

If floating-point values are desired, gauges can be used instead, as helpers such as increment_gauge already exist for working with gauges in a similar way to counters.

[dzmitry-lahoda]

hm. gauge is awesome. will use. it is for tracking some long lived entity (in my case account).

but how to use gauge to track transfers? it may be huge amount gagues.

is any paper on itsq equivalence?

[dzmitry-lahoda]

@tobz may you reconsdier you opinion?

[dzmitry-lahoda]

https://stackoverflow.com/questions/58674087/why-there-are-both-counters-and-gauges-in-prometheus-if-gauges-can-act-as-counte

ok, seem I do not care. so imho also can https://github.com/hydrogen602/unsigned-f64

[tamasfe]

This is an intentional choice to ensure that counters are monotonically increasing, which would not be guaranteed if floating-point values were accepted, as negative values could be given, leading to the overall counter value decreasing.

If floating-point values are desired, gauges can be used instead, as helpers such as increment_gauge already exist for working with gauges in a similar way to counters.

Guaranteeing positive values at the type-level is nice, however using a gauge and pretending it's a counter is not ideal. Prometheus has builtin features to deal with counter resets that are not available for gauge metric types (e.g. you cannot use the rate() function).

So in order to record total request times, you'd have to either:

• use integers and a smaller unit, this technically works but goes against prometheus' conventions
• use something like deriv() on the gauge, but this won't account for resets

These hacks could be avoided either by:

• allowing to override metric type (even in just the exporter), this is hacky but could work
• allowing f64 counters, and clipping new values below 0 (or do nothing and leave negative values as a responsibility of the user)

[tobz]

@tamasfe It's unfortunate that our choice to constrain counters to u64 has suboptimal interactions with that aspect of Prometheus, but it's not something I'm ever going to change in metrics.

If people are primarily interacting with Prometheus, and want an experience that matches the Prometheus conventions more closely, both the prometheus and prometheus-client crates are suitable replacements for metrics.

[tamasfe]

We've just switched from prometheus to use metrics due to the convenient API and the architecture and philosophy that is similar to tracing. I was confident that this issue could be easily resolved or worked around as the most (only?) widely used exporter seems to target Prometheus.

that matches the Prometheus conventions more closely

It's not just Prometheus, OpenTelemetry also recently chose to recommend seconds as the unit of measurement for durations after a long debate.

but it's not something I'm ever going to change in metrics.

I'd be happy to submit a PR for it.