|
|
|
|
|
|
by cip01
1545 days ago
|
|
|
Which restrictions do you have in mind? Quick look at the issue looks like it wanted to avoid using local storage by Prometheus, but that’s Prometheus specific problem, not remote-read problem. Remote-read is a generic protocol (https://github.com/prometheus/prometheus/blob/a1121efc18ba15...), you pass query (start/end time and matchers), and get back data. |
|
|
You wrote in the previous comment:
> ... so external systems (eg Prometheus) can read data from them easily.
I pointed to an issue, which prevents from practical usage of remote read protocol from Prometheus itself.
As for the interoperability with external systems, Prometheus querying API [1] is better suited for this task than Prometheus remote read protocol because of the following reasons:
- Prometheus querying API is easy to use, since it is just JSON over HTTP (unlike compressed protobuf used for Prometheus remote read). E.g. humans can test and debug it either directly in web-browser or in a command-line shell with curl.
- Prometheus querying API is already supported by popular external systems such as Grafana.
- Many Prometheus-compatible systems such as Thanos, Cortex, M3, VictoriaMetrics, etc. support Prometheus querying API out of the box.
[1] https://prometheus.io/docs/prometheus/latest/querying/api/