Open link2xt opened 5 months ago
without conveting it to u64
Note that gauge::Atomic
is also not implemented for u64
, but only i64
. This is due to the OpenMetrics Protobuf definition requiring a value to be either i64
or f64
, not u64
:
In other words, say that you provide a u64::MAX
to Gauge::set
, what should prometheus-client
do? It can't store it in an i64
. It can't store it in an f64
without loss.
Does that make sense?
In other words, say that you provide a
u64::MAX
toGauge::set
, what shouldprometheus-client
do? It can't store it in ani64
. It can't store it in anf64
without loss.
If it is encoded in text format, just write it out as text. There are no such restrictions in text format, any integer can be encoded there even if it does not fit 128 bits. If it is not supported by the receiver, it is the receiver problem.
If it is encoded in protobuf, also does not matter, could be not encoded or encoded as i64::MAX
then.
Currently in the application I have to do this:
metrics.heartbeat_token_count.set(tokens.len() as i64);
Metrics are then exported as text. This as i64
should not be necessary for a gauge that tracks some structure size and is then encoded into text.
I want to store
usize
in a gauge metric without conveting it to u64, butAtomic
trait is not implemented forusize
: https://docs.rs/prometheus-client/0.22.2/prometheus_client/metrics/gauge/trait.Atomic.htmlBecause of this
Gauge::<usize, AtomicUsize>::default()
. Is there any reason for not supporting it? Would it require too high MSRV?