Please note that this content is targeted for SysOps administrators. If 1
you're a Solutions Architect or a developer you may want to skip over this 2
one. 3
Welcome back to BackSpace Academy if you're a system administrator you're 4
not only going to be heavily involved in troubleshooting services when they go 5
wrong you're also going to be expected to implement systems that can alert you 6
to problems and also not only alert you to problems but also invoke other 7
services that may be able to correct that problem. So we'll go through and 8
have a look at one of the most important of those services being the ec2 service 9
and we'll look at the CloudWatch of metrics that are available we'll also 10
look at the custom metrics different metrics that we can implement that are 11
not standard within CloudWatch we can look at CloudWatch statistics and that 12
will provide us aggregate data of those metrics that are being recorded we'll 13
look at the different types of actions that are available from a CloudWatch 14
alarm and then finally we'll look at elastic load balancer monitoring as well 15
the standard ec2 CloudWatch metrics that are available to us for our t2 16
burstable instances we can keep track of our credit usage and credit balance to 17
make sure that we still always have available that ability to burst when 18
required, For general instance metrics we have CPU utilization we have Disk I/O and 19
network information that we can monitor it as a metrics and we also have our 20
status checks that we can monitor as a metric as well. CloudWatch metrics they 21
can be filtered using a dimension so for example if you wanted to just get the 22
metrics for all of the instance within a specific auto scaling group you can use 23
the auto scaling group name or you can use the image ID the instance ID or the 24
instance type and the available metrics I will be listed in the CloudWatch 25
console but you can also use a command-line interface by using the 26
CloudWatch list metrics command to list those as well detailed monitoring 27
that can be enabled and that will enable one minute interval of your CloudWatch 28
metrics and you can do that at launch or you can do it we 29
existing instances also using the ec2 console but you can also use a 30
command-line interface so when you're doing an ec2 run instances command you 31
can have monitoring enabled equals equals true for detailed monitoring or 32
you if you're doing the easy to monitor instances command on an existing 33
instance that can be done as well it is possible to create your own custom 34
metrics and they can be collected and published to CloudWatch from your ec2 35
instances and you can do that using the CloudWatch put metric data command in 36
the CLI or if you're using an SDK and you can have an application running on 37
your ec2 instance you can use put metric data and that will enable you to publish 38
that information to CloudWatch and cloud what you will collect and monitor 39
that for you you can have that at standard resolution of one minute or up 40
to high resolution of one second they are also available CloudWatch 41
monitoring scripts and they are again custom metrics and they will run Perl 42
scripts on your ec2 instances and they can collect memory swap and disk space 43
utilization data if you would like to have a that they monitored on a regular 44
basis you can create a cron job and that will publish that at regular intervals 45
to the CloudWatch service and from there you can view that information as 46
you would any other CloudWatch metric a lot of times it is not really beneficial 47
to look at instantaneous metrics and see what's going on there but we might want 48
to look at what the aggregation of that data is over a specific period of time 49
so we can look at the minimum or maximum levels that have that have occurred over 50
that period of time we can look at the sum of all of the values that were 51
submitted during that period from all of the samples that were taken and we can 52
also look at the number of counts all these sample accounts which is a number 53
of samples that received over that period and the average which will of 54
course be the sum the total of all those values divided by the number of 55
of samples all that's divided by the sample count also we can have a look at 56
the specific the specified percentile so review if we've got there a percentile 57
of 95.45 that means that 95.45% 58
of all of the data collected will be lower than this value if we did 59
94 would be 94% of that data is below this value 60
so we can select a specific percentile and report our metrics based upon that 61
one of the great features of using cloud watch with the ec2 service is being able 62
to use alarm actions and they can automatically stop terminate reboot or 63
recover our instances for us we don't need to intervene in any way it will 64
automatically happen once it's set up so they can be created using or the ec2 or 65
the CloudWatch console and there are a number of use cases that are very good 66
that we could use for this feature we could use it to stop idle instances that 67
are not really being used we can use it to stop web servers that are getting 68
unusually high traffic for example they're getting attacked we can look at 69
the network out and then we can also look at stopping in an instance that 70
is experiencing a memory leak, we can stop impaired systems that have failed 71
their status checks and we can terminate an instance when a job has been finished 72
for exact you might have a batch job to process a video and then you can 73
terminate that instance when it is completed so additional to monitoring at 74
ec2 instances we can also monitor our elastic load balancers out of the box we 75
have CloudWatch metrics and they will be reported at or monitored and reported 76
at sixty second or one-minute intervals additional to that we have access logs 77
so the elastic load balancer can publish a log file when it is enabled and that 78
will record log information from anywhere from five to sixty minute 79
intervals and those logs will be saved to Amazon s3 and we can access those if 80
we need to additional to access logs when they are 81
enabled. A feature of application ELBs, not classic ELBs, but just 82
application ELBs is that we can look at request tracing and that enables 83
us to track our HTTP request from our clients to our targets or other services 84
and it does that by adding or updating the trace ID header before sending it 85
back and that is integrated again with with the ELB access logs and finally we 86
can look at implementing CloudTrail on our elastic load balancer to log any API 87
calls to our load balancer. So that's all I need to discuss now from a high level 88
around monitoring of ec2 and ELB coming up next we'll have a hands-on session to 89
apply this stuff, so I'll see you in that one.