 All right, yeah, hi, I'm Matthias Loeber. I'm a Prometheus Thanos Prometheus operator maintainer. I work at Polar Signals. And today I want to talk about the open source project Pura, which aims to make SLOs manageable, accessible, and easy to use for everyone. So in the first place, why SLOs? They reduce your flakiness and alerts, and quantify overalls. So exactly, what are they? They quantify your services, reliability target, and you can make data-driven decisions about the reliability of your service. And I think can agree that that's something we want. So kind of like to formalize it a bit more, imagine an API website or something, and you want 99% of requests to succeed within five seconds, for example. And we measure that. And then on the flip side, when talking about SLOs, there's like the arrow budget. And the arrow budget is kind of the inverse of the objective that we are measuring. And for 90%, the arrow budget would be 10%. So on kind of always like 100% minus the objective is the arrow budget. So why Pura? Nadine Failing, UX designer at Grafana and I, we kind of like knew we needed to do something to make it better for users using Prometheus. And we kind of started out interviewing kind of a dozen SREs, different companies, to kind of really get an understanding for what is going on. And did a bunch of product research before even designing and even before doing any engineering work. In the end, we came up with this kind of UI. You can see all the SLOs with their name, different labels, kind of Prometheus style. You can label them. You can see the time window objective and then the actual availability and the actual arrow budget that's left on the service. You can also always see if there's an alert firing for any of the SLOs. You can filter by availability. Time window, for example, as well. And you can use the labels to filter, just like Prometheus or alert manager. You can filter SLOs as well. That's like a detailed page for the SLOs. So if you click on one, you get the name and then a better description. So other people on the team really understand what's going on. But also maybe people from the other teams. The current availability and arrow budget is shown and then a bit better understanding what the arrow budget looked like over time. You get a nice graph. You can drill it down into it as well. And then further down, we get like red as a graph. So a rate, arrows, duration. Duration, hopefully, one day. And at the bottom, you get the actual multi burn rate alerts kind of nicely shown. If there's some firing with the different severity, it's very clear how severe the incident is. It works with Prometheus, Thanos, and Cortex, or every other product that implements the query or query range APIs. You can deploy it on Kubernetes. It has a CRD. Or you can just use Docker or the binaries to generate the rules and alerts for Prometheus. So how do you create in SLO? Again, there's kind of a CRD. Get the namespace and name. You can get labels. Then you specify the time window for the duration of the SLO, the target. And then you can say, is it an error ratio thing you want to alert on, or the duration or latency? You give it an error metric. You give it the total metric. You can also do the same metric, different labels. You can filter into APIs, for example. And if you do that, kind of with the Rackex, you can also group by similar to some by Prometheus. And with one config, you get all the different SLOs by handler from one config. In the end, you get the Prometheus recording rules loaded into Prometheus, and just like that, also the allotting rules. Today, we released pure 0.4. You can find it on GitHub. If you want to learn more, go on these pages, read the books. I've been on the Big 10 podcast by Grafana, discussed with Björn SLOs. Thank you to the contributors. And Grafana and Polar Signals are always hiring. Thanks.