Something you could investigate is that the exposition format <https://prometheus.io/docs/instrumenting/exposition_formats/> in principle allows you to provide your own timestamps for your metrics. However I don't know if current versions of prometheus honour this at all, or just throw it away and use the scrape time.
However, I don't really understand what's going on with your metric, and it sounds to me like this might be an X-Y problem. In general, exporters don't "post" metrics, they are "scraped", and this scraping can take place by multiple clients concurrently. For example, in a HA setup you may scrape the same exporter by multiple prometheus servers; or you might spin up a test prometheus server which scrapes from the same exporters as your live server. Therefore the "prometheus timestamp associated with m" doesn't really make much sense, except in terms of the time when the value was actually scraped by a particular server. If the problem is that you want to turn a rate gauge into a counter (why?), then it's possible in a recording rule, but the results may not be satisfactory. You're only collecting samples of the rate at particular instants in time, so integrating over it is likely to lead to error accumulation. If you know that your gauge is reporting "rate over the last 15 seconds", and you're scraping at 15 second intervals, it may be good enough. But it would be much better to change the exporter into a native counter. On Wednesday, 8 September 2021 at 23:01:51 UTC+1 [email protected] wrote: > Also one other idea is to do a 2 phase commit. First create a time history > record with some default value, and then use the resulting timestamp to > update the value. > > On Wednesday, September 8, 2021 at 2:18:34 PM UTC-7 Conrad Mukai wrote: > >> I want to track a metric that depends on the Prometheus timestamp. I know >> the rate of change for the metric, but not the metric value. For example, >> suppose I have the following metric m: >> >> m = k * (t1 - t0) >> >> where t1 is the Prometheus timestamp associated with m, and t0 is the >> timestamp of the previous value of the metric. k is a constant that I know >> prior to pushing the metric to Prometheus. >> >> Is it possible to post a metric that can be computed based on timestamp? >> An alternative would be to predetermine the timestamp and require that >> Prometheus use it when recording the metric. Any suggestions? >> >> Thanks in advance. >> >> -- You received this message because you are subscribed to the Google Groups "Prometheus Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/0ca37d85-73db-402f-bf93-dad1d65b9b58n%40googlegroups.com.
