 All right. Well, thanks first of all for being so dedicated to TubeCon. It's 5.30 on a beautiful day. And you're here and not at the bars. So thank you so much. I also want to say thank you to Oleg. He was supposed to give this talk, but unfortunately he had to travel and leave early. So I'll do my best to give him justice. But the great slides that you see are actually from him. So if you ever see Oleg Nanchev, then give him some kudos. Talk today. Thank you, Captain Obvious, making observability actionable with Prometheus and Captain. Obviously, I try to make it obvious. I really like Captain. My name is Andy Grapper. I work for Nanchev during the day, but I'm also a captain maintainer and a contributor. And I really like to show you what we are doing with Captain. If you think Captain, if you've heard about Captain, you think Captain is yet another CICD tool. And it's a, if this stands with this tool, then hopefully I prove you wrong because I want to give you a little different perspective on Captain. Captain has also changed over the last couple of years. But if you want to get shirts or hats, we all have a booth at the pavilion. So check us out tomorrow. But let me first get into my talk. I talk about observability, making observability actionable. And when I talk about and think about observability, I think about SREs. SREs are using observability data to keep systems reliable and resilient. But you may say, well, one doesn't simply do a SRE. Well, I counter. I think actually Captain makes it pretty simple. This is a post from Tarash. He is a performance engineer at Facebook. And when he saw that Captain two years ago, when we were still in the early stages, you already saw, we are trying to bring the SRE core principles to the cloud-mated community, letting observability that you pull out from Prometheus or any other observability frame that she had, using this to drive those actions that actually keep the system reliable. So first of all, let me get started on what problem we really want to solve. We all know that modern cloud-mated systems are no longer simple. You have a lot of different tools and you need to connect them in one way or the other, which means you have to build a lot of point-to-point integrations and try to put in also your possibility to make better decisions. I'm pretty sure some of these tools are familiar. The question is, how can you make better informed decisions if you don't have visibility? Well, fortunately, we always talk a lot about observability in this conference. I also want to give a shout-out to Henry, in case you have not seen his phenomenal YouTube channel. It's called Isn't Observable? Check it out. He is looking at new frameworks in the space all the time, and it gives his perspective. He also creates tutorials, so check it out. The point is, observability is a must, because if we don't have observability, we cannot make good decisions. We don't even know if a system is broken. The problem is that observability is not easy if you know that you have a big landscape of tools and you don't really know how you actually get data out of this. Well, fortunately, again, we have movements where we are trying to figure out how to standardize open observability. I don't need to remind you about some of these great products or frameworks and projects here that are really trying to make it easier for us to get insights. Prometheus is one of them, right? I think we don't. And again, if you like these slides, all that is the one to put them together. I really like it, right? Sauron's eye, Prometheus' eye, we give you all the visibility and what happens in your environment. What we want to bring to the table, if you have data, then we as captain make it actionable. If you have a desired state based on the data that a system should be helping, should be up and running, it should be performing in a certain way, we can act on this data to always keep the system in that state that you expect from your system-based observability data. So in other words, captain is an observability-driven orchestration engine for your cloud-native apps. What this means is, again, another cool slide from Oleg, one platform to orchestrate them all. I hope I have some of the ring fans in here at least. Captain has been around for a while. We are a CNC at Sandbox project right now, very close to getting to reaching intubation. What's really important is that orchestration and observability-driven orchestration is at the core. And what this means is, if I come back to the slide that I had earlier, the click-off works as expected. Somebody needs to observe the signal here. There we go. One option that you have, and you can build orchestration yourself, you can connect all of these tools, but what we try to do is, I just click here, instead of you having to connect all of these tools and making decisions on what to do next, captain's control plane reaches out to your observability platform and based on how the state of your system is, they call the right tools to actually bring the system back to its healthy state. So, at the core of captain, we have SLO, Service Level Objectives. You define the desired state of what your system, you expect your system to be, and then we orchestrate the tool to bring the system always back to the desired state. Captain has a really cool REST API. We are standardizing on cloud events, and we are in the CDF events spec, and I see amount of time. What I would like you to know is, if you have an app, it's instrumented with open telemetry, you get some data, we can act on it to bring the system always back to its desired state based on your observability. Captain is extensible. There's a lot of stuff that we have out here. Check out Nana's video. If you know Nana, she did a video on captain. Learn more about Captain at Q-Con, which means please meet us at the pavilion. I am there and some others tomorrow, Thursday and Friday. Thank you.