Day 9: Amazon CloudWatch – Metrics, Logs, Alarms, and Dashboards
Day 9 of my 90-day AWS challenge: how Amazon CloudWatch collects metrics and logs, how alarms notify you when something goes wrong, and how I set up an alarm and a dashboard to monitor my resources.
Recap of Day 8
Yesterday I created my first Lambda function and checked its logs. Those logs lived in Amazon CloudWatch, the service I'm exploring today.
What is Amazon CloudWatch?
CloudWatch is AWS's monitoring and observability service. It collects metrics (numbers like CPU usage), logs (text output from your apps and services), and events, so you can see what is happening and react when something goes wrong.
Key concepts
| Concept | What it is |
|---|---|
| Metric | A time-ordered set of data points, e.g. EC2 CPUUtilization |
| Namespace | A container for metrics, e.g. AWS/EC2 or AWS/Lambda |
| Dimension | A label that identifies what a metric belongs to, e.g. an instance ID |
| Log group and log stream | A log group holds related logs, and each source writes to its own stream inside it |
| Alarm | Watches a metric and triggers an action when it crosses a threshold |
| Dashboard | A customizable page that shows graphs of your metrics in one place |
Alarm states
- OK: the metric is within the threshold
- ALARM: the metric has crossed the threshold
- INSUFFICIENT_DATA: not enough data yet to decide
An alarm can send a notification through Amazon SNS (email or SMS), or trigger an action such as stopping an EC2 instance.
Good to know
- AWS services publish many metrics automatically, such as EC2 CPU, S3 request counts, and Lambda invocations
- Memory and disk usage on EC2 are not collected by default; they need the CloudWatch agent
- Log groups keep logs forever by default, so set a retention period to control cost
- CloudTrail is different: it records who did what through API calls (auditing), while CloudWatch tracks how things are performing
What I practiced today
- Opened the Lambda function's log group and read the output from my test run
- Viewed an EC2 CPU metric graph in the metrics explorer
- Created an alarm with an SNS email notification
- Built a simple dashboard with a few widgets
- Set a retention period on my log group
Connecting back to Day 1
The billing alert I set up on Day 1 is built on CloudWatch alarms too. It watches the estimated charges metric and notifies me before costs grow.
Key takeaways
- Monitoring is not optional: set alarms before problems happen
- Set log retention to avoid paying to store old logs forever
- Use CloudWatch for performance and CloudTrail for auditing
Up next: Day 10
Elastic Load Balancing and Auto Scaling: handling more traffic automatically.
Learning AWS too? Follow along and share what you're building. #90DaysOfAWS
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article