In this lab, you saw how to monitor your applications using built in Google Cloud tools. First, you deployed an application to app engine and examined cloud locks. Then you viewed profile information and explored cloud trace. Last but not least, you monitored your applications with dashboards and created uptime checks and alerts. You can stay for our lab walkthrough but remember Google Cloud's user interface can change so your environment might look slightly different. So the first thing we're going to do is activate Clouds Shell and then we're going to use that to download a sample app from Get up. So I'm just going to click continue because this is a new project and I'd like to open this in a new window. Just have a little bit more space. I was just telling us that the cloud SDK is preinstalled. That's great. And I'm going to wait for the machine to be provisioned. I'm going to create a directory, navigate to that directory and then clone a simple python flask application from get hub. So let me just make that directory could navigate to that directory. And then I'm going to get good clone from the same repository that we saw in the previous lab. So this is now been completed. So let me change directories to that. And then I'm also going to launch decoded and in here, I am also going to navigate through courses, design process to this application. And here we can see the main file. So what I'm going to do now is I'm going to make some modifications to the main file because I want to use the Google Cloud Profile. The first thing I'm going to do is import the profiler. I'm going to specify that on line to import Profiler and this allows the Profiler to monitor the resources the application uses. Now I'm also going to after the main function at a code snippet to start the Profiler. So let me go down here and maybe add this on line 13 and then they're going to try to add that. And now I'm going to confirm that the code in here matches what is shown in the lab instructions and that looks good to me. So this code simply turns the profiler on and once the profile is on it starts reporting application metrics to Google Cloud. Now, we also have to add the Profiler to the profile library, I should say, to our requirements txt so let me go do that. I'm going to open the requirements txt and online 2, I'm just going to specify that we're going to use the Google Cloud Profiler. Okay, so I've added it everywhere. Now, the last thing I need to do is enable it for the project, we can do that directly in Cloud Shell. So I'm just going to clear this to give myself more space and I'm going to run the command in the lab instructions to enable the Cloud Profiler from the Google APIs. So let me run that and once that has been completed, we're going to test the program by first installing the requirements and then starting the program. And there, we can see the Google Profiler in here that successfully built. And let's test that. Now, within Cloud Shell I have the web preview option to preview this import 80, 80 and if I do that we see that the programs currently working and it's just displaying, hello GCP. So that's it for task one. Now in task two, we're going to take this application and deploy to an app engine application. So let me go back, we're going to stop this and I'm now going to create a new file, the app yaml, which we did similarly in the previous lab. So I'm just going to, right click here on this folder, a new file app yaml. And in the minimum that we need to specify here is the rundown. So I'm going to specify python, then save those changes. And now we're going to start off by specifying the region where we want this app to be created. So I'm going to use the gcloud upgrade region, us-central-1 and that's not creating that for our project in that region. And once it's up and running we're going to deploy our app. Okay, so now I can deploy it and we're going to wait for that to complete. So the app has been deployed. So let's go to the cloud console to view it. So I'm just going to advocate to the cloud console, can make this a bit smaller here and in the navigation menu, I'm going to go to app engine. Collapse these tools have a bit more space and we currently only have one version and here's our application and if I click on that we should see same page we saw earlier. Hello GCP, and I can refresh this a couple times now to start generating some traffic and we're going to do a little bit more of that in a second for the profiler. But first let's go to task three and examine the cloud locks. So for that I'm going back to app engine and I'm going to click on versions. Here's my version that's serving all of the traffic. And if I got to the right under diagnosed tools, I'm going to leverage logs. And we'll see here some of the requests I've been making and we will also see here that the Stackdriver Profiler agent has started and has created a profile so we can see that that has been successful. So now we can move on to task four and view the Profiler information. So I can go to the navigation menu, scroll down to operations and here is the profiler. So this gray bar here at the top represents the total amount of CPU time used by the program. And the bars below that represent the amount of CPU time used by the program's function relative to the total. At this point, there's no traffic relays, so the chart is not very interesting. So what we're going to do now is we're going to throw some load at the application. We're going to do that by creating a virtual machine using compute engine that is in a different region than our app and in app. And then we will use bench to create some traffic on here. So let me go to the navigation menu, go to compute engine. And I'm going to click create. And in here now we're going to just choose a different region. So instead of us-central1, we're going to place this in, let's say europe west 1. And then I'm just going to click create. And once this virtual machine is up and running, we're going to SSH to this instance. We're going to run through apt update and then also install Apache to you tails. So let me go to SSH and resize this window a little bit. And then we're going to go ahead and run that and then use Apache bench to generate the traffic. So first, good update. And then install Apache bench. And when I run the Apache bench command now I'm going to run it 1000 times 10 requests at a time, but I need the site, the https address for my app engine application. This is always in the form of by default of project ID.blogspot.com. So I could just use that or I am going to go back and just grab it in my browser. I still have it in there and it's important that you have the slash at the end. So I'm going to run that and we can run that a couple times to just generate some traffic. It might take a while for the Profiler to show something very interesting. But if you generate enough traffic and again you might have to try just a couple of times for the information to start showing up. You will definitely seem some more interesting graphs that again, where you have these bars and each bar represents a function. And the width of the bars represent how much CPU time each function consumed. So I'm just going to just keep generating more traffic. Look at the Profiler and then move on to task five. All right, so I've generated some more traffic. So I think it's time to go back to the Cloud Council and from the navigation menu, I'm going to go back to Profiler and indeed this looks a lot more interesting. So again each of these bars is a function and the width of the bar represents the amount of CPU time that the program has consumed for each of those functions. So that finishes task force. So it's time to move on to task five where we're going to explore Cloud Trace. So every request to your application is added to a trace list. So let's go to the navigation menu and as well under operations go to trace. So this is an overview screen and it shows recent requests and allows you to create reports to analyze traffic. But because the program is new and really only has one page, it's not very interesting. But in a real lab there will be lots of useful information in here. So I'm going to first click on the trace list and this is going to show a history of the requests and their latency. So here all of the different requests I've made just over the last couple of minutes, I can see all the latency. Some of them definitely took a little bit longer and I can also see all of them here and they're latency. So what we could do now is I could go back to my SSH window of my virtual machine. I could just go ahead and generate more and more traffic and I'm going to do that and then we're going to come back and look at this trace list again. So I've run the Apache bench command a couple more times. And what I did is I've actually changed it and you can do that too to just play a little bit with the values of NNC. So I'm requesting it 10,000 times and 100 times at a time. So now let me go in here and reload my trace list and now you can see that I have a lot more requests and because I'm requesting so many, I'm doing so many quests at the same time. Some of them certainly have a higher latency here. So again you could keep playing with us. Keep in mind the lab is only open for so long but this is just to give you an idea of trace and how to use the trace lists. I'm not going to move on to task six where we're going to monitor resources using dashboards. So in the cloud console I'm going to navigate to monitoring which again is under the operations section. And what this is going to do is it's going to first set up a workspace for us. So let's wait for this to complete. So the workspace is now established. So we get this welcome page here and we can now use the navigation bar over here on the left. So first I'm going to head to dashboards and here we can see dashboards for different resources. It's currently not showing GCE instances we might have to refresh and wait for a while to come back. For now let's just go to app engine and here we see our project and our application and I can click on that to just see a dashboard for our application. No, I was just showing me some responses on HTTP. I can also go to system and data store and look at a couple different options or I could actually go ahead and create my own custom dashboard. So if I go back to dashboards, I could also click create dashboard, give it a name, my dashboard. And since it's currently not showing GCE instances, let's just create something ourselves. So dashboard is just a canvas and you just add charts to it. So I'm going to look for GCE VM instance. There we go. And I'm going to select CPU utilization. Now I only have one instance. So that is the one shown here and here. I get a little bit idea of what kind of load the Apache bench command has put on my instance that I have. So obviously when I run the command there's high utilization than when I don't can see that here. And I could put other things in here like filters or group this or I could just save it and have this chart. So here we can now see my CPU utilization and I could create other charts in here. That might be interesting. Now that's it for test six. So let's move to test seven where we're going to create up time checks and alerts. So here on the left hand side I'm going to click on up time checks and create a time check. Now we're just going to give it a name. So let's make this the uptime check for our app and an application, the check type is going to be HTTPS. We're just going to use a resource by URL and now I need to put in the host name and then .blogspot.com. So I'm just going to grab that again. I'm never getting back to the browser where I have this app open already and put that in here. I already said that this is HTTPs and this is the path. So I can remove that up here and then I can just say sure check every minute. And I could now test this to see this working response, okay, great. And then I can save that. Now it's saying, hey, great. We've created a Uptime check. But you also want to create an alert policy. That's actually pretty useful because if for whatever reason you have some downtime in your application and you're not currently looking at the Uptime check. You won't be notified unless you create a policy. So let's create an alert policy. So it's already looking at that and making sure that Uptime. That's great. So this is the uptime check sort of metric itself. The condition so I can just give that a name, say my Uptime alert. Or actually the lab instructions are saying Uptime check alerts. So let's do that because a lot of times the scores that were given labs require that you follow the instructions. So that's good, great. So this is the metric. This is the, sorry, this is the condition. I can also put that same name in here and then I could have several conditions so if anything else is going on and I could say, hey, it's either or or an end condition with these triggers. And then really importantly optional but important you should add a notification channel. So if I click on that in here, you could have different types. So you can use for example email and you could send yourself an email. I don't really recommend putting your own email in here. You could and tested, but the apps that are not going to go down until this project is deleted and then you might get tons of emails that you may not like. So as an example I can just put in the email from this qwiklabs project and add that. And then also importantly is to actually put in some documentation so whoever gets this email, what should they be doing when they receive this alert. I'd be very specific. I'd have the actual disaster plan in here. If this application goes down, do x, y, z notify these people do that. So that's really what you want to put into the documentation. So I'm just going to go ahead and save that because that's required for the scoring that we have in here. And actually what you can do is you could now go ahead and disable the application and just see that the up time check will then fail. So let's actually look at the time check currently if I go to the uptime check, we see these different continents from where we're checking the symptom check, it's working from everywhere. I can click on the name to actually get more information. I see so far it's been 100% uptime, I see the latency and I control down into that by looking at the latency from different regions. So here we can see this is actually being tested from different regions specifically in these different continents. We have different regions from where we're checking this and here we can see our overall configuration one more time. We also see that we have an alert policy and we could create some other alert policies. So let's go ahead and disable the application, so I'm going to go into the navigation menu and go back to app engine. All right, so here I am on app engine left hand side, I'm going to scroll down and go to settings and I'm going to click disable application. Now, for safety reasons it's telling me that I need to type in the name. So let's type in the app ID, I can actually copy that and click disable. So this is now getting disabled and now I can go back to the dashboard and if I try that URL we see we get a 404. Great, that's what we're trying to replicate. So let me go to the navigation menu and let's go back to monitoring and head to our up time check and we're going to wait until this check is run again which keep in mind is being run every minute. And see that this should then be failing, okay. So here we can see it's already failing. Only took a couple of seconds and Europe is failing. Here, 1 out of 3 tests have failed and if I just never get to alerting and back to temp checks, I can see well, all of North America, all of South America, Asia Pacific probably needs to run one more time. If we go in here now we see the percent uptime is already down over the last hour. My up time latency down and here apac-singapore is the last region and if we refresh there we go, all of these have failed. So if I go to alerting I see that I have my alert policy, they should be firing any moment now to send me an actual alert depending on the conditions that are defined in this alert. Which is just at what point does it actually sent that alert? And if you put in your own email address you will actually be getting that alert. So we could refresh this a couple of times and wait for that. And once you actually see that the incidents fired or you get the alert, you do want to go back here and edit the notification channel of this alert. And remove your email address so that you don't accidentally get any spam about this feeling in the future because it's going to keep failing. So you will keep getting alerts. So you can do that in here by just editing this. And taking the trash icon next to the email and then clicking safe. And then you can also go to the uptime check and delete the app time check itself as well, just for safety so that again, you're not being notified about this. And that's the end of the lab.
