3 ms·

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

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.

stackskipton 2y ago
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?
- zacksiri 2y ago
  We're not throwing out Prometheus stack that's for sure. I've had experience using Elastic for a long time I understand it's capabilities and limitations, I'm familiar with it's querying capabilities, and things have always played out nicely with elastic for me. I guess it's all about what tools you are familiar with. If you are a paying customer and say you want prometheus metrics today we would show you how to access the already available LXD /metrics endpoint securely. You can learn more about this here https://documentation.ubuntu.com/lxd/en/latest/metrics/ https://documentation.ubuntu.com/lxd/en/latest/metrics/. With Opsmaru you get full access to the underlying LXD cluster by default out of the box. Ideally we would want to build an uplink version of the /metrics endpoint to ensure more smooth / automated / seamless integration but the above will work perfectly well if you want it today. The uplink /metrics endpoint would also provide additional metrics regarding application specific metrics not available from the LXD endpoint. LXD only provides infrastructural metrics not application metrics. In the future we want to integrate APM by default since we handle the routing for the apps we can bring together all these metrics like response times, SIEM and provide more metrics than infrastructural level metrics.

stackskipton 2y ago

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?

zacksiri 2y ago
We're not throwing out Prometheus stack that's for sure. I've had experience using Elastic for a long time I understand it's capabilities and limitations, I'm familiar with it's querying capabilities, and things have always played out nicely with elastic for me. I guess it's all about what tools you are familiar with. If you are a paying customer and say you want prometheus metrics today we would show you how to access the already available LXD /metrics endpoint securely. You can learn more about this here https://documentation.ubuntu.com/lxd/en/latest/metrics/ https://documentation.ubuntu.com/lxd/en/latest/metrics/. With Opsmaru you get full access to the underlying LXD cluster by default out of the box. Ideally we would want to build an uplink version of the /metrics endpoint to ensure more smooth / automated / seamless integration but the above will work perfectly well if you want it today. The uplink /metrics endpoint would also provide additional metrics regarding application specific metrics not available from the LXD endpoint. LXD only provides infrastructural metrics not application metrics. In the future we want to integrate APM by default since we handle the routing for the apps we can bring together all these metrics like response times, SIEM and provide more metrics than infrastructural level metrics.