Prometheus ingestion into other monitoring solutions - Invitation to comment

[Javier Kohen (via Google Docs)]

Javier Kohen has invited you to comment on the following document:

Prometheus ingestion into other monitoring solutions

The goal of this proposal is to enable ingestion of data passing through the Prometheus server into other monitoring solutions via supported API, with no code changes (that is, once the proposal is implemented).

Why not use the remote storage API? Some monitoring solutions require metadata at ingestion time; the metadata is available in the Prometheus client, but the Prometheus server doesn't propagate it beyond the scrape phase, and therefore not available to the remote storage API. The remote storage API is also not intended for the gapless low-latency ingestion use case: it drops data if the backend is down or cannot keep up with the load; it's reported to have high propagation delay; and histogram samples can be split across different requests, while some monitoring systems require atomic value writes and don't support updates.

The high-level architecture of using a metric descriptor database and tracking the write-ahead log (WAL) was initially suggested by Brian Brazil, Fabian Reinartz, and Julius Volz.

Open in Docs

Google Docs: Create and edit documents online. Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA You have received this email because someone shared a document with you from Google Docs.

[Javier Kohen]

Thanks Brian and Julius for all your comments. I've incorporated all your feedback, mainly: MDDB is in-memory only; WAL is read from files with a library in prometheus/tsdb; CRUD API doesn't include a watch operation.

What is the next step of approval so I can start working on this with some confidence?

[Brian Brazil]

On 19 April 2018 at 22:44, Javier Kohen <jko...@google.com> wrote:

Thanks Brian and Julius for all your comments. I've incorporated all your feedback, mainly: MDDB is in-memory only; WAL is read from files with a library in prometheus/tsdb; CRUD API doesn't include a watch operation.

What is the next step of approval so I can start working on this with some confidence?

We seem to largely have consensus, so that's it.

Brian

On Thu, Apr 5, 2018 at 2:25 PM Javier Kohen (via Google Docs) <jko...@google.com> wrote:

Javier Kohen has invited you to comment on the following document:

Prometheus ingestion into other monitoring solutions

The goal of this proposal is to enable ingestion of data passing through the Prometheus server into other monitoring solutions via supported API, with no code changes (that is, once the proposal is implemented).

Why not use the remote storage API? Some monitoring solutions require metadata at ingestion time; the metadata is available in the Prometheus client, but the Prometheus server doesn't propagate it beyond the scrape phase, and therefore not available to the remote storage API. The remote storage API is also not intended for the gapless low-latency ingestion use case: it drops data if the backend is down or cannot keep up with the load; it's reported to have high propagation delay; and histogram samples can be split across different requests, while some monitoring systems require atomic value writes and don't support updates.

The high-level architecture of using a metric descriptor database and tracking the write-ahead log (WAL) was initially suggested by Brian Brazil, Fabian Reinartz, and Julius Volz.

Open in Docs

Google Docs: Create and edit documents online. Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA You have received this email because someone shared a document with you from Google Docs.

--

Brian Brazil

www.robustperception.io