1 00:00:00,780 --> 00:00:01,780 Instructor: So for our demo, 2 00:00:01,780 --> 00:00:04,980 we'll use again our loyal Beeceptor 3 00:00:04,980 --> 00:00:07,500 this time in a slightly different domain. 4 00:00:07,500 --> 00:00:10,740 So the domain we will monitor is apicourse1, 5 00:00:10,740 --> 00:00:13,140 and if we will take a look at the mocking rules 6 00:00:13,140 --> 00:00:17,340 we will see we have our regular URL of api v1 order. 7 00:00:17,340 --> 00:00:20,910 This is the endpoint we would like to monitor. 8 00:00:20,910 --> 00:00:23,700 Now the monitoring engine, we will use 9 00:00:23,700 --> 00:00:28,700 is the Application Insights of Azure, Microsoft Azure, 10 00:00:28,885 --> 00:00:32,040 which is the public cloud of Microsoft. 11 00:00:32,040 --> 00:00:34,950 And it has a very good monitoring engine. 12 00:00:34,950 --> 00:00:37,980 Of course, it is not the only monitoring engine out there. 13 00:00:37,980 --> 00:00:41,370 There are a few, but I personally always prefer 14 00:00:41,370 --> 00:00:42,870 the Application Insights. 15 00:00:42,870 --> 00:00:45,240 Now, if you don't have an Azure account, 16 00:00:45,240 --> 00:00:50,240 you can always sign up for a free account with $200 credit. 17 00:00:50,280 --> 00:00:52,680 And the Application Insights is basically free. 18 00:00:52,680 --> 00:00:55,590 So you can use it as much as you want. 19 00:00:55,590 --> 00:00:58,980 So we are in the Azure portal 20 00:00:58,980 --> 00:01:01,950 and let's build the monitoring. 21 00:01:01,950 --> 00:01:06,950 So we will go here and write application insights 22 00:01:12,960 --> 00:01:16,743 and let's add a new monitor, 23 00:01:20,610 --> 00:01:22,800 select Resource Group, 24 00:01:22,800 --> 00:01:24,100 and let's give it a name 25 00:01:24,972 --> 00:01:28,090 and I'll call it Beeceptor-monitor, 26 00:01:32,550 --> 00:01:35,133 and let's create this monitor. 27 00:01:39,120 --> 00:01:40,800 And in a few seconds, 28 00:01:40,800 --> 00:01:43,890 we will have a monitoring engine ready to use. 29 00:01:43,890 --> 00:01:45,783 The deployment is going through, 30 00:01:49,290 --> 00:01:51,210 and the deployment is ready. 31 00:01:51,210 --> 00:01:54,693 So let's go to the resource, which is the monitor. 32 00:01:55,770 --> 00:01:57,690 And we have a lot of chart here 33 00:01:57,690 --> 00:02:01,920 that right now naturally displays nothing. 34 00:02:01,920 --> 00:02:04,083 Now let's click the availability. 35 00:02:05,520 --> 00:02:08,430 and let's add test. 36 00:02:08,430 --> 00:02:11,370 So what we are going to do here in the test 37 00:02:11,370 --> 00:02:13,770 is to define the kind of monitoring 38 00:02:13,770 --> 00:02:17,100 we would like to perform on our website. 39 00:02:17,100 --> 00:02:19,560 Now we want to keep the monitoring in this demo 40 00:02:19,560 --> 00:02:21,926 as basic as possible without modifying 41 00:02:21,926 --> 00:02:24,450 and without writing any code. 42 00:02:24,450 --> 00:02:27,030 So this monitoring will be only external, 43 00:02:27,030 --> 00:02:29,700 meaning we will ask the Application Insights 44 00:02:29,700 --> 00:02:32,550 to ping our website periodically 45 00:02:32,550 --> 00:02:35,910 and collect data about its availability. 46 00:02:35,910 --> 00:02:40,910 So the test name will be Beeceptor-availability. 47 00:02:44,040 --> 00:02:47,220 We would like to perform ping test. 48 00:02:47,220 --> 00:02:50,880 And the URL we would like to ping is, 49 00:02:50,880 --> 00:02:52,863 let's copy it from here, 50 00:02:56,880 --> 00:02:58,593 and paste here. 51 00:03:00,480 --> 00:03:05,480 V1, sorry, api-v1 order. 52 00:03:05,508 --> 00:03:10,020 This test will be performed every five minutes. 53 00:03:10,020 --> 00:03:12,690 It'll be performed from five locations 54 00:03:12,690 --> 00:03:15,630 which is great, because our API should be global 55 00:03:15,630 --> 00:03:17,370 and we would like it to be tested 56 00:03:17,370 --> 00:03:19,320 from as many locations as possible, 57 00:03:19,320 --> 00:03:21,450 and in this case, five are great. 58 00:03:21,450 --> 00:03:25,020 From the United States, in its West, South, 59 00:03:25,020 --> 00:03:28,050 North Central, East, Central US. 60 00:03:28,050 --> 00:03:33,050 Let's also add Japan East, UK West, 61 00:03:33,150 --> 00:03:35,280 and West Europe. 62 00:03:35,280 --> 00:03:39,510 Great. Now, what is a success criteria for this test? 63 00:03:39,510 --> 00:03:42,450 If the endpoint returns 200, 64 00:03:42,450 --> 00:03:45,780 which is as you probably remember, an okay status 65 00:03:45,780 --> 00:03:48,750 then the test succeeded. 66 00:03:48,750 --> 00:03:52,473 Great, so let's create it. 67 00:03:54,540 --> 00:03:56,670 And now let's let it run. 68 00:03:56,670 --> 00:03:59,929 So I'll pose the recording and I'll come back 69 00:03:59,929 --> 00:04:02,130 in a few minutes when we will already 70 00:04:02,130 --> 00:04:04,083 have some results to look at. 71 00:04:06,360 --> 00:04:08,280 Okay, so we are back. 72 00:04:08,280 --> 00:04:09,690 So what we see here is 73 00:04:09,690 --> 00:04:14,690 that the monitor made 23 successful request 74 00:04:14,970 --> 00:04:17,579 and not a single request failed. 75 00:04:17,579 --> 00:04:19,740 And if you will look at the chart here, 76 00:04:19,740 --> 00:04:22,500 let's just focus on the time slice 77 00:04:22,500 --> 00:04:24,393 that is interesting for us. 78 00:04:26,100 --> 00:04:28,500 Then you can see the data here, 79 00:04:28,500 --> 00:04:33,500 we have a 100% overall availability, which is great. 80 00:04:34,740 --> 00:04:38,580 Now let's go back here to the Beeceptor 81 00:04:38,580 --> 00:04:43,580 and let's modify the rule that instead of returning 200 82 00:04:45,360 --> 00:04:49,083 let's return 400, which is bad request. 83 00:04:50,700 --> 00:04:53,460 And let's go back to the monitor, 84 00:04:53,460 --> 00:04:55,440 and again, I'll pose the recording 85 00:04:55,440 --> 00:04:58,233 and let's come back in a few minutes. 86 00:05:00,570 --> 00:05:04,380 And we are back, and look what we have here. 87 00:05:04,380 --> 00:05:07,230 We can see here clearly there is a problem 88 00:05:07,230 --> 00:05:09,660 with the availability of our website, 89 00:05:09,660 --> 00:05:12,720 and if you will hover above this point in the chart 90 00:05:12,720 --> 00:05:16,800 we can see that the availability right now is 0%. 91 00:05:16,800 --> 00:05:21,420 And we can see here there will four failed requests. 92 00:05:21,420 --> 00:05:22,833 And if you will click here, 93 00:05:23,722 --> 00:05:27,930 we can see that we have four requests 94 00:05:27,930 --> 00:05:31,350 that have failed which is actually exactly 95 00:05:31,350 --> 00:05:33,120 what we wanted to happen. 96 00:05:33,120 --> 00:05:37,260 Again because we modified the response code of our request, 97 00:05:37,260 --> 00:05:40,830 and as you probably remember, we defined the test 98 00:05:40,830 --> 00:05:45,830 that only a 200 status code designates a successful test. 99 00:05:46,230 --> 00:05:49,620 So that concludes our demonstration on monitoring. 100 00:05:49,620 --> 00:05:52,710 Again, this monitoring is extremely basic 101 00:05:52,710 --> 00:05:55,680 and we can achieve a lot more using 102 00:05:55,680 --> 00:05:58,500 this tool as well as other tools. 103 00:05:58,500 --> 00:06:00,900 But the bottom line is the same. 104 00:06:00,900 --> 00:06:03,600 Always make sure to monitor your API 105 00:06:03,600 --> 00:06:06,120 so that you will know when there is a problem 106 00:06:06,120 --> 00:06:09,060 or a developing problem with the API 107 00:06:09,060 --> 00:06:12,183 that might harm your user's experience.