Series CloudWatch #2: Bắt mạch hệ thống với Metrics & Cảnh báo (Alarms) trước khi quá muộn

Chào anh em đã quay lại với series CloudWatch!

Ở Bài 1, chúng ta đã thống nhất với nhau tư duy: "Đừng bao giờ để hệ thống chạy trong bóng tối". Hôm nay, chúng ta sẽ bắt tay vào việc thắp sáng hệ thống đó bằng hai công cụ cơ bản nhưng mạnh mẽ nhất của CloudWatch: Metrics (Chỉ số đo lường) và Alarms (Cảnh báo).

1. CloudWatch Metrics – Bắt mạch hệ thống

Trong thế giới AWS, mọi dữ liệu đo lường theo thời gian đều được gọi là Metric. Khi anh em tạo một con server (EC2) hay một Database (RDS), AWS sẽ tự động gắn sẵn các "ống nghe y tế" vào đó và đẩy dữ liệu về CloudWatch.

Để hiểu và tìm đúng Metric mình cần, anh em chỉ cần nhớ 3 từ khóa phân cấp này:

1. Namespace (Không gian tên): Giống như tên khoa/phòng ban trong bệnh viện. Ví dụ: AWS/EC2 (chứa các chỉ số của server), AWS/RDS (chứa chỉ số của Database).
2. Metric Name (Tên chỉ số): Tên của loại bệnh muốn khám. Ví dụ: CPUUtilization (Tỉ lệ dùng CPU), NetworkIn (Băng thông mạng đi vào).
3. Dimension (Chiều không gian): Lọc chính xác bệnh nhân nào. Ví dụ: Lọc theo InstanceId = i-1234567890abcdef0 để chỉ xem CPU của đúng con server chạy Backend API.

Cú lừa kinh điển dành cho người mới: "Ủa, sao không thấy RAM?" Khi anh em vào xem Metrics của con server EC2, anh em sẽ thấy CPU, thấy ổ cứng (Disk), thấy Mạng (Network). Nhưng tìm đỏ mắt sẽ không thấy chỉ số RAM (Memory). Tại sao? Vì AWS là người cho thuê nhà (Hypervisor), họ chỉ nhìn thấy các tài nguyên phần cứng bên ngoài (CPU, Network). Còn RAM là thứ bị hệ điều hành (Linux/Windows) bên trong quản lý rạch ròi, AWS không thể tự ý thò tay vào đọc được.

Để giải quyết, chúng ta phải cài một phần mềm nhỏ tên là CloudWatch Agent lên server. Lúc này, Agent sẽ đứng từ bên trong hệ điều hành, đọc thông số RAM và các chỉ số tùy chỉnh (Custom Metrics) rồi chủ động gửi báo cáo ngược về cho CloudWatch.

2. CloudWatch Alarms – Bác sĩ trực ban 24/7

Có Metrics rồi, chúng ta vẽ được biểu đồ rất đẹp. Nhưng chẳng lẽ anh em định ngồi nhìn màn hình biểu đồ đó 24 giờ một ngày?

Đó là lúc CloudWatch Alarms xuất hiện. Nó cho phép anh em đặt ra một "Ngưỡng" (Threshold). Nếu Metric vượt qua ngưỡng đó trong một khoảng thời gian nhất định, Alarm sẽ chuyển trạng thái và thực hiện hành động.

Một Alarm luôn nằm ở 1 trong 3 trạng thái:

• OK: Hệ thống bình thường, nhịp tim ổn định.
• ALARM: Chỉ số đã vượt ngưỡng nguy hiểm!
• INSUFFICIENT_DATA: Mất kết nối, không nhận được dữ liệu (Có thể server đã chết hẳn hoặc mất mạng).

Hành động (Actions) khi có biến: Khi trạng thái chuyển sang ALARM, nó không chỉ chớp chớp đỏ trên màn hình cho vui. Nó có thể gọi các dịch vụ khác để xử lý sự cố.

• Báo động (Notify): Thông qua dịch vụ AWS SNS, nó có thể bắn một tin nhắn cảnh báo thẳng vào kênh Slack/Telegram của team hoặc gửi Email cho anh em ("Sếp ơi, CPU đang 95% rồi!").
• Tự động phản ứng (Auto Scaling): Nếu API đang quá tải do lượng request đột biến, Alarm có thể ra lệnh cho hệ thống Auto Scaling tự động "đẻ" thêm 2 con server EC2 nữa để chia sẻ gánh nặng. Khi khách vãn, CPU giảm xuống báo OK, nó lại tự động tắt bớt server đi để tiết kiệm tiền. Đây là phép màu thực sự của Cloud Computing!

3. Thực hành: Tạo "còi báo động" chống nghẽn CPU

Hãy cùng nhau cấu hình một cảnh báo cơ bản nhất mà hệ thống Backend nào cũng cần có.

Tình huống: Báo động nếu CPU của Server Backend chạy Golang vượt mức 80% liên tục trong 5 phút.

Bước 1: Chọn Metric

1. Đăng nhập AWS Console, tìm kiếm và mở dịch vụ CloudWatch.
2. Ở thanh menu bên trái, chọn Alarms > All alarms > Bấm nút Create alarm.
3. Bấm Select metric. Chọn EC2 > Per-Instance Metrics.
4. Tìm ID con server của anh em, tích chọn vào ô CPUUtilization. Bấm Select metric.

Bước 2: Cài đặt Ngưỡng (Conditions)

1. Statistic: Chọn Average (Trung bình).
2. Period: Chọn 1 minute (Gom dữ liệu mỗi 1 phút/lần).
3. Ở phần Conditions, chọn Static (Ngưỡng cố định).
4. Thiết lập quy tắc: Greater/Equal (Lớn hơn hoặc bằng) 80.
5. Datapoints to alarm: Gõ 5 out of 5. (Nghĩa là phải lớn hơn 80% liên tục trong 5 phút mới báo động. Tránh trường hợp CPU giật lên 80% trong vài giây rồi xuống lại cũng bị báo động rác). Bấm Next.

Bước 3: Cấu hình Hành động (Actions)

1. Chọn Alarm state trigger là In alarm.
2. Ở phần Send a notification to, anh em có thể chọn Create new topic. Đặt tên là Backend-Alerts và nhập Email của anh em vào ô bên dưới. AWS sẽ dùng dịch vụ SNS để gửi mail cho anh em. Bấm Create topic.
3. Bấm Next, đặt tên cho Alarm (Ví dụ: Backend-CPU-High-Alert), bấm Next lần nữa để review và cuối cùng chọn Create alarm.

Vậy là xong! Hãy vào check email và bấm xác nhận đăng ký nhận cảnh báo từ AWS nhé.

Tổng kết Bài 2

Hôm nay anh em đã hiểu được cách nhịp tim của hệ thống lưu thông dưới dạng Metrics, và biết cách cắt cử một y tá Alarms túc trực 24/7 để báo động khi có biến.

Nhưng này, khi nhận được email cảnh báo CPU lên 95%, anh em làm gì tiếp theo? Cảnh báo chỉ cho ta biết "Hệ thống đang ốm", chứ không nói được "Tại sao ốm". Lỗi do code vòng lặp vô hạn (infinite loop) trong Golang? Hay do database Vitess bị lock table?

Để trả lời câu hỏi "Tại sao", chúng ta phải lục lại bệnh án. Và đó chính là chủ đề của Bài 3: CloudWatch Logs – Truy vết lỗi Backend phân tán như một thám tử. Cùng đón chờ ở bài tiếp theo nhé!