 All right. It's time for the monitoring functional group update. My name is Ben Koche, I'm the lead team lead. I have Joshua Lambert, Jose, Mike and Tiago on the team. Just to remind everybody of what do we do? We deal with metrics, tracing and logging for continuous integration and operations deployment. We're a pretty small team where Tiago is new on the team, but he's only temporarily on the team. So we are still looking for several more back in Ruby engineers. We could really use some help with hiring. If you know anybody who is interested in monitoring and as Ruby on Rails back in developer, we'd love to hear from them. And Tiago will be helping us out. Big thanks to him for helping out on 10.8 and we'll be going through 11.1. What are we trying to improve? Well, of course, we're trying to improve on our hiring and to that we're going to be doing a little bit less in terms of what we're shipping for the next couple of releases, but there's still gonna be some cool stuff and coming down the pipe. In 10.8, we got some cool stuff. We now have the pod name. So if you are using the CD pipeline, you can now see the name of the pod displayed in the list. And that'll be helpful for later. Other features, some minor bug fixes and some cool stuff coming. We finally are going to be turning on the Prometheus Ruby metrics in the Unicorn and Sidekick. This will be great because now administrators won't have to deal with any of the, won't have to actually turn that on by default and we'll be able to start adding some cool new features in 11.0. In 11.0, we're gonna be finally shipping the SLO alerting. This will allow you to create and send alerts to administrators of projects. By default, we're gonna be working on building this thing called a webhook and this will allow the owner of a project or the managers of project to get alerts in their email through GitLab itself because GitLab knows the developers or it knows the manager's email addresses in the project. It can actually send out email through the normal notification just like a normal merge request or issue notification. And that'll be super, super fun for project owners to be able to get alerts directly through GitLab. We're also going to start shipping the ability to see pod logs. Oh, sorry, this is wrong slide title. We have a few more other cool minor features. We're gonna be shipping the Prometheus 2.0 version instead of the original Prometheus 1.0 version as part of GitLab 11. This is a interesting and difficult change because the storage format for Prometheus 2.0 changed and there is going to be a manual upgrade process and thanks to you those folks on the Prometheus team for helping us build a storage migration tool that should for users that want to be able to upgrade their data. If you're not using Prometheus or you don't really care, you can just upgrade quickly and it will just reset the data to empty. In 11.0, we're also going to be shipping the operation sidebar or there's some general changes to the operation or to the sidebar and Kubernetes and environments are going to be moving to their own operations tab and Prometheus will be joining and other monitoring features will be joining that operations tab. Also coming soon to Prometheus in gitlab.com production is a sub project of the Prometheus team's efforts is a really cool new tool called Thanos. And so one of the interesting things with Prometheus is we designed it to be very simple and easy to deploy but growing to a very large scale can be a challenge. And so Thanos is an overlay layer that goes on top of if you have multiple Prometheus servers in your production environment, Thanos is a really great overlay tool that links all your Prometheus servers together and allows you a single query interface and it also has a bunch of other nice features including long-term storage, down-sampling and just really great way of like storing or building a really high scalability Prometheus setup for your production clusters. And that's basically it on the summary. Let's go to questions. For alerts there, will there be a API web service available? Yes, that's exactly how we're doing it. We're building a Prometheus webhook API into GitLab itself. So that the Prometheus alert manager will be able to send messages directly to GitLab if that answers the question. I guess I'm curious if that will be externally available like a developer connected into a pager duty or something like that. So the alert manager can connect, the alert manager itself can connect directly to pager duty. So the Prometheus alert manager supports a number of external messaging systems including email and pager duty and other VictorOps I think, OpsGenie but we have a generic thing called that just is a webhook interface and we're gonna build a Prometheus native webhook interface into the GitLab API service. I didn't pick the name Thanos. That came from the developers at improbable. I believe the story there is that Thanos is the infinite Prometheus is that it comes from the mythology of being the the infinite Prometheus. But I don't know the whole story there. How do the reboot metrics compared to the APM solutions like New Relic? So the Prometheus metrics library is just a metrics library. It doesn't send you exemplar and other like sampling information but we basically took the available data that we were using with InfluxDB and turned those into Prometheus metrics so that we get histogram data on and other useful information about like how long it took like histograms of the time it took to process things in Ruby, how long it took to do database requests that kind of thing. Does that answer your question, Patrick? Any other questions?