tikv / rust-prometheus

Prometheus instrumentation library for Rust applications
Apache License 2.0
1.07k stars 184 forks source link

Add ConstMetric to be used in custom collectors #94

Open kamalmarhubi opened 7 years ago

kamalmarhubi commented 7 years ago

Double check that this is the recommended approach in client_golang, but it is what they do for the ProcessCollector: https://github.com/prometheus/client_golang/blob/master/prometheus/process_collector.go#L125-L130

breezewish commented 5 years ago

https://github.com/prometheus/client_golang/blob/12af604cf208d3105ced825c65231b4ecf00a8cc/prometheus/process_collector.go#L170

phyber commented 5 years ago

Some of what a ConstMetric counter would be used for can probably be covered by https://github.com/pingcap/rust-prometheus/pull/261 now (eg. your exporter code could reset to 0, inc_by counter to intended value), but it's still a hack.

The use case I have in mind for ConstMetrics is where you have a counter in the OS itself and wish to expose it. Currently (well, before PR https://github.com/pingcap/rust-prometheus/pull/261), this involves some amount of overhead to track various numbers to work out what to inc_by the counter by. You could use a gauge instead so you could set it, but that is also a hack. Your TYPE text would no longer really describe how the value behaves.

ConstMetrics allow us to forget all about that by just exposing the number from the OS directly with no transformation or tracking required.

svenstaro commented 4 years ago

What's the current state on this? Are there any accepted workaround or such for enabling ConstMetric behavior in this library?

tim-seoss commented 4 years ago

When looking for this functionality in rust-promethues, ConstMetric seemed like a weird / non-obvious name. ConstMetric feels more like something like a Rust const value .e.g. to be used to expose the build-time value of env!("CARGO_PKG_VERSION_MAJOR").

I understand this bug report title follows the terminology of the Prometheus Go client library, but it feels like a bit of an awkward name there too, because (as I understand it), it's the result of an internal naming decision within that library?

Would something like UnmanagedMetric, ExternalMetric, ExternMetric, RawMetric etc. be a better choice in the context of this crate? (and just mention ConstMetric in the docs for those familiar with the Go client library)?

hdost commented 3 years ago

363 Could probably be closed as a duplicate.

Additionally I am curious @breeswish or any other maintainer. There does seem to be a magnetism towards the golang_client as a template. This makes sense in many cases, but I am curious there is some sort of standard which could be applied to determine the when to worry about being directly compliant. As mentioned by @tim-seoss above ConstMetric concept would be good to employ, but should naming of it diverge? Without some sort of clear direction it makes it sometimes difficult to contribute.