search

prometheus / client_rust

Prometheus / OpenMetrics client library in Rust
Apache License 2.0
484 stars 80 forks source link

Allow to optionally specify timestamps #126

Open lstrojny opened 1 year ago

lstrojny commented 1 year ago

It would be terrific to be able to pass an optional chrono instance as a timestamp to specify the recency of the particular metric. My usecase is a prometheus exporter where the metrics are cached and it would therefore be correct to specify the time of the original retrieval of the metric instead of leaving out the timestamp which implicitly states "now".

mxinden commented 1 year ago

Very much in favor of this. What do you think of adding this to the new ConstCounter and ConstGauge for now as neither of them would require synchronization and likely fits your use-case in an exporter? Contributions very welcome @lstrojny.

As an aside, as a developer of an exporter, I would greatly appreciate input on the new Collector trait: https://github.com/prometheus/client_rust/pull/82. You can see it in action on https://github.com/libp2p/rust-libp2p/pull/3325.

lstrojny commented 1 year ago

@mxinden adding it to Const* initially sounds good. I guess you would want to feature flag chrono support? I can try my luck with an implementation although be warned, I am doing more serious Rust for a week or so.

Will have a look at a custom collector trait but very likely only in a couple of days. From a short glimpse it could potentially change how I am driving metrics generation in my exporter.

mxinden commented 1 year ago

Why is chrono needed? Given that we need unix timestamps only, wouldn't Instant and UNIX_EPOCH be enough?

lstrojny commented 1 year ago

Good point, should indeed be enough

lstrojny commented 1 year ago

One important note here: Prometheus requires millisecond timestamps while the OpenMetrics spec uses seconds. Since this is a Prometheus client not an OpenMetrics client it seems to be sensible to go with milliseconds but I wanted to bring it up.

mxinden commented 1 year ago

One important note here: Prometheus requires millisecond timestamps while the OpenMetrics spec uses seconds. Since this is a Prometheus client not an OpenMetrics client it seems to be sensible to go with milliseconds but I wanted to bring it up.

My understanding is that the old Prometheus format expects ms, while newer versions of Prometheus will parse the timestamps as s when the content type is set to application/openmetrics-text; version=1.0.0; charset=utf-8.

@lstrojny can you confirm that this is / is not the case?