Thank you for your feedback, you have a valid point about the /metrics endpoint. We're planning on providing a /metrics endpoint in the future. I mentioned this previously as well in another reply.
This isn't a custom system at all we're simply removing the need to install / configure / manage another external package by implementing a data shipper into uplink using elixir broadway. The end goal is still that Ops / SREs can still use their existing favorite monitoring pipeline whether that's Grafana / Prometheus / Loki or Elastic / OpenSearch stack. There are several advantages, it means less things to install / maintain / patch / secure as mentioned in the post. We believe doings things this way leads to a more robust / secure system in the long term.
As for the 15 seconds scrapes we can tune that and provide that as an option for customers as well. These are things we can improve and provide to our customers as options. For now for MVP we're shipping data to the elastic stack certain decisions are made to help simplify and reduce the amount of things we have to do to get the product to an MVP.
We can provide the /metrics endpoint in the future, it's just a matter of time and priorities.
There are reasons why we're shipping data into elastic that will be clearer once things mature a little more. There are things Elastic can do that we need at a base level for our internal product plans, there will be a follow up post about this later.
Will provide more blog post articles giving you more details as to the decisions we've made and why we made them. Always happy to read feedback.
I await the blog article. I just think throwing out Prometheus Stack was terrible idea. If you want to store Metrics in Elastic, which I've done and always ends in tears, is fine. My concern is not keeping Prometheus compatible until last second.
If I'm a customer and say "Hey, my applications are emitting Prometheus Metrics, how to scrape?" what is your recommendation with the platform?