Allow to optionally specify timestamps

[lstrojny]

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]

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: #82. You can see it in action on libp2p/rust-libp2p#3325.

[lstrojny]

@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]

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

[lstrojny]

Good point, should indeed be enough

[lstrojny]

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]

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?