Closed andrejs82git closed 1 year ago
prom-client doesn't currently support that. Some of the Prometheus core developers have advised that direct instrumentation libraries like prom-client should not support it, even (e.g. https://groups.google.com/g/prometheus-users/c/qv5i08bXmkM/m/H-hP0BwxBQAJ and https://github.com/prometheus/client_python/issues/588#issuecomment-709903365). Are you sure that you need it?
We removed the timestamp support in 41c9523cd8d046fa1392686cb9d62cc79988cc93. So unless the advice from upstream Prometheus project changes, we won't be adding it back.
prom-client doesn't currently support that. Some of the Prometheus core developers have advised that direct instrumentation libraries like prom-client should not support it, even (e.g. https://groups.google.com/g/prometheus-users/c/qv5i08bXmkM/m/H-hP0BwxBQAJ and prometheus/client_python#588 (comment)). Are you sure that you need it?
We need to proxy events from a source that has severe rate-limiting. For this reason, we query the events every 60 seconds, but we get lots of events to expose as Prometheus gauges. Without timestamps for each event, Prometheus does not show them in the correct order and with the correct duration between them. Instead, all events are stored by Prometheus at the scrape time.
How to handle this scenario? Official Prometheus documentation on exposition_formats suggests it would use the timestamp if provided after the gauge value:
http_requests_total{method="post",code="200"} 1027 1395066363000
@SimenB prometheus has Support for out of order samples in the TSDB. Why not adding it back. you can see it with link
https://docs.google.com/document/d/1Kppm7qL9C-BJB1j6yb6-9ObG3AbdZnFUBYPNNWwDBYM/edit?pli=1#heading=h.unv3m5m27vuc
https://github.com/siimon/prom-client/issues/177 was filed by a maintainer of prometheus - but that is a few years ago.
Maybe we can ask @jesusvazquez if we re-adding timestamp support helps with OOO samples?
Out of order is still disabled by default so adding it back would cause some friction because it would only work if the server has OOO enabled.
Since remote write was added to prom, people started sending samples with their own timestamps and thats a valid usecase.
I dont think that pull based instrumentation should allow setting an specific timestamp since its meant to be scraped every scrape interval and that is what sets the timestamp. I can be proven wrong on this statement, I just dont see why would I need it.
However if the idea is to send samples using remote write then you can specify any timestamp, it makes sense to be now() but i can also understand the client batching up writes before sending them all and in that case you'll have samples with different samples.
Thanks for the response! We do have a push gateway thing, but I think the main use case is poll based. Not sure if it makes sense to add something for the push gateway?
Hello everyone! We also want to use this library as a parser for metrics and upload them to prometheus. We collect metrics into a group and send them with timestamp every minute to reduce network load. There are metrics inside the group that are collected every second.
Hello all, I do not understand why this feature is removed. Adding a timestamp can be important.
The actual case I have is that I have a power meter which takes the consumption of the system every 0.1 seconds and exports it in a matrix of values with a rotating buffer of 5 seconds. I cannot poll at this speed but can push those data every 5 seconds... So adding back timestamps would be important.
Hi.
I have Gauge. And i add my metric with labels. And it working perfect.
But the code:
returning metrics without timestamp. And I do not understand how add timestamp in the end of line of metrics
I have:
But I need:
Thanks for your library!!!