Only custom collectors should be able to expose timestamps

[brian-brazil]

https://github.com/siimon/prom-client#timestamps indicates that direct instrumentation can specify timestamps, and other code indicates that a /metrics will always have timestamps.

This makes no sense semantically, and breaks ingestion, timestamps, and staleness on the Prometheus end. All ability to set timestamps with direct instrumentation should be removed, and there should be no timestamps on /metrics in normal circumstances.

[brian-brazil]

It looks like this client does not support custom collectors as it doesn't support collectors (it's all metric based), so as it stands there's no need for any timestamp-related functionality.

[SimenB]

Oh, I didn't know that!

What's the role of collectors? Is it something we should support?

[brian-brazil]

This is a bug report, this issue is actively causing problems.

What's the role of collectors? Is it something we should support?

They're mainly needed for writing exporters, though they can also come up in applications sometimes. It's up to you if you want to support them.

[SimenB]

What issues is it causing? It's possible to strip the timestamp from the textual representation (see https://github.com/siimon/prom-client#register)

Not to say I'm against removing them, but "actively causing problems" should at least be possible to work around until we remove it.

[brian-brazil]

It's causing duplicate timestamp errors at the least. It's also going to be causing quite a few problems when trying to use affected metrics via PromQL due to staleness handling.

[SimenB]

#333