View my website: https://kkloudtarus.net/blog/aws-native-observability-ec2-cloudwatch-agent

Repo GitHub:https://github.com/ngoNguyenTruongAn/cloudwatch-agent-ec2-observability

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

Trong kiến trúc này, EC2 chạy workload Nginx và CloudWatch Agent. Agent chạy bên trong instance, đọc metrics ở cấp operating system, đọc log file của Nginx, sau đó gửi dữ liệu về CloudWatch.

Luồng chính:

User / Local terminal

→ AWS Systems Manager Session Manager

→ EC2 instance

→ CloudWatch Agent

→ CloudWatch Metrics / CloudWatch Logs

→ Dashboard / Alarm

→ SNS Email Notification

Mình không dùng SSH trong bài lab này. EC2 được truy cập bằng AWS Systems Manager Session Manager, giúp không cần mở port 22, không cần key pair, và quản lý quyền truy cập thông qua IAM.

Repository structure

Phần evidence, architecture và script nên được tách riêng để dễ review:

cloudwatch-agent-ec2-observability/

├── architecture/

│   └── high-level-architecture.jpg

│

├── evidence/

│   ├── Case 1 - Existing EC2 Running.jpg

│   ├── Case 1 - IAM Role Attached.jpg

│   ├── Case 1 - SSM Managed Node.jpg

│   ├── Case 1 - CloudWatch Agent Installed.jpg

│   ├── Case 1 - Agent Running.jpg

│   ├── Case 1 - CWAgent Metrics.jpg

│   ├── Case 1 - CloudWatch Logs.jpg

│   ├── Case 1 - CloudWatch Alarm.jpg

│   ├── Case 1 - SNS Email Confirmed.jpg

│   ├── Case 1 - CloudWatch Dashboard.jpg

│   ├── Case 2 - New EC2 Running.jpg

│   ├── Case 2 - Agent Running.jpg

│   ├── Case 2 - Key CWAgent Metrics.jpg

│   ├── Case 2 - CloudWatch Log Groups.jpg

│   └── Case 2 - CloudWatch Dashboard.jpg

│

├── scripts/

│   ├── case1-cloudwatch-agent-config.json

│   ├── case2-user-data.sh

│   └── cleanup.md

│

├── 01-cloudwatch-agent-lab-evidence.md

└── 01-aws-native-observability-for-ec2-with-cloudwatch-agent.md

File blog này chỉ giải thích flow và kết quả chính. Phần config dài của CloudWatch Agent và User Data được đặt trong thư mục scripts/ để dễ tái sử dụng.

Các AWS service sử dụng

Chi phí và Log Retention

CloudWatch Agent có thể phát sinh chi phí tùy theo số lượng custom metrics, số lượng log events, thời gian lưu logs và tần suất thu thập metrics.

Trong bài lab này, các metric như memory, disk và Nginx process count được gửi vào namespace CWAgent. Đây là custom metrics, vì vậy chi phí sẽ phụ thuộc vào số lượng metric, số lượng dimension và thời gian lưu trữ/quan sát.

Mình đặt metrics_collection_interval là 60 giây để cân bằng giữa độ chi tiết và chi phí:

metrics_collection_interval: 60

Nếu giảm interval xuống 10 giây, dữ liệu sẽ chi tiết hơn nhưng số lượng datapoint tăng lên, từ đó có thể làm tăng chi phí CloudWatch. Vì vậy trong lab hoặc môi trường nhỏ, 60 giây là lựa chọn hợp lý hơn.

Với CloudWatch Logs, nếu không cấu hình retention, log group có thể giữ log vô thời hạn. Vì vậy sau khi log group được tạo, nên đặt retention policy để tránh lưu log không cần thiết.

Ví dụ đặt retention 7 ngày cho Case 1:

aws logs put-retention-policy \

  --log-group-name "/ec2/cloudwatch-agent/case1/nginx/access" \

  --retention-in-days 7 \

  --region us-east-1

aws logs put-retention-policy \

  --log-group-name "/ec2/cloudwatch-agent/case1/nginx/error" \

  --retention-in-days 7 \

  --region us-east-1

Ví dụ đặt retention 7 ngày cho Case 2:

aws logs put-retention-policy \

  --log-group-name "/ec2/cloudwatch-agent/case2/nginx/access" \

  --retention-in-days 7 \

  --region us-east-1

aws logs put-retention-policy \

  --log-group-name "/ec2/cloudwatch-agent/case2/nginx/error" \

  --retention-in-days 7 \

  --region us-east-1

Trong production, retention nên được chọn theo nhu cầu audit, compliance và chi phí, ví dụ 7 ngày, 14 ngày, 30 ngày hoặc lâu hơn.

Chuẩn bị IAM Role cho EC2

CloudWatch Agent cần quyền để gửi metrics và logs về CloudWatch. EC2 cũng cần quyền để làm việc với Systems Manager Session Manager.

Mình tạo IAM Role cho EC2:

ec2-cloudwatch-agent-role

Attach hai managed policies:

CloudWatchAgentServerPolicy

AmazonSSMManagedInstanceCore

Ý nghĩa:

CloudWatchAgentServerPolicy

→ Cho phép CloudWatch Agent gửi metrics/logs lên CloudWatch.



AmazonSSMManagedInstanceCore

→ Cho phép EC2 xuất hiện trong Systems Manager và truy cập bằng Session Manager.

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:

EC2 cũng đã xuất hiện trong AWS Systems Manager Managed Nodes với trạng thái Online.

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:

Tạo CloudWatch Agent config

File config được đặt tại:

/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json

Full config được lưu trong repo tại: Case 1 - File Agent Config

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:

Start CloudWatch Agent

Start agent với config vừa tạo:

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \

  -a fetch-config \

  -m ec2 \

  -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json \

  -s

Kiểm tra trạng thái:

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

sudo systemctl status amazon-cloudwatch-agent

Kết quả mong đợi:

{

  "status": "running",

  "configstatus": "configured",

  "version": "1.300067.1"

}

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:

Tạo CloudWatch Alarm và SNS Email

Sau khi có metric memory, mình tạo CloudWatch Alarm trên metric:

Metric: mem_used_percent

Namespace: CWAgent

Condition: Greater than threshold

Action: Send notification to SNS topic

Trong lab, threshold được đặt thấp để dễ trigger alarm và lấy evidence. Với môi trường production, threshold nên đặt theo baseline thực tế, ví dụ khoảng 80% hoặc 85%.

Ngoài threshold, khi cấu hình alarm cần chú ý thêm các tham số sau:

Nếu dùng cấu hình 1 out of 1 datapoint, alarm phản ứng nhanh nhưng dễ bị false alarm khi có spike ngắn.

Trong production, nên dùng nhiều evaluation periods hơn, ví dụ:

Period: 5 minutes

Evaluation periods: 3

Datapoints to alarm: 2 out of 3

Cấu hình này giúp giảm false alarm do spike tạm thời.

TreatMissingData cũng rất quan trọng. Nếu CloudWatch Agent ngừng gửi metric, alarm có thể chuyển sang hoặc bị kẹt ở trạng thái INSUFFICIENT_DATA, tùy cách cấu hình. Đây là một tình huống vận hành thực tế cần tính đến khi thiết kế monitoring.

Evidence alarm:

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

Evidence SNS:

Khi alarm chuyển trạng thái, email notification được gửi về mailbox. Đây là phần chứng minh alerting flow hoạt động end-to-end:

CloudWatch Metric

→ CloudWatch Alarm

→ SNS Topic

→ Email Notification

Tạo CloudWatch Dashboard

Dashboard giúp visualize các metrics quan trọng của EC2.

Dashboard name:

cwagent-existing-ec2-dashboard

Metrics hiển thị:

Memory Used Percent

Nginx Process Count

Disk Used Percent

Evidence:

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: Case 2 - User Data

Script này sẽ được copy vào phần:

EC2 Launch Instance

→ Advanced details

→ User data

User Data là phần cốt lõi của Case 2 vì nó giúp EC2 mới tự bootstrap observability ngay khi launch, thay vì phải SSH/SSM vào máy rồi cài thủ công.

Ý tưởng chính của User Data:

dnf update

→ install nginx

→ install amazon-cloudwatch-agent

→ enable/start nginx

→ write CloudWatch Agent config

→ start CloudWatch Agent

→ verify status

Một phần quan trọng của User Data:

#!/bin/bash

set -euxo pipefail



dnf update -y

dnf install -y nginx amazon-cloudwatch-agent



systemctl enable nginx

systemctl start nginx



echo "Bootstrap EC2 for CloudWatch Agent lab" > /usr/share/nginx/html/index.html



curl http://localhost || true

curl http://localhost || true

curl http://localhost || true

Đoạn trên đảm bảo EC2 mới được cài Nginx, start service và tự tạo một vài request test để sinh Nginx access log.

Phần tiếp theo trong User Data là ghi CloudWatch Agent config vào đúng đường dẫn trên EC2:

cat > /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json <<'EOF'

{

  "agent": {

    "metrics_collection_interval": 60,

    "run_as_user": "root"

  },

  "metrics": {

    "namespace": "CWAgent",

    "append_dimensions": {

      "InstanceId": "${aws:InstanceId}"

    }

  }

}

EOF

Trong file đầy đủ, phần config còn có thêm mem, disk, cpu, procstat và log collection cho Nginx/system logs. Mình chỉ inline một đoạn ngắn để người đọc hiểu User Data đang làm gì, còn full script được lưu trong thư mục scripts/.

Cuối cùng, User Data start CloudWatch Agent bằng lệnh:

/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \

  -a fetch-config \

  -m ec2 \

  -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json \

  -s



systemctl enable amazon-cloudwatch-agent

systemctl restart amazon-cloudwatch-agent

Lệnh này giúp CloudWatch Agent đọc config vừa tạo và bắt đầu gửi metrics/logs lên CloudWatch ngay sau khi EC2 boot xong.

Launch EC2 mới

Instance dùng trong Case 2:

Instance name: cwagent-bootstrap-ec2

Instance ID: i-0dd7183a3899a9462

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 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:

Điều này chứng minh User Data đã tự động cài và start CloudWatch Agent khi EC2 được launch.

Kiểm tra CloudWatch Logs

Case 2 tạo các log groups riêng:

/ec2/cloudwatch-agent/case2/nginx/access

/ec2/cloudwatch-agent/case2/nginx/error

/ec2/cloudwatch-agent/case2/system/cloud-init

/ec2/cloudwatch-agent/case2/system/dnf

Nginx access log có request từ curl http://localhost, còn Nginx error log có startup logs của Nginx. Đây là chứng minh cho việc User Data đã chạy thành công và agent đã gửi logs lên CloudWatch.

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ả này chứng minh EC2 mới được bootstrap bằng User Data đã tự động gửi metrics lên CloudWatch.

Tạo Dashboard cho Case 2

Dashboard name:

cwagent-bootstrap-ec2-dashboard

Widget hiển thị:

Memory Used Percent

Nginx Process Count

Disk Used Percent

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.