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 Cloudlocks. 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 walk-through, 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 Cloud Shell and then we're going to use that to download a sample app from GitHub. So I'm just going to click continue, because this is a new project, and I like to open this in a new window just so I have a little bit more space. That's just telling us that the Cloud SDK is pre-installed, 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 GitHub. So let me just make that directory, going to navigate to that directory, and then I'm going to git clone from the same repository that we saw in the previous lab. So this is not been completed, so let me change directories to that, and then I'm also going to launch the code editor, 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 2, import profiler, and this allows the profiler to monitor the resources the application uses. Now I'm also going to, after the main function, add 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 profiler is on, it starts reporting application metrics to Google Cloud. Now, we also have to add the profiler to, the profiler library, I should say, to our requirements.txt. So let me go do that, I'm going to open the requirements.txt, and on line 2, I'm just going to specify that we're going to use the Google Cloud profiler. And 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 and 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's successfully built, and let's test that. Now, within Cloud Shell, I have the web preview option to preview this import 8080. And if I do that, we see that the program is 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 it to an App Engine application. So let me go back, we are 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, oops, right click here on this folder, New File, app.yaml. And the minimum that we need to specify in here is the runtime. 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 app create region us-central1, and that's now creating that for our project in that region. And once that'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 navigate 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 two so I 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 the 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 is my version that's serving all of the traffic. And if I go to the right under Diagnose, 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, really, 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 Engine 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-west1, 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 sudo apt update and then also install apache2 utils. So we 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, I'm going to update. Then install Apache Bench. And when I run the Apache Bench command now, I'm going to run it 1,000 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.appspot.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 times for the information to start showing up, you will definitely see him 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 keep generating some more traffic. I'll 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 Console, 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 four, 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 allows you to create reports to analyze traffic. But because our program is new and really only has one page is 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 are 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 Also see all of them here and there latency so 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. I'm 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 could do that to to just play a little bit with the values of N and C. So I'm requesting it 10,000 times and a hundred times 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 do so many question the same time some of them certainly have a higher latency. So again, you could keep playing with this. 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 now going to move on to Task 6 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 gong 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 GC instances. We might have to refresh and wait for a while it 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. Now it's just just showing me some responses on HTTP. I can also go to SYSTEM and DATASTORE 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 GC instances, let's just create something ourself. So dashboard is just sort of 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. No, 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 in my instance that I have. So obviously, when I run the command there's high utilization than when I don't, you 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 Task 6, so let's move to Task 7 where we're going to create uptime checks and alerts. So here in the left hand side I'm going to click on Uptime checks and CREATE UPTIME CHECK. Now we're just going to give it a name, so let's make this the Uptime Check for our App Engine 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 Hostname and then .appspot.com. So I'm just going to grab that again, I'm navigating back to the browser where I have this app open already and put that in here. I already set this to 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 this uptime check, but do you also want to create an alert policy? This is actually pretty useful because if for whatever reason you have some down time in your application and you're not currently looking at this 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's uptime. So 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, sorry, the lab instructions are saying, Uptime Check Alerts. So let's do that because a lot of times the scores that we're giving the labs require that you follow the instructions. So that's good, great, so this is the metric. And then I'm going to, 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 an or or an and 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 have different types. So you could 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 test it, but the App Store 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, right? If this application goes down, do XYZ, 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 uptime check will then fail. So let's actually look at the uptime check. Currently, if I go to the up time check, we see these different continents from where we're checking. This uptime 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 can drill 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, since 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 Uptime 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 seconds. In Europe it's failing, here one out of three tests have failed, and if I just navigate to Alerting and back to Uptime checks, I can see, what? All of North America, all of South America, Asia Pacific, probably needs to run one more time. If I go in here now, we see the Percent Uptime is already down over the last hour. My Uptime Latency Zone and here apac-singapore's 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 the conditions that are defined in this alert, which is just at what point does it actually send that alert? And if you've put in your own email address, you will actually be getting that alert. So we could refresh this a couple times and wait for that and once you actually see that the incidence 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 failing 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 clicking the trash icon next to the email and then clicking Save. And then you could also go to the Uptime check and delete the Uptime 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.
