Thank you. >>*Alternatively, if the existing metric system already has extensive > historical data which you'd like to be able to query (for dashboards and > alerts) take a look at the remote read system.*
This is probably a silly question, but is it also true for remote write? I may use Prometheus-compatible remote storage VictoriaMetrics and it looks like it supports only the remote write. Le mar. 25 oct. 2022 à 20:21, Stuart Clark <[email protected]> a écrit : > If you are trying to interface with another metrics system the Push > Gateway isn't the right tool. The main use case for the Push Gateway is for > batch jobs that aren't able to be directly scraped, but still have useful > metrics. For systems which are constantly running you should instead look > at direct instrumentation or the use of exporters. > > Is this a custom metrics system, or something off the shelf and common? If > so, there might already be an exporter available. > > If you do need to make a custom exporter, I'd suggest looking at some of > the similar existing ones (for example the Cloudwatch exporter) to see how > they are made - but basically when a scrape request is received API calls > would be made to your other metrics system to fetch the latest values, > converted to Prometheus format (including the timestamp of that latest > value from the other metric system) and returned. Prometheus would > regularly scrape that exporter and add new values on a regular basis. > > Alternatively, if the existing metric system already has extensive > historical data which you'd like to be able to query (for dashboards and > alerts) take a look at the remote read system. With this option Prometheus > would use the remote system as an additional data source, running queries > as needed (based on the PromQL queries it receives), combining the data > with local information as needed. There are already remote read > integrations available for some data stores. > > On 25 October 2022 18:24:56 BST, Omar Khazamov <[email protected]> > wrote: >> >> Thanks, I'm importing metrics from our internal metrics system. Do you >> have any advice on how to push with the explicit timestamps? >> >> Le ven. 7 oct. 2022 à 13:30, Stuart Clark <[email protected]> a >> écrit : >> >>> On 07/10/2022 10:16, Omar Khazamov wrote: >>> >>> Hi Stuart, >>> >>> I can see that support of timestamps has been discontinued around >>> November 21st, 2021. Indeed, when I try >>> >>> C02G74F9Q6LR bat-datapipeline % echo "test_metric_with_timestamp 33 >>> 1665623039" | curl --data-binary @- https:// >>> <pushgatewayURL>/metrics/job/pushgateway-job >>> >>> I get *"pushed metrics are invalid or inconsistent with existing >>> metrics: pushed metrics must not have timestamps"* >>> >>> Could you please specify how do you use timestamps in metrics? Thanks >>> >>> As mentioned before timestamps in general should not be used. >>> >>> You should always be publishing the "latest" value of any metric when >>> Prometheus scrapes the endpoint (or the push gateway in this case). >>> >>> -- >>> Stuart Clark >>> >>> >> >> -- >> Thanks, >> Omar Khazamov >> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -- Thanks, Omar Khazamov -- 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/CAJs55iS%2B0jPORu9_HYHJrKEY9ppX9FyvffH4xe6Ahj1jM7mmZg%40mail.gmail.com.
