Added support to set an externally available timestamp to the metrics

[cwiechmann]

@brian-brazil

I see this requirement has been discussed since a while and you wrote some time ago you would be happy to accept a PR to make it possible to take over already available timestamp information.

Some background about my use-case:
I can't instrument the code of an application directly as I don't own it, but the application provides me regular Metric-Information including a timestamp. The metric data is streamed to my Custom-Exporter almost in realtime, but there might be slight delays between the original event and when it is finally received by Prometheus.
That's the reason, why I would prefer to take over the given timestamp information into the exposed Metrics for Prometheus.

[brian-brazil]

Timestamps for direct instrumentation don't make sense, you want to use a custom collector which already support them.

[cwiechmann]

Thanks @brian-brazil for the feedback.
When you say, I need to use a Custom-Collector, do you mean by that more or less the same thing as Counter, Gauge, Histogram, etc?
If yes, that would mean I need to re-implement exactly the same Collectors (duplicate the code) as the ones already existing just to make it possible to set existing timestamp. FYI: Before I created this PR, I already tried to overload the existing collectors, but that's not possible, as some of the fields are private.
If not, can you please give me a hint?

Thanks!

[brian-brazil]

If yes, that would mean I need to re-implement exactly the same Collectors (duplicate the code) as the ones already existing just to make it possible to set existing timestamp.

When you're writing an exporter to consume push-based information, that's pretty normal.

[cwiechmann]

Okay and understood.
However, I don’t get my head around to duplicate so much code just for that.

So, would you be okay to make it possible to overload the existing collectors?
I mean, I would create my own collectors based on the existing ones, which I will change hopefully slightly. For these changes I will create a new PR and let you know.

Just let me know and you may close this PR.

[brian-brazil]

Being able to subclass these classes is not something I want to support, as that's not sane generally.

[cwiechmann]

Hmm, I'm not fully sure, why it should harm to make the Client-Library a bit more flexible in one or the other way, as long as the standard use-cases are fully supported.
But you own it and you make the rules - So I'm going to close this PR. Thanks for your swift responses, much appreciated.