Hi developers, We recently launched Google Cloud’s Prometheus metric backend based on Monarch. We encountered some obstacles regarding the remote APIs, which we believe to be common for backends that were not built for Prometheus bottom-up.
A central issue is that the remote APIs expose the Prometheus storage data model. It is notably different from the Prometheus/OpenMetrics instrumentation model and discards most of the structure known at scrape time. Structured data is critical to store and query data more effectively and translate it to different underlying storage data models. With the current API however the structure is very challenging and sometimes impossible to restore. We're also interested in potential new features, like first-class support for HA deduplication and write atomicity. We’d like to explore evolving the remote APIs so that interoperability and compliance become more practically attainable for independently developed backends. But there should be substantial opportunities for backends that largely reuse Prometheus code as well. If I recall correctly from years ago, the current remote API was always meant as a starting point, rather than the final solution. Is now a good time to revisit its fundamentals? Are there any recent discussions in this area to read up on and participate in? Thanks, Fabian -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" 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-developers/CAG97UEngEdrkrcGnH5J%2BRQ4ThT8GW530JcLOgdJ2Jf13A_RAjA%40mail.gmail.com.
