News for hackers. Stuff that matters.

A comment on Ingest OpenTelemetry metrics with Prometheus natively. Parent comment

Re:Ingest OpenTelemetry metrics with Prometheus natively by ranting-moth on Saturday July 29, 2023 @04:03AM (#36917993)
Does it still apply that if my Prometheus goes down or network glitches then metrics for that period is lost forever?
[ Parent | on HN ]
Re:Ingest OpenTelemetry metrics with Prometheus natively by gouthamve on Saturday July 29, 2023 @04:10AM (#36918028)
Unfortunately, yes. The OTel Collector has plans to implement a WAL for the OTLP exporter and when it does, you should be resilient to upstream temporarily having issues.
[ Parent | on HN ]
Re:Ingest OpenTelemetry metrics with Prometheus natively by SideburnsOfDoom on Saturday July 29, 2023 @05:49AM (#36918552)
WAL = Write-Ahead Logging ?
[ Parent | on HN ]
Re:Ingest OpenTelemetry metrics with Prometheus natively by gouthamve on Saturday July 29, 2023 @06:27AM (#36918740)
Yes sorry
[ Parent | on HN ]
Re:Ingest OpenTelemetry metrics with Prometheus natively by worserer on Saturday July 29, 2023 @04:37PM (#36924301)
It does today. You have a retry queue and you can use a persistent storage for it.
[ Parent | on HN ]
Re:Ingest OpenTelemetry metrics with Prometheus natively by ranting-moth on Sunday July 30, 2023 @01:52PM (#36933975)
How will that affect timestamps, won't all the metrics have the timestamp as the time when Prometheus finally receives them?
[ Parent | on HN ]
Re:Ingest OpenTelemetry metrics with Prometheus natively by kbouck on Saturday July 29, 2023 @01:53PM (#36922733)
What are the merits of the prometheus approach versus one where events/metrics and their original timestamps can be preserved, stored (during temporary outages), then forwarded to backends when connectivity is reestablished?
[ Parent | on HN ]