Welcome back to BackSpace Academy. In this lecture we're going to be building 2
on what we already know about Cloudwatch from the cloud practitioner course. 3
We know that we can use it for infrastructure monitoring, for example to 4
trigger an auto scaling event that would add EC2 instances to our infrastructure 5
when demand is high. We know we can use it to alert us when our AWS bill is 6
going to exceed a certain level. We can also use it for application monitoring, 7
so not only monitoring our infrastructure as working but also 8
looking at our application and making sure that the application is doing what 9
we intended it to do and it is performing exactly how we would like it to perform. 10
We'll look at CloudWatch metrics and alerts specifically for containers in 11
container insights. We'll look at CloudWatch logs and how we can filter and 12
analyze those logs and the different services around that can integrate with 13
CloudWatch logs. We'll look at how AWS services can subscribe to log events 14
from multiple sources and multiple accounts and collate that in one 15
delivered spot through the use of CloudWatch subscriptions, and finally we'll 16
look at securing our CloudWatch logs as well. We already know about metrics and 17
what they can do. We know that there are default metrics for EC2 and SQS but 18
there are also a number of other default metrics for other AWS services. 19
In fact more than 70 AWS services have default metrics that are available for you to use. 20
That includes not only EC2 and SQS but also Dynamodb S3, ECS, Lamdda, 21
API Gateway and many more, and if those default metrics don't do what we want 22
then we can also create our own custom metrics, and the way we do that is that 23
we can have an application deliver data directly to CloudWatch for us, and we 24
can do that using the CloudWatch API, SDK or the command-line interface, 25
and use the put metric data command which will send data that we have collected 26
and send that to CloudWatch. For example you might have an Internet of Things 27
device and that is acquiring data from a sensor, and you would like to put that 28
data somewhere. You could use the put metric data command and have your 29
application that is using the AWS SDK and that would send that data to the AWS 30
CloudWatch service and from there you can analyze it and view it and do whatever 31
you want with it. Now standard custom metrics they are a one minute resolution 32
but there are also high resolution custom metrics that can go up to one 33
second resolution. One thing to consider though is that the pricing is the same 34
regardless of resolution. So the higher resolution will of course cost you more. 35
All metrics will expire after the defined retention period, so if you've 36
got high resolution custom metrics and they are less than 60 seconds of 37
resolution then CloudWatch will hold those for up to 3 hours and then after 38
that they will expire and will be removed from the system. If it's 1 minute 39
it will be 15 days, if it's 5 minutes it will be 63 days, and if you have a one 40
hour resolution between your sampling then that will be 455 days or 15 months 41
of retention period. Those metrics, you cannot delete those manually they must 42
expire after that defined retention period. If an instance is terminated or 43
that monitoring is disabled, the previously connected metrics will still 44
be available for you to view. Now if you find that the retention period is not 45
long enough for you, you want to archive these further, you can actually download 46
your data points using the CloudWatch API or an SDK or the command line interface 47
using get metrics statistics command and that will allow you to 48
download those data points over a defined 49
period and from there you can store them somewhere else 50
such as Amazon s3. If you implement CloudWatch logs to store your log data then 51
that will store it for as long as you want, it will store it indefinitely and 52
you can change that period for however you want as well. 53
Any CloudWatch metric, whether it's default or custom doesn't matter, 54
can have an alarm associated with it and that alarm will be triggered when that 55
threshold is met. An example of an alarm would be EC2 CPU utilisation, and we 56
could use that alarm to alert an auto scaling event to occur. We could use the 57
sqs queue length to add worker ec2 instances on a processing line. We could 58
also have a metric that alerts us or an alarm that alerts us when our AWS bill 59
exceeds a certain level. The alarms will be triggered when a threshold level is 60
met, so you need to set a target value and then you need to choose whether 61
there is greater than, greater than or equal, less than or, less than or equal to 62
that target value, for that alarm to be triggered. If you are using high 63
resolution custom metrics then you can establish a high resolution alarm 64
for periods as low as 10 seconds. The history of alarms will be retained for 65
up to 14 days and available for you to view. Not only can we collect metric data 66
and view that metric data, we can also apply basic statistics to that data as 67
well. We can apply metric data aggregations over a specified period of 68
time and we can apply the minimum or the maximum value, the sum of values, the 69
average of all of these data points, the sample count or, a percentile of that 70
data within that period of time. It supports many unit types and if you want 71
to know what they are you just go to the 72
CloudWatch API documentation and lookup metric datum and that will list all of 73
the different data types that are available. The periods for our data 74
aggregations will be defined in seconds and that will be one second, or five 75
seconds, or 10 seconds, or 30 seconds, or any multiple of 60 seconds. Sub-minute 76
periods are only available if you are using high resolution custom monitoring, 77
it's not available with standard monitoring. Not only can you collect data 78
but you can also view those metrics and alarms in the console with the AWS 79
CloudWatch dashboards. They are a customized auto refresh view of that 80
data. You can also create cross account and cross region dashboards if you need. 81
Live data if it is switched on is shown as soon as any data is published for 82
that period. So when that period is up and it and it publishes the data for 83
that specific period that live data will appear on the dashboard. If live data is 84
switched off then it will be shown one minute later. 85
Those dashboards, they can be created obviously using the AWS 86
management console, but they can also be created manually using the command-line 87
interface, API or one of the many software development kits, using the put 88
dashboard command. Anyone who wants to view those dashboards will need to have 89
an IAM permission to view that, and that could be administrator access, or 90
CloudWatch full access policy, or you could create a custom policy that would have 91
get dashboard permissions, or list dashboard, or put dashboard to create a 92
dashboard, or delete dashboards permissions attached to it. 93
CloudWatch synthetics allows you to create configurable scripts or canaries to 94
monitor web endpoints and api's. What that means is if you want to not only 95
check that a website is up and available, you also 96
want to check that it is performing and doing exactly what it is supposed to do, 97
then you can create a script that can test that for you to make life easier 98
for you. There are blueprints available and you 99
can choose from a heartbeat monitor just to check that the the endpoint or API is 100
actually accessible, you can check an API canary that can send a HTTP POST command 101
or whatever to an API and check that it is responding correctly, you can also 102
have a broken link checker that can go through a website and make 103
sure that there are no broken links, and there is also a graphical user interface 104
workflow blueprint that is based upon puppeteer. Now this is where the real 105
power of Synthetics comes in. Puppeteer, not to be confused with Puppet, 106
Puppeteer is a Nodejs package that allows you to communicate 107
with a headless webkit for web automation. Now if you're not a developer 108
you're probably saying, what is that? Now this is a very powerful tool and I've 109
been using web automation for many many years and it is part of my really 110
powerful tool kit that i use quite a bit. I've uses PhantomJS quite a lot and, 111
in 2017 when Google came out with their headless Chrome browser I've been using 112
that with puppeteer. Both of them are very good. What they do is that they 113
allow you to interact with a website without actually having a browser and 114
you can do it all with code. So you can code to enter into a text box and then 115
click on submit and you can wait until a button appears or some CSS element appears 116
and you can do all this through code, and so this from the backend, so 117
from a website's perspective, it doesn't know whether it's communicating with a 118
real person that is using a browser or whether it is actually just code that is 119
sending commands to a headless browser, and that is very powerful because we can 120
use that for testing. So we can go through as a normal user would and go 121
through and conduct some things on a web page, we can download stuff, we can input 122
stuff, and we can do everything that a normal user would do. So we can set up 123
with CloudWatch Synthetics to monitor and run through this GUI test, using 124
Puppeteer, and we can write our code in Puppeteer, and Synthetics will, on a 125
regular basis that we that we define, will run that test on our 126
application and this is great because although we may have unit testing at the 127
design stage and development of our application, it's always great because 128
things do change and there may be things that we didn't pick up and we 129
later on pick those up when it goes live, and so that's where this really comes in 130
and is really powerful. Those synthetics tests can be scheduled for up 131
to one minute intervals and statistics and details of those can be viewed in 132
the console. Another great feature is it integrates with CloudWatch Servicelens 133
which we'll talk about in the next slide. CloudWatch Servicelens, it allows you 134
to visualize and analyze a health performance and availability of your 135
applications in a single place, and it does that by integrating AWS x-ray with 136
CloudWatch. Now you'll learn a lot about AWS x-ray if you're going on to do the 137
AWS certified developer course with backspace' academy, but if you're not 138
it's a service that allows you to insert, within your applications 139
code, to send data to the AWS x-ray service, and so what that does is the AWS 140
x-ray service will collect that data, those data points, and it will 141
display those, and what that means is that you can see how long it takes for 142
different functions within your application to operate, and allows you to 143
pick up on any errors or bottlenecks within your application 144
when it's running. So the way it works is that we have to integrate x-ray 145
with CloudWatch by deploying first off the x-ray code on the application and we 146
do that using one of these software development kits, and then we also, 147
separate from our application, we have to install the x-ray daemon, and what the 148
daemon does is it communicates between our application and the AWS x-ray 149
service, and then the x-ray service will collect that data. Then we need to 150
install the CloudWatch agent on our server and that will allow the x-ray 151
data points to be sent off to CloudWatch and from there we can monitor and 152
view those. Container insights are metrics and logs specifically for 153
containerized applications and micro-services . Some examples of metrics 154
could be CPU utilization, memory, storage, task count, it's available for elastic 155
container service, elastic kubernetes service and also for kubernetes that is 156
running on EC2. Container insights are charged as custom metrics. 157
CloudWatch logs allow you to monitor store and access log files from a number of AWS 158
services such as ec2, VPC flow logs, cloudtrail, API gateway, ECS, EKS, lambda, 159
RDS, route 53 and SNS, just to name a few. There are log events for CloudWatch 160
logs that consists of a timestamp and then a message, and the log streams are a 161
sequence of these log events that come from the same source, and then we have 162
log groups which are groups of these log streams that have the same retention 163
monitoring and access control settings. You can apply filters to the metrics 164
that are collected by the CloudWatch log service by assigning those metric 165
filters to an individual log group and by doing that that metric filter will be 166
applied to all of those associated group streams. Now by default, unlike standard 167
CloudWatch, the logs are kept indefinitely and never expire but you 168
can change this by modifying the retention settings. So by creating 169
different retention settings and assigning those to a log group any 170
streams that are associated with that log group will have those retention 171
settings applied to them. CloudWatch logs insights is a fully managed service 172
that allows you to analyze data stored in CloudWatch logs and it does that 173
with a really fast an interactive querying service and it also allows you 174
to visualize the results of that afterwards in line and area charts as well. 175
It uses a really simple query language with really simple commands 176
such as display to simply limit the display of those results, to retrieve 177
certain fields, to apply a filter on results, to apply statistics to an 178
aggregated region of those results, to limit those results, and also to conduct 179
parse operations on those results as well. You can apply arithmetic operations and 180
also you can apply regular expressions to those results as well. There are a 181
number of built-in functions such as string functions, date/time functions, 182
also functions that can be based upon the IP address of those results, and also 183
functions that can be that can apply across aggregations of data, and again 184
the visualization results can be in line or area charts. CloudWatch contributor 185
insights is a great tool if you're conducting a root cause analysis into 186
problems in your infrastructur. It helps you to identify the top contributors to 187
those results that are influencing your system performance. It does this by you 188
creating rules in a JSON or a JavaScript object notation and those rules will 189
allow contributor insight to evaluate for patterns in those streams 190
of log events that are sent to CloudWatch logs. To make life easier for you 191
there is a wizard that can develop these JSON objects for you. You don't have to 192
actually do it yourself as such and there are also sample rules also 193
available to create that JSON. So if you're not too comfortable in creating 194
JSON scripts or JSON notation then there is that wizard and sample rules 195
available for you. Those results can be also sorted and filtered according to 196
what you require. Here we've got a CloudWatch insights of a DynamoDB 197
table and here we can see we've got a most or the most accessed items and we 198
see a good line graph of that, and we can clearly identify at what time what items 199
were most accessed, and also the most throttled items. So again we can see what 200
areas of this Dynamodb table are under load as such and we might be able to 201
make some changes to our schema or make some changes to our infrastructure to 202
accommodate that. CloudWatch subscriptions allow a Kinesis stream or 203
the Kinesis data firehose or AWS lambda to subscribe to a real-time feed of log 204
events from CloudWatch logs. It achieves this by having you define a subscription 205
filter which defines which events are to be delivered to that subscribed service 206
and then you define the ARN or the amazon resource number for that 207
particular resource be it a Kinesis stream or lambda or whatever it is. Another 208
really good feature of subscriptions is that you can create an IAM role that 209
will allow log data from other AWS accounts to be subscribed to as well. 210
You could have one account with a Kinesis stream or a data Firehose 211
delivering it to s3 or whatever. It is receiving a real-time feed from multiple 212
AWS accounts. The data in CloudWatch logs can be 213
encrypted at rest by simply associating an AWS key management service or kms 214
customer master key with a particular log group, and so any logs or any log 215
streams that are associated with that log group will be encrypted at rest 216
with that kms master key. Identity based IAM policies can be used to restrict 217
access from an IAM entity to log groups log streams or destinations for 218
CloudWatch logs. So this entity could be a user or a group in your account but it 219
also could be someone who has permissions that has been granted to 220
them through a role, and by doing that they may be able to access your data 221
securely, with the permissions defined, from another account. You can also have 222
resource based policies and they can be attached to the actual resources of 223
CloudWatch logs destinations that are defined in the CloudWatch subscription 224
service, and by doing that you're going to restrict access to that particular 225
resource by applying it to the actual resource itself. If the service that 226
you're collecting data from resides within a VPC or inside of a VPC you 227
can encrypt that data in transit between your VPC and the CloudWatch service by 228
using a VPC endpoint and that will allow for private communication between 229
those resources that you're monitoring inside of your VPC and the CloudWatch service. 230
So that brings us to the end of this lecture and I hope you enjoyed it 231
and I look forward to seeing you in the next one.