 Welcome to the first Prometheus team functional update. Prometheus team, who are we? My name is Ben Kochi, I'm the Prometheus lead. Joshua Lambert is our product manager. Kevin Leida and Julius Volts are two part-time engineers that we have on the team. And so I was going to start out with what's Prometheus. Prometheus is an open source monitoring system. And we already use it at GitLab to handle metrics and alerting. But the real strength of Prometheus is it's a monitoring system for dynamic microservice style systems. And in addition to, you know, more traditional service styles. So it's an extremely flexible monitoring system. It combines a little bit of the kind of alerting that you would get from, say, an old school monitoring system like Nagios. And also the modern data analysis that you get from something like Graphite. It's been an open source for about four years. And we have been a part of the Cloud Native Computing Foundation fairly recently. So we're very well connected with projects like Kubernetes. And unlike a lot of other monitoring projects out there, Prometheus is totally open source project. There's no commercial interest from any one particular company. We're extremely collaborative in the open source community. So why is GitLab using Prometheus? Well, one, it's fully open source. Two, compared to a lot of other monitoring systems that are coming out, it's actually quite a boring solution. It's a simple single binary server that monitors everything. There's no discharging. There's no, there's no required sharding. There's no distributed systems. You run the one binary, it's up and running, and you can immediately start building your monitoring based on that. It uses a very simple HTTP communication protocol. Prometheus just uses Git in the metrics format as text base. You can generate metrics from any programming language from Bash to Scala to Java to Ruby to anything. We have direct integration with many programming languages and many existing applications. So it's really easy to implement new monitoring in your applications that people haven't been able to do before. It also scales well, both small size and large projects. So I can install Prometheus on a Raspberry Pi or I can run it on a giant server and monitor millions of things. So Prometheus team, what are we doing? So the goal here is to provide a software as a service monitoring within a GitLab installation. So you install GitLab, it comes with Prometheus server, and that Prometheus server allows you to get automatic alerts and metrics from all the applications that you deploy with the GitLab CI pipeline. So that everything you get from GitLab is monitored in production and you're testing. And this will allow GitLab customers to get really good visibility into the performance of their applications and alerting to let them know when their applications are not working. In line with this, we're actually using Prometheus as well. In addition to the customer monitoring, we're also using it to monitor GitLab installations themselves and GitLab.com. So we also are going to be working to improve the performance of GitLab installations themselves. Plus, the fun goal of Prometheus is to make it really useful for everybody, which will hopefully drive more people to adopt GitLab. In 816, we included a very basic Prometheus package with the NodeExporter. The NodeExporter is a small piece of software that allows Prometheus to record and get metrics from the base OS installation. And this provides some initial system metrics so that you can know whether the CPU is overloaded or if the file system is full. Very basic stuff. 817 was just released. We added some more instrumentation endpoints for GitLab Monitor, which is some basic metrics about GitLab, the GitLab running instance, Postgres Explorer, which gives you database metrics and the Redis Explorer for the Redis cache. And this is something we're going to be expanding on over the next number of releases. So in 9.0, what we wanted to do is we wanted to deliver a real customer monitoring experience. So when you get your app and you use the CI and you deploy your app, you'll be able to get instant feedback from GitLab that your app is actually running and performing the way you'd expect it to. This will be fairly basic, but very important things like CPU metrics for the running applications. The target platform here is Kubernetes because Kubernetes provides the metrics in a very simple, because Kubernetes is a container system, it already has all the structure to provide the application-specific metrics and makes it very easy to integrate. And this is kind of the vision for the future is Kubernetes will be the first-class way to deploy applications with GitLab. Getting started, we're working on the UI discoverability so that it's easy to configure Prometheus within each project. And then once you have that configured, you'll get some nice simple graphs that contain basic information about the running application. 9.1, we have some new things that we want to do, support for additional user-defined Prometheus metrics. So say you have an application that you've built and you've added Prometheus metrics to that application, you'll be able to put that in and get Prometheus to record that for you and provide that. And then we're also going to be launching more significantly more detailed internal metrics from GitLab's Unicorn server or Ruby-run Rails system. Currently, that data is not in a Prometheus format, so we're going to be developing extensions to the Prometheus client library for Ruby so that we can get really good data from a running GitLab installation. 9.2, further on, will be automatically deploying individual Prometheus servers to monitor each application separately so that... Or is that... Maybe I'm wrong about that. But we'll be improving the deployment of Prometheus on Kubernetes so that you can get more detailed statistics. And lastly, Prometheus team is hiring. We have an open rec for Prometheus engineer. We're actually don't need somebody who's already an expert in Prometheus. We're just looking for good go and or Ruby backend developers who really want to understand and who enjoy working on performance instrumentation style work. So, familiar with monitoring as a plus, but we're not looking for specifically Prometheus expertise here. And until then, we really could use a little more help with the backend work because we don't have somebody on board to do a lot of the backend work right now. So, that's it.