Ngôn ngữ hiển thị:
Ngôn ngữ hiển thị:
ChatBot AILúc 2 giờ sáng, điện thoại bạn rung lên — không phải tin nhắn bạn bè, mà là khách hàng báo web chết. Bạn mở laptop, đăng nhập AWS, mới phát hiện CPU EC2 đã chạy 100% từ... 6 tiếng trước. Không có ai cảnh báo. Không có gì báo hiệu. Bạn chỉ biết khi mọi thứ đã sập. Đây không phải chuyện hiếm — và AWS CloudWatch chính là thứ ngăn bạn rơi vào tình huống đó.
AWS CloudWatch là dịch vụ giám sát và quan sát (observability) của Amazon Web Services. Hiểu đơn giản: nó như một "trung tâm điều phối" liên tục đo đạc mọi thứ đang xảy ra trong hạ tầng AWS của bạn — từ CPU của EC2, dung lượng RDS, số request vào Load Balancer, đến log của Lambda function.
CloudWatch thu thập metrics (số liệu định lượng như CPU%, network bytes), logs (nhật ký hệ thống/ứng dụng), và events (sự kiện thay đổi trạng thái). Từ đó bạn có thể vẽ dashboard, đặt ngưỡng cảnh báo (Alarm), và kích hoạt hành động tự động khi vượt ngưỡng.
Tại sao quan trọng lúc này? Năm 2026, chi phí downtime trung bình với doanh nghiệp vừa là ~$5,600/phút theo Gartner. Với một startup, mất 30 phút không có ai biết server đang hấp hối là đủ để mất khách. CloudWatch cho phép bạn biết trước khi khách hàng biết — và đó là lợi thế sống còn.
Trước khi vào hướng dẫn thực tế, hãy nắm chắc ba thứ này — không hiểu rõ thì thiết lập xong cũng không biết mình đang làm gì:
CPUUtilization của EC2 là metric mặc định, được ghi mỗi 5 phút (1 phút nếu bật detailed monitoring). Bạn cũng có thể tự tạo custom metric bằng AWS SDK hoặc CloudWatch Agent.OK sang ALARM và kích hoạt hành động — gửi thông báo, scale EC2, hoặc chạy Lambda.
Ví dụ thực tế: bạn muốn nhận email khi CPU của EC2 vượt 80% trong 10 phút liên tiếp.
Bước 1 — Tạo SNS Topic: Vào AWS Console → SNS → Topics → Create topic. Chọn Standard, đặt tên (ví dụ alert-high-cpu). Sau khi tạo xong, nhấn "Create subscription": Protocol chọn Email, nhập địa chỉ email. AWS sẽ gửi email xác nhận — bạn phải nhấn Confirm trong mail đó, nếu không SNS không gửi được.
Bước 2 — Tạo CloudWatch Alarm: Vào CloudWatch → Alarms → Create alarm → Select metric. Chọn EC2 → Per-Instance Metrics → tìm instance của bạn, chọn CPUUtilization. Tiếp theo:
Average5 minutesGreater than 802 out of 2 (tức CPU > 80% trong 2 lần đo liên tiếp = 10 phút)Bước 3 — Gắn SNS Topic: Phần "Notification", chọn "In alarm" → Send notification to → chọn SNS topic alert-high-cpu. Đặt tên alarm (ví dụ EC2-HighCPU-Alert), tạo xong.
Mẹo xương máu: Luôn set "Datapoints to alarm" ít nhất 2/2 thay vì 1/1. CPU đôi khi spike 1-2 giây rồi về bình thường — nếu alarm ngay lần đầu bạn sẽ bị spam thông báo giả suốt ngày và dần quen với việc bỏ qua, đến khi có sự cố thật thì không ai để ý nữa.
Email đôi khi bị bỏ qua. Telegram thì khác — thông báo hiện ngay trên điện thoại, không vào spam. Cách kết nối SNS với Telegram:
@BotFather, lấy BOT_TOKEN. Tạo group/channel, thêm bot vào, lấy CHAT_ID bằng cách gọi https://api.telegram.org/bot/getUpdates .import json, urllib.request, os
BOT_TOKEN = os.environ["TELEGRAM_BOT_TOKEN"]
CHAT_ID = os.environ["TELEGRAM_CHAT_ID"]
def lambda_handler(event, context):
for record in event["Records"]:
msg = record["Sns"]["Message"]
subject = record["Sns"].get("Subject", "AWS Alert")
text = f"🚨 *{subject}*
{msg}"
payload = json.dumps({
"chat_id": CHAT_ID,
"text": text,
"parse_mode": "Markdown"
}).encode()
req = urllib.request.Request(
f"https://api.telegram.org/bot{BOT_TOKEN}/sendMessage",
data=payload,
headers={"Content-Type": "application/json"}
)
urllib.request.urlopen(req)
Set Environment Variables TELEGRAM_BOT_TOKEN và TELEGRAM_CHAT_ID trong Lambda configuration. Đảm bảo Lambda có execution role với quyền cơ bản (AWSLambdaBasicExecutionRole).
AWS Lambda → chọn Lambda function vừa tạo.Từ giờ, mỗi khi Alarm kích hoạt, SNS gửi đến Lambda, Lambda forward ngay vào Telegram của bạn.
Vài lỗi mình từng thấy người mới mắc phải khi thiết lập CloudWatch:
Confirmed, không phải Pending confirmation.mem_used_percent. Nhiều người ngồi tìm metric RAM mà không thấy vì nghĩ nó tự động có.Q: CloudWatch Free Tier có dùng được thực tế không?A: Được, nhưng có giới hạn rõ: 10 custom metrics, 10 alarms, 3 dashboards (50 metric/dashboard), 5GB log ingestion/tháng. Cho startup nhỏ hoặc cá nhân là đủ. Scale lên thì tính thêm — alarm thứ 11 trở đi tốn $0.10/alarm/tháng.
Q: Có cần cài gì thêm vào EC2 không?A: Metrics mặc định (CPU, network, disk I/O) không cần cài gì. Nhưng để có Memory, disk space usage, hoặc log từ ứng dụng, bạn cần cài CloudWatch Agent lên EC2. Agent này miễn phí, chỉ tính phí cho data nó gửi lên.
Q: CloudWatch vs Datadog/Grafana — nên dùng gì?A: Nếu toàn bộ stack trên AWS và team nhỏ, CloudWatch đủ dùng và tích hợp native không cần setup phức tạp. Datadog/Grafana mạnh hơn về visualization và cross-cloud monitoring, nhưng thêm một lớp dependency và chi phí. Bắt đầu CloudWatch, outgrow mới migrate.
CloudWatch Alarm không phải thứ "khi nào rảnh làm". Nó là thứ bạn thiết lập trước khi lên production — như đặt báo thức trước khi ngủ, không phải sau khi ngủ quên. Mất 15 phút hôm nay để cấu hình, đổi lấy sự yên tâm những đêm sau. Bài tiếp theo sẽ đào sâu vào AWS Cost Explorer — vì biết server đang sập là một chuyện, biết mình đang đốt tiền AWS ở đâu lại là chuyện khác.
