Log files are probably the most well-known way of monitoring systems. They are a great complement to metrics, as they provide more flexibility. Because you aren't limited to a key-value pair system, like our metrics, you can use log files to provide very detailed information on events happening in your application. For instance, you may capture, through your metric system, an increase in the error rate of your application, but to know what exactly is happening, you will want to access your application logs to see whether there are exceptions, stack traces, or error messages that can help you troubleshoot that issue. The downside of logs is that they are much bigger than metrics. This means that they are more expensive to store, but also harder to index, search, and aggregate.

CloudWatch logs are organized around a few key concepts:

• Each log is called a log event and contains a raw message and a timestamp.
• The logs events produced by a unique source are grouped into a log stream.
• Log streams send their log event to log groups. Each log group has its own policy in terms of data retention (how many days you want to keep your log event for, who can access those logs, and so on).

As an example of that, we can retrieve the events produced by our CodeBuild execution logs:

1. In your browser, open the CloudWatch service at https://console.aws.amazon.com/cloudwatch.
2. Clock on Logs in the left-hand side menu.
3. From there, you can see the different log groups. Select one of the /aws/codebuild/ groups to access the log streams.
4. Open one of the log streams to access the logs produced by CodeBuild.