View my website:

Khi chạy workload trên EC2, CloudWatch mặc định chỉ cho mình một phần nhỏ bức tranh vận hành: CPU, network, disk I/O và status check. Nhưng trong thực tế DevOps/SRE, chỉ vậy là chưa đủ. Mình thường cần biết thêm memory đang dùng bao nhiêu, disk root còn trống không, process Nginx có còn chạy không, access log/error log có lỗi gì không, và khi vượt ngưỡng thì hệ thống có gửi cảnh báo hay không.

Bài lab này thực hành xây dựng một pipeline observability đơn giản nhưng thực tế cho EC2 theo hướng AWS-native bằng CloudWatch Agent.

Mình triển khai theo hai tình huống:

Case 1: EC2 đã có sẵn, đang chạy Nginx, nhưng chưa có CloudWatch Agent.

Case 2: Tạo EC2 mới từ đầu và bootstrap CloudWatch Agent bằng User Data.

Điểm quan trọng của bài không chỉ là “cài agent”, mà là đi hết flow:

EC2

→ CloudWatch Agent

→ CloudWatch Metrics

→ CloudWatch Logs

→ CloudWatch Dashboard

→ CloudWatch Alarm

→ Amazon SNS

→ Email Notification

Vì sao cần CloudWatch Agent?

EC2 basic monitoring mặc định chỉ quan sát instance từ bên ngoài, chủ yếu thông qua hypervisor. Vì vậy CloudWatch có thể thấy các metric như CPU, network, disk I/O và status check.

Tuy nhiên, các thông tin nằm bên trong operating system như memory đang dùng bao nhiêu, filesystem còn trống bao nhiêu, application log ghi gì, hoặc process Nginx còn chạy hay không thì CloudWatch không tự thấy được nếu chỉ dùng basic monitoring.

CloudWatch Agent giải quyết khoảng trống đó bằng cách chạy bên trong EC2 instance. Agent đọc metrics và logs từ hệ điều hành, sau đó gửi dữ liệu về CloudWatch Metrics và CloudWatch Logs.

Nói ngắn gọn:

EC2 basic monitoring

→ nhìn từ bên ngoài instance



CloudWatch Agent

→ nhìn được bên trong operating system

Đây là lý do các dữ liệu như memory usage, disk usage, application logs và process status cần CloudWatch Agent.

Kiến trúc tổng quan

Kết nối vào EC2 bằng Session Manager

Thay vì SSH, mình dùng AWS CLI từ máy local để kết nối vào EC2:

aws ssm start-session \

  --target <id-instance-ec2-của-bạn> \

  --region us-east-1

Ví dụ:

aws ssm start-session \

  --target i-xxxxxxxxxxxxxxxxx \

  --region us-east-1

Sau khi vào được EC2, chuyển sang quyền root để thao tác trong lab:

sudo su -

whoami

Kiểm tra OS và hostname:

hostname

cat /etc/os-release

Cách này giúp bài lab không cần mở SSH port 22 ra Internet.

Case 1: Cài CloudWatch Agent trên EC2 đã có sẵn

Bối cảnh

Ở case đầu tiên, mình giả định đã có một EC2 đang chạy workload Nginx. Instance này chưa từng cài CloudWatch Agent. Đây là tình huống khá thực tế: hệ thống đã chạy rồi, sau đó team DevOps/SRE muốn bổ sung observability mà không rebuild instance.

Flow thực hiện:

Existing EC2

→ Attach IAM Role

→ Kiểm tra SSM Managed Node

→ Kiểm tra Nginx đang chạy

→ Xác nhận CloudWatch Agent chưa cài

→ Cài CloudWatch Agent

→ Tạo CloudWatch Agent config

→ Start CloudWatch Agent

→ Kiểm tra Metrics và Logs

→ Tạo Alarm, SNS và Dashboard

Kiểm tra EC2 hiện tại

Instance dùng trong Case 1:

Instance name: cwagent-existing-ec2

Instance ID: i-004d22f414fe421f0

AMI: Amazon Linux 2023

Instance type: t3.micro

VPC: CW-Agent-Ec2-vpc

Subnet: Public subnet us-east-1a

IAM Role: ec2-cloudwatch-agent-role

Evidence:

Kiểm tra workload và trạng thái ban đầu

Sau khi kết nối vào EC2 bằng Session Manager, mình kiểm tra:

whoami

hostname

cat /etc/os-release

systemctl status nginx

rpm -qa | grep amazon-cloudwatch-agent

Kết quả:

User hiện tại: root

OS: Amazon Linux 2023

Nginx: active running

CloudWatch Agent: chưa được cài đặt

Evidence:

Điều này xác nhận đúng bối cảnh: EC2 đã có workload nhưng chưa có CloudWatch Agent.

Cài CloudWatch Agent

Cài package CloudWatch Agent trên Amazon Linux 2023:

sudo dnf install -y amazon-cloudwatch-agent

Kiểm tra package:

rpm -qa | grep amazon-cloudwatch-agent

ls -l /opt/aws/amazon-cloudwatch-agent/

Evidence:

Config này thu thập:

Metrics:

- mem_used_percent

- disk_used_percent

- cpu usage metrics

- Nginx process count qua procstat



Logs:

- /var/log/nginx/access.log

- /var/log/nginx/error.log

Phần quan trọng nhất của config là procstat và logs. procstat giúp CloudWatch Agent theo dõi process Nginx, còn phần logs giúp agent đọc log file trên EC2 và gửi lên CloudWatch Logs.

Ví dụ phần procstat:

{

  "procstat": [

    {

      "exe": "nginx",

      "measurement": [

        "pid_count",

        "cpu_usage",

        "memory_rss"

      ],

      "metrics_collection_interval": 60

    }

  ]

}

Ví dụ phần log collection cho Nginx access log:

{

  "file_path": "/var/log/nginx/access.log",

  "log_group_name": "/ec2/cloudwatch-agent/case1/nginx/access",

  "log_stream_name": "{instance_id}-access",

  "timezone": "UTC"

}

Mình không inline toàn bộ JSON config để bài viết gọn hơn, nhưng vẫn đưa các phần cốt lõi vào bài để người đọc hiểu agent đang collect gì. Full config nằm trong thư mục scripts/ để có thể copy và chạy lại.

Evidence:

Kiểm tra CloudWatch Metrics

Sau khi agent chạy, vào CloudWatch Metrics và tìm namespace:

CWAgent

Các metric chính được kiểm tra:

mem_used_percent

disk_used_percent

procstat_lookup_pid_count

Ý nghĩa:

mem_used_percent

→ phần trăm memory đang sử dụng.



disk_used_percent

→ phần trăm disk đã dùng ở filesystem `/`.



procstat_lookup_pid_count

→ số lượng process Nginx được CloudWatch Agent tìm thấy.

Vì sao Nginx Process Count có thể lớn hơn 1?

Metric procstat_lookup_pid_count cho biết số process Nginx mà CloudWatch Agent tìm thấy.

Với Nginx, giá trị này thường lớn hơn 1 vì Nginx thường chạy theo mô hình:

1 master process

+ N worker processes

Ví dụ nếu dashboard hiển thị:

Nginx Process Count = 3

Điều đó có thể hiểu là Nginx đang có 1 master process và 2 worker processes. Vì vậy giá trị 3 không phải lỗi, mà là trạng thái bình thường khi Nginx đang chạy nhiều worker.

Evidence:

Kiểm tra CloudWatch Logs

CloudWatch Agent cũng gửi Nginx logs lên CloudWatch Logs.

Log groups chính:

/ec2/cloudwatch-agent/case1/nginx/access

/ec2/cloudwatch-agent/case1/nginx/error

Nginx access log có request GET / HTTP/1.1, chứng minh log file trên EC2 đã được agent đọc và gửi lên CloudWatch Logs.

Evidence:

Sau đó tạo SNS topic và email subscription để nhận cảnh báo.

Evidence SNS:

Kết quả Case 1:

[✓] EC2 existing đang chạy workload Nginx

[✓] CloudWatch Agent được cài thủ công

[✓] Agent gửi metrics lên CloudWatch Metrics

[✓] Agent gửi logs lên CloudWatch Logs

[✓] Alarm được tạo và trigger

[✓] SNS gửi email notification

[✓] Dashboard hiển thị key metrics

Case 2: Bootstrap CloudWatch Agent khi tạo EC2 mới

Bối cảnh

Ở Case 2, mình không cài agent thủ công sau khi EC2 chạy nữa. Thay vào đó, mình dùng User Data để tự động:

Cài Nginx

→ Start Nginx

→ Cài CloudWatch Agent

→ Ghi CloudWatch Agent config

→ Start CloudWatch Agent

→ Tạo request test bằng curl localhost

Flow:

Launch new EC2

→ Attach IAM Role

→ User Data installs Nginx

→ User Data installs CloudWatch Agent

→ User Data writes config

→ User Data starts CloudWatch Agent

→ Verify Logs, Metrics and Dashboard

Chuẩn bị User Data

User Data script được lưu trong repo tại:

Kiểm tra CloudWatch Agent

Sau khi EC2 boot xong, mình kết nối vào instance bằng Session Manager và kiểm tra agent:

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a status

sudo systemctl status amazon-cloudwatch-agent

Evidence:

Kiểm tra CloudWatch Metrics

Trong namespace CWAgent, mình kiểm tra ba metrics chính của instance Case 2:

mem_used_percent

disk_used_percent

procstat_lookup_pid_count

Evidence:

Kết quả Case 2:

[✓] EC2 mới được tạo từ đầu

[✓] User Data chạy thành công

[✓] Nginx được cài và start tự động

[✓] CloudWatch Agent được cài và start tự động

[✓] Logs được gửi lên CloudWatch Logs

[✓] Metrics được gửi lên CloudWatch Metrics

[✓] Dashboard visualize được key metrics

So sánh hai cách triển khai

Case 1 phù hợp khi mình đã có hệ thống chạy sẵn và muốn thêm observability mà không thay đổi cách launch instance.

Case 2 phù hợp khi mình muốn chuẩn hóa việc tạo EC2 mới: instance vừa boot lên là đã có Nginx, CloudWatch Agent, logs, metrics và dashboard-ready.

Bài học rút ra

CloudWatch Agent là phần rất quan trọng nếu muốn quan sát EC2 sâu hơn basic monitoring.

Không có CloudWatch Agent, mình chủ yếu thấy các metric bên ngoài instance như CPU, network, disk I/O và status check. Có CloudWatch Agent, mình lấy thêm được:

Memory usage

Disk usage theo filesystem

Application logs

System logs

Process status

Custom metrics trong namespace CWAgent

Một điểm quan trọng nữa là IAM Role nên được dùng thay vì access key. EC2 có role phù hợp thì CloudWatch Agent tự dùng quyền đó để gửi metrics/logs lên CloudWatch.

Bài lab cũng cho thấy Session Manager là lựa chọn tốt hơn SSH trong môi trường lab hoặc production cơ bản, vì không cần mở port 22 ra Internet.

Cleanup

Sau khi hoàn thành lab, cần cleanup để tránh phát sinh chi phí. Ngoài việc xóa EC2, dashboard, alarm và SNS, cần chú ý cả CloudWatch Log Groups vì log group có thể giữ log lâu dài nếu không đặt retention policy.

Terminate EC2 Case 1 nếu chỉ dùng cho lab

Terminate EC2 Case 2

Delete CloudWatch Dashboards

Delete CloudWatch Alarms

Delete SNS Topic

Delete CloudWatch Log Groups nếu không cần giữ

Delete IAM Role nếu chỉ dùng cho lab

Có thể sử dụng file cleanup mẫu này để sử dụng: cleanup-file

Kết luận

Bài lab này xây dựng một observability pipeline AWS-native cho EC2 bằng CloudWatch Agent. Qua hai case, mình kiểm chứng được cả hai hướng triển khai:

Existing EC2

→ cài CloudWatch Agent thủ công

→ thêm observability cho workload đang chạy



New EC2

→ bootstrap bằng User Data

→ có observability ngay từ lúc launch

Khi kết hợp CloudWatch Agent với CloudWatch Metrics, CloudWatch Logs, Dashboard, Alarm và SNS, mình có thể tạo một hệ thống monitoring đơn giản, dễ hiểu, đủ thực tế cho môi trường DevOps cơ bản và có thể mở rộng tiếp cho các workload lớn hơn.