metrics-rs / metrics

A metrics ecosystem for Rust.
MIT License
1.13k stars 157 forks source link

is counter macro supports floating point values? #367

Closed dzmitry-lahoda closed 1 year ago

dzmitry-lahoda commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@tobz may you reconsdier you opinion?

dzmitry-lahoda commented 1 year ago

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 commented 1 year ago

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:

These hacks could be avoided either by:

tobz commented 1 year ago

@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 commented 1 year ago

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.