Note – CloudWatch and CloudWatch Metrics – SCS-C02 Study Guide

Note

If you were trying to do this for a large number of instances in an automated fashion, then the best course of action would be to label those instances to get the CloudWatch agent with a particular tag and value – for example, CloudWatchAgent as the tag and the date as the value. This way, you could use the Specify instance tags option and look up the exact tag-value pair for the installation. If you only used the tag of CloudWatchAgent and didn’t use the date as the value, or if you used a value such as true, then you could run into a case where any instances where the agent had previously been installed would require you to re-install the agent, which could lead to metric or log disruption during the process.

1. Your next step is to scroll down to the Outputs options section of the page. You want the output from the run command to go to CloudWatch Logs rather than an S3 bucket, so uncheck the box labeled Enable an S3 bucket and then check the box labeled Enable CloudWatch Logs. You do not need to create a custom log group name, as the CloudWatch service will use default naming.
2. Once you have enabled the output of the run command, scroll down to the bottom of the page and press the orange Run button.

After pressing the Run button, you will be taken to a screen showing your command’s state. Initially, the command will be in the In Progress state. After a minute or two, you should see Success appear under Overall status.

Figure 8.12: CloudWatch command’s state screen

You can now go to the CloudWatch service and look at the log groups or the metrics for this specific instance. With the agent installed, you can customize which logs on the server are being captured. If this were a Linux web server running Apache, you could tell request CloudWatch agent, under the logs configuration, to gather the HTTPD log files and then send them back to CloudWatch Logs for safekeeping and analysis.

There are alternative ways to set up the CloudWatch Logs agent without using the Systems Manager runbook. You could upload the agent via the secure copy command, which allows you to copy files from a local source folder and a remote directory over a secure protocol. This is fine if you are doing it on a single instance, but once the agent is on the remote machine, you still need to go into the machine and hand-configure the settings manually. You could place the agent files in an S3 bucket where the EC2 roles would have read access to that bucket and, therefore, can pull down the agent file as part of a cloud initialization script. One of the differences between using the cloud-init process and the SSM process is that if something faltered during the cloud-init process, you would need to access the instance and will then have to perform the commands again remotely. This is in contrast to the SSM document, wherein the command(s) could quickly be rerun from either the CLI or the SSM console without needing to access the instance itself.

You just saw how to install a CloudWatch agent on an EC2 instance running Systems Manager Agent to quickly and easily configure the agent. You also learned that there are multiple ways to install the CloudWatch agent on an instance and reviewed some of the pros and cons of using those ways. In the next section, you will learn how to search through some of the logs you collect with CloudWatch.