[MUSIC] Now, let's try a couple of jobs to see how this looks in action, and I'm going to go back to our repositories. And we're going to take a look at some builds here. I'm going to make some changes to the README file, just for starters. And this is actually going to be done on a branch, so I'm going to choose a branch. We'll call this test_branch_1. And we'll create the new branch there, and then, I'm going to edit that, and we're just adding a test message, test message 1, don't merge. So I'm going to commit that on our branch. This is just going to build successfully for us. So we go back, we have a test_branch_1, and I'm going to compare and make sure that I choose my local repository. I'm also going to choose the herouku_production branch, so that I actually get a build for our service. Okay, we're going to create the port request, and that'll start a build, yep. And if we go back and look in our web app. We aren't receiving other events, I believe. Let's see, this is a little different. We're not processing this event, so there's not much information here. But we are receiving the event. So this is a check run created, which means that a new build started. However, we're not doing anything with that. We're just letting that pull through. So that's going to take a few seconds here. We're going to do another one, as well. So I'm going to do one more. So we can see more than, more action in so test_branch_2, we'll create another test branch. And this time, I'm going to edit the README again, and put a slightly different message Testing and create a commit for that. And then, we'll make another pull request here, And make sure that we choose our repository, and work with production branches again, and that's going to create a second build. Now, you can probably get pretty creative here, and also, start capturing some metrics for when you create a build, and you can track that with a different actual permethrins metric, and visualize the start times, as well. So in Grafana, Grafana is going to continue collecting our metrics from the Prometheus server, and any kind of new data that is going to show up here as soon as it's visible to Prometheus and Graphonic, can actually track it. Now, we're going to wait a few seconds here. I'm going to pause the video, and we're going to wait for these particular builds to finish, and allows us to look at them in. Okay, so the builds are done, and we can see two successes there. Now, if we go back to Grafana, and we refresh there, we'll see, yes, now, we have two builds. One took a little bit longer than the other one. So you could usually see that this build succeeded, and it took a little bit over three minutes. And then, the other build took a little less time, almost two minutes, and two point thirty three. And we can also see our built success now climbing, and our percentage failure declining, as well. So you can see how having this kind of statistics over time can help you make decisions about whether the quality of the code is heading in the right direction for lots of bills, and their passing green, or whether is you need to go do something like correct some bills, now, remember that fill bill that we had if we go back to report rescues this. Adding prom-client, if we go look at the failed build, and look at our checks, we actually deployed this app, which is a big no no, usually, without fixing the failed build. And lucky for us things worked, but there was some side effects. And I'm going to show you that in a second. So the first is, if we go to Travis, we'll notice that, hey, our linter actually caught that there was some issues with some events, so that might not be our failure. It doesn't look like it is, it's just a warning. But then, the real problem here, is that we had some issues with collect default metrics that was assigned but never used. And that can probably lead to some problems for us. So I actually found out that this was a problem with our documentation, so I made a fix to our documentation in the instructions. Let me just pull that up. And that was over here, and I had actually missed one small step here, which is to add a collect default metrics section every fifth second. So this would've given us some additional details, which as a side effect, it wasn't giving us every possible detail that we could've been seeing. We were only getting the Travis metrics. But there was actually a way that we could've collected even more metrics, by just adding these few lines of code. So if we went back to our index.js file on our Probot app, and we added that right after line 15, and we do File > Save on that, and then, we go back to our desktop, and we commit those changes. Missing NodeJS metrics, And we push that up. And then, I'm just going to redeploy the application, so we can see it faster. So let's go find, git push from. That's going to deploy, so give that a second. Okay, that's finished deploying, so now, if we go back to our web browser, and we refreshed the metrics end point for our Probot application. We'll notice that, wow, there is a whole lot of extra metrics here that are being captured. And that's available to us to graph against as well in the Prometheus and back end. So if we give Prometheus a few minutes here to collect some data, you will see it has a whole bunch of extra Node.js data that might be useful for us to troubleshoot. Things like memory exhaustion issues with our Node.js app. More process utilization issues, maybe, we'll have one of those threads that runs out of control, or we might have some other issues here. But this is really good information for us to now put in the Grafana. Grafana also has some alerting. If you play with the Alerting, you can use it to help you kind of create a page, mechanism, or an alert system for yourself. So that, for example, if we had a down take on up time, we might alert ourselves that our Probot app isn't working. Incorrectly, all right, so what did we do today? We built a new metrics gathering system, with Prometheus. We used the checks API system within Travis to notify our provide app about changes in builds, and to detect build failures, and build direction, build success rates. And then, we translate it that to Prometheus scraper, which then could be pulled by Prometheus, and then, visualized with Grafana. This was a little bit more complex exercise than the previous exercises. So do take some time to go back, and look at the exercise, and especially, the coding copy-paste parts, so if you have any issues that you're able to kind of troubleshoot those issues with those steps, and you can see how easy it is to kind of set up your own metrics and do that in a pretty efficient way. There's a lot of other commercial metric systems for, if you're not into setting up a Grafana server, or setting up your own Prometheus server, you can use tools like Datadog. Datadog makes it very easy for you to send metrics from any kind of client, any kind of language. And send that to the Datadog system, and they have a very similar kind of graphing capability with Grafana. And then, if you think about other metrics that you could start capturing, think about things like your timeouts, like who are the users, who are using your CI system. Maybe you have several CI projects that you want to collect metrics for. And you can use the same scraper mechanism to create scrapers for those particular projects, and send metrics to visualization system like Grafana, and start breaking down, which projects are your busy projects, which projects are your not so busy projects. So you can maintain them a little bit better. So I hope you enjoyed the lesson on metrics, and hope to see some really cool things from your explorations, so thank you.
