1 00:00:00,960 --> 00:00:02,969 Instructor: So when talking about monitoring 2 00:00:02,969 --> 00:00:04,800 what do we want to monitor? 3 00:00:04,800 --> 00:00:07,477 What do we want to look at in our API? 4 00:00:07,477 --> 00:00:11,340 So there are a lot of data that might be of interest for us. 5 00:00:11,340 --> 00:00:13,230 Let's review some of it. 6 00:00:13,230 --> 00:00:16,402 First, we want to know how many requests per second 7 00:00:16,402 --> 00:00:18,690 our API is having. 8 00:00:18,690 --> 00:00:20,040 That's an important information 9 00:00:20,040 --> 00:00:23,730 because it'll help us understand what is the usage pattern 10 00:00:23,730 --> 00:00:28,440 of our API and whether there are actual users using it. 11 00:00:28,440 --> 00:00:30,600 In addition, we definitely want to know 12 00:00:30,600 --> 00:00:32,610 the number of failures. 13 00:00:32,610 --> 00:00:37,350 So for example, if we see that one out of 10 request fails, 14 00:00:37,350 --> 00:00:41,292 then there is some problem with API that we must look at. 15 00:00:41,292 --> 00:00:44,430 Latency is a very important factor. 16 00:00:44,430 --> 00:00:47,640 Latency reflects the time a single request 17 00:00:47,640 --> 00:00:48,810 takes to complete. 18 00:00:48,810 --> 00:00:52,740 Or in other words, what is the performance of the API? 19 00:00:52,740 --> 00:00:55,163 Now, we discussed performance in previous lectures, 20 00:00:55,163 --> 00:00:58,050 so you already know how important it is 21 00:00:58,050 --> 00:01:00,420 and the latency data can tell us 22 00:01:00,420 --> 00:01:03,180 what is the actual performance of the API. 23 00:01:03,180 --> 00:01:05,190 CPU is always important. 24 00:01:05,190 --> 00:01:08,760 We need to know what is the average CPU utilization 25 00:01:08,760 --> 00:01:11,190 of our servers and if it is too high, 26 00:01:11,190 --> 00:01:13,950 then we will probably would like to scale out 27 00:01:13,950 --> 00:01:16,121 and add more computer resources. 28 00:01:16,121 --> 00:01:19,028 Number of users is great for our statistics, 29 00:01:19,028 --> 00:01:24,028 so we can know if we have 100 users or 1 million users. 30 00:01:24,270 --> 00:01:26,520 There is a huge difference between them. 31 00:01:26,520 --> 00:01:27,930 And in addition to users, 32 00:01:27,930 --> 00:01:31,213 we always want to know the number of sessions. 33 00:01:31,213 --> 00:01:34,320 Now, the difference between users and sessions 34 00:01:34,320 --> 00:01:37,892 is that users represent the number of unique users 35 00:01:37,892 --> 00:01:39,960 and the sessions represent the number 36 00:01:39,960 --> 00:01:42,750 of total requests of all users. 37 00:01:42,750 --> 00:01:46,170 So if a single user performed five requests, 38 00:01:46,170 --> 00:01:49,860 then he will be counted as one in the number of users 39 00:01:49,860 --> 00:01:52,593 but as five in the number of sessions. 40 00:01:53,970 --> 00:01:56,910 Geographic distribution is another interesting factor. 41 00:01:56,910 --> 00:02:00,420 We always want to know where our users are coming from. 42 00:02:00,420 --> 00:02:04,740 It can help us in decisions such as how to localize our API 43 00:02:04,740 --> 00:02:07,530 or where to put our computer resources. 44 00:02:07,530 --> 00:02:10,320 And last is the RAM, the memory. 45 00:02:10,320 --> 00:02:13,740 We always need to keep an eye on our memory utilization, 46 00:02:13,740 --> 00:02:15,390 and if it comes too high, 47 00:02:15,390 --> 00:02:18,330 then we probably have a problem of a memory leak. 48 00:02:18,330 --> 00:02:20,730 So here's an example of the monitoring 49 00:02:20,730 --> 00:02:24,390 I have on my own website at memilavi.com. 50 00:02:24,390 --> 00:02:27,150 So this specific monitoring displays 51 00:02:27,150 --> 00:02:29,751 the failures my website experiences. 52 00:02:29,751 --> 00:02:33,510 And you can see in the graph that on this specific day, 53 00:02:33,510 --> 00:02:35,880 August 25, there were a few. 54 00:02:35,880 --> 00:02:36,780 Now to be honest, 55 00:02:36,780 --> 00:02:38,610 I don't really know what was the reason for that. 56 00:02:38,610 --> 00:02:40,374 It is probably some kind of bot 57 00:02:40,374 --> 00:02:43,770 that simply requested a non-existent address, 58 00:02:43,770 --> 00:02:45,930 but it's still an important information. 59 00:02:45,930 --> 00:02:48,840 And this is only a very, very small part of the monitoring 60 00:02:48,840 --> 00:02:50,400 I have on my website. 61 00:02:50,400 --> 00:02:53,820 So now let's have a demo of a basic monitoring 62 00:02:53,820 --> 00:02:56,073 on the API we built in this course.