1 00:00:00,120 --> 00:00:03,120 So now, let's talk about the insights type 2 00:00:03,120 --> 00:00:04,260 of CloudWatch products. 3 00:00:04,260 --> 00:00:05,899 And we have, the first one we have 4 00:00:05,899 --> 00:00:08,070 is the CloudWatch container insights. 5 00:00:08,070 --> 00:00:11,640 So this is as the name indicates, the way to collect, 6 00:00:11,640 --> 00:00:14,970 aggregate, and summarize metrics and logs 7 00:00:14,970 --> 00:00:16,980 from your containers. 8 00:00:16,980 --> 00:00:18,960 And it's available for containers that you run 9 00:00:18,960 --> 00:00:22,650 on Amazon ECS, on Amazon EKS, 10 00:00:22,650 --> 00:00:25,650 on Kubernetes platform directly on EC2 11 00:00:25,650 --> 00:00:29,580 or on Fargate, both for ECS and EKS. 12 00:00:29,580 --> 00:00:30,690 So the idea is that thanks 13 00:00:30,690 --> 00:00:32,610 to the CloudWatch container insights, 14 00:00:32,610 --> 00:00:35,700 we can very easily extract the metrics and the logs 15 00:00:35,700 --> 00:00:38,490 out of our containers into a very detailed 16 00:00:38,490 --> 00:00:42,390 and granular dashboard from within CloudWatch. 17 00:00:42,390 --> 00:00:43,410 The other thing you need to know 18 00:00:43,410 --> 00:00:46,680 is that if you are using CloudWatch container insights 19 00:00:46,680 --> 00:00:49,350 on Kubernetes, would it be for Amazon EKS 20 00:00:49,350 --> 00:00:51,420 or Kubernetes running on EC2? 21 00:00:51,420 --> 00:00:53,790 The way CloudWatch insights work is that it's using 22 00:00:53,790 --> 00:00:56,670 a containerized version of the CloudWatch agents 23 00:00:56,670 --> 00:00:58,410 to discover containers. 24 00:00:58,410 --> 00:01:00,840 So that's the first thing you need to remember is this one. 25 00:01:00,840 --> 00:01:02,610 The second one is Lambda insights. 26 00:01:02,610 --> 00:01:04,800 So you're guessing what it would be about. 27 00:01:04,800 --> 00:01:07,710 It is about monitoring and troubleshooting solution 28 00:01:07,710 --> 00:01:11,580 for your serverless applications running on AWS Lambda. 29 00:01:11,580 --> 00:01:13,380 So again, it's going to collect, aggregate, 30 00:01:13,380 --> 00:01:15,240 and summarize system level metric, 31 00:01:15,240 --> 00:01:18,720 including CPU time, memory, disk, and network, 32 00:01:18,720 --> 00:01:21,360 and also information around your cold starts, 33 00:01:21,360 --> 00:01:23,400 and your Lambda worker shutdowns. 34 00:01:23,400 --> 00:01:26,250 And it's provided for your Lambda function 35 00:01:26,250 --> 00:01:27,150 as a Lambda layer. 36 00:01:27,150 --> 00:01:28,620 You don't really know this. 37 00:01:28,620 --> 00:01:31,020 But the idea is that it runs next to your Lambda. 38 00:01:31,020 --> 00:01:34,350 And it's going to create, again, a specified dashboard 39 00:01:34,350 --> 00:01:36,210 called Lambda insights to monitor 40 00:01:36,210 --> 00:01:38,040 the performance of your Lambda functions. 41 00:01:38,040 --> 00:01:39,750 And this is to be used when you need 42 00:01:39,750 --> 00:01:41,220 really, really detailed monitoring 43 00:01:41,220 --> 00:01:45,033 into your serverless applications running on AWS Lambda. 44 00:01:46,080 --> 00:01:48,060 Then, we have contributor insights. 45 00:01:48,060 --> 00:01:51,690 So this one is to analyze logs and create time series 46 00:01:51,690 --> 00:01:53,460 that display contributed data. 47 00:01:53,460 --> 00:01:56,820 So for example, you wanna see the top end contributor 48 00:01:56,820 --> 00:01:59,400 or the total number of unique contributors and their usage. 49 00:01:59,400 --> 00:02:01,080 So we'll go quickly into an example 50 00:02:01,080 --> 00:02:02,550 so you understand what this means. 51 00:02:02,550 --> 00:02:05,760 So this helps you find, for example, top talkers 52 00:02:05,760 --> 00:02:07,020 on your network and understand 53 00:02:07,020 --> 00:02:08,970 who is impacting system performance. 54 00:02:08,970 --> 00:02:12,540 So you can run it on any logs generated by AWS. 55 00:02:12,540 --> 00:02:16,110 For example, VPC logs, or DNS logs, and so on. 56 00:02:16,110 --> 00:02:17,850 And let's take an example. 57 00:02:17,850 --> 00:02:20,070 You can identify bad hosts. 58 00:02:20,070 --> 00:02:24,090 So we are going to look at the network logs, the VPC logs. 59 00:02:24,090 --> 00:02:27,210 And we're going to find the heaviest network users 60 00:02:27,210 --> 00:02:29,520 or we can find, for example, if you look at DNS, 61 00:02:29,520 --> 00:02:31,200 the URLs that generate the most errors. 62 00:02:31,200 --> 00:02:34,380 So let's have a look at how to identify 63 00:02:34,380 --> 00:02:36,330 the heaviest network users. 64 00:02:36,330 --> 00:02:39,060 So we look at the VPC flow log, which is the log 65 00:02:39,060 --> 00:02:41,880 of all the network request made within your VPC, 66 00:02:41,880 --> 00:02:44,490 which is then passed to CloudWatch logs, 67 00:02:44,490 --> 00:02:47,910 and then analyzed by the CloudWatch contributor insights. 68 00:02:47,910 --> 00:02:51,420 And out of it, we can find the top 10 IP addresses 69 00:02:51,420 --> 00:02:54,480 that are generating traffic on RVPC 70 00:02:54,480 --> 00:02:58,200 and understand if they are good actors or bad actors. 71 00:02:58,200 --> 00:03:01,980 So anytime, you see a top 10 contributors or whatever, 72 00:03:01,980 --> 00:03:04,290 this is the CloudWatch contributor insight. 73 00:03:04,290 --> 00:03:06,420 So you can look through logs and find 74 00:03:06,420 --> 00:03:08,910 who are the top whatever. 75 00:03:08,910 --> 00:03:10,350 So you can build rules from scratch 76 00:03:10,350 --> 00:03:14,310 or you can also leverage simple rules that AWS has created. 77 00:03:14,310 --> 00:03:17,280 And behind the scene, again, it leverages CloudWatch logs. 78 00:03:17,280 --> 00:03:20,100 And to finish, there are also built in rules 79 00:03:20,100 --> 00:03:21,660 that you can use to analyze metrics 80 00:03:21,660 --> 00:03:24,453 coming from other AWS services. 81 00:03:25,530 --> 00:03:28,170 Finally, we have CloudWatch application insights, 82 00:03:28,170 --> 00:03:30,630 which is to provide an automated dashboard 83 00:03:30,630 --> 00:03:32,070 that will show potential problems 84 00:03:32,070 --> 00:03:35,430 with monitored applications to help isolate ongoing issues. 85 00:03:35,430 --> 00:03:38,310 So your applications can be running on Amazon EC2. 86 00:03:38,310 --> 00:03:41,940 We select technologies only, for example, Java, or.net, 87 00:03:41,940 --> 00:03:45,900 or Microsoft IIS web server, or specific databases. 88 00:03:45,900 --> 00:03:49,290 And then, it will be linked to other AWS resources 89 00:03:49,290 --> 00:03:54,087 such as EBS, RDS, ELB, ASG, Lambda, SQS, DynamoDB, 90 00:03:54,087 --> 00:03:57,480 S3 buckets, maybe your ECS cluster, your EKS cluster, 91 00:03:57,480 --> 00:03:59,820 SNS topics, or your API gateway. 92 00:03:59,820 --> 00:04:03,030 And so in case there is an issue with your application, 93 00:04:03,030 --> 00:04:05,460 automatically, CloudWatch applications insights 94 00:04:05,460 --> 00:04:08,850 is going to put together an automated dashboard 95 00:04:08,850 --> 00:04:11,730 that shows you the potential issue with some services. 96 00:04:11,730 --> 00:04:15,180 And to do this, automated dashboard is going to use 97 00:04:15,180 --> 00:04:17,940 a SageMaker machine learning service internally. 98 00:04:17,940 --> 00:04:20,850 So it's really going to give you enhanced visibility 99 00:04:20,850 --> 00:04:23,880 into your application health for you to reduce the time 100 00:04:23,880 --> 00:04:27,570 it takes you to troubleshoot and repair your application. 101 00:04:27,570 --> 00:04:30,570 So this is really cool because, well, if your application 102 00:04:30,570 --> 00:04:33,750 is using other services or other resources of AWS, 103 00:04:33,750 --> 00:04:35,910 automatically, if it's a problem originating 104 00:04:35,910 --> 00:04:37,830 from one of them, it will surface 105 00:04:37,830 --> 00:04:40,083 in the applications insights dashboard. 106 00:04:41,252 --> 00:04:43,470 And all the alerts and findings will be sent 107 00:04:43,470 --> 00:04:46,650 to Amazon EventBridge and SSM OpsCenter 108 00:04:46,650 --> 00:04:49,530 so that you can be alerted in case there is an issue 109 00:04:49,530 --> 00:04:51,663 detected with your application. 110 00:04:52,800 --> 00:04:55,650 So to summarize, you only need to know these services 111 00:04:55,650 --> 00:04:56,700 at a high level. 112 00:04:56,700 --> 00:05:00,570 So CloudWatch container insights is for your metrics 113 00:05:00,570 --> 00:05:03,951 and logs coming from ECS, EKS, 114 00:05:03,951 --> 00:05:05,670 Kubernetes on EC2, and Fargate. 115 00:05:05,670 --> 00:05:07,590 And in case you are using Kubernetes, 116 00:05:07,590 --> 00:05:09,990 you need an agent to run. 117 00:05:09,990 --> 00:05:12,810 For CloudWatch Lambda insights, this is detailed metrics 118 00:05:12,810 --> 00:05:14,520 to troubleshoot your serverless applications 119 00:05:14,520 --> 00:05:16,740 running on AWS Lambda. 120 00:05:16,740 --> 00:05:18,510 For CloudWatch contributors insights, 121 00:05:18,510 --> 00:05:20,790 this is to find the top end contributors 122 00:05:20,790 --> 00:05:22,320 through your CloudWatch logs. 123 00:05:22,320 --> 00:05:24,240 For CloudWatch application insights, 124 00:05:24,240 --> 00:05:26,100 this is to create automatic dashboards 125 00:05:26,100 --> 00:05:27,810 to troubleshoot your applications 126 00:05:27,810 --> 00:05:32,520 and the related AWS services that your application is using. 127 00:05:32,520 --> 00:05:33,450 So that's it for this lecture, 128 00:05:33,450 --> 00:05:34,680 you should be good for the exam. 129 00:05:34,680 --> 00:05:35,700 I hope you liked it. 130 00:05:35,700 --> 00:05:37,650 And I will see you in the next lecture.