Thanks for the response. I am new to time series data, so many of my questions may not make sense. What I am trying to do is to track cost. I know the price of an item in USD/hr (price includes CPU and memory usage so it varies with time). I was using Postgres, but it turns out that Grafana templates/variables did not seem to work well with that data source. I then turned to Prometheus.
It appears that you are saying is I should not worry about integrating rate, and just scrape the cost (price*dt). I assume you mean that the difference between the time I use to compute cost and the time recorded during the scrape is insignificant. One other thing is that I need to maintain 2 time series. One for monthly cost and the other for fiscal year cost. Basically I need to reset the cost at the beginning of the month and the fiscal year respectively to 0. So I believe I should be using a Gauge and not a Counter to record costs. On Thursday, September 9, 2021 at 1:44:32 AM UTC-7 Brian Candler wrote: > 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/0329d955-b5a6-4a59-8b20-4d69b5797395n%40googlegroups.com.
