Amazon Aurora MySQL Bài 24: Tích hợp Amazon CloudWatch với Aurora MySQL để giám sát toàn diện hệ thống
Nếu Performance Insights (đã học ở Bài 23) là công cụ chuyên dụng để soi từng câu lệnh SQL chậm, thì Amazon CloudWatch chính là "bảng điều khiển trung tâm" (Dashboard & Alerting Center) giúp bạn giám sát toàn diện sức khỏe của cả cụm Aurora MySQL ở tầng hạ tầng và ứng dụng.
Bài viết này sẽ mổ xẻ cách thiết lập hệ thống giám sát và cảnh báo tự động chuẩn Enterprise cho Aurora MySQL.
1. Các Metrics quan trọng nhất cần giám sát trên CloudWatch
Aurora cung cấp hàng chục thông số metrics khác nhau, nhưng đối với một Backend Engineer hoặc DevOps, bạn chỉ cần tập trung tuyệt đối vào 5 nhóm chỉ số cốt lõi sau:
-
a. Sức khỏe tính toán (CPU & Memory):
-
CPUUtilization: Tỷ lệ sử dụng CPU của Writer và các Reader. Cảnh báo đỏ nếu vượt quá 85% trong thời gian liên tục 5 phút. -
FreeableMemory: Lượng RAM còn trống thực tế. Tránh để chỉ số này sụt giảm quá thấp dẫn đến hiện tượng treo hệ thống.
-
-
b. Tải lưu trữ và I/O (Storage & I/O):
-
VolumeBytesUsed: Tổng dung lượng thực tế đang được sử dụng trên Aurora Storage Volume (giúp kiểm soát tốc độ tăng trưởng dữ liệu). -
VolumeReadIOPS/VolumeWriteIOPS: Số lượng yêu cầu đọc/ghi I/O trên giây.
-
-
c. Tải kết nối (Connections):
DatabaseConnections: Số lượng kết nối đồng thời đang mở vào cơ sở dữ liệu. Cần theo dõi sát để tránh vượt quá giới hạnmax_connectionscấu hình trong Parameter Group, gây ra lỗiToo many connectionscho ứng dụng backend.
-
d. Độ trễ Replication (High Availability):
AuroraReplicaLag: Độ trễ tính bằng mili-giây giữa Writer và các Read Replicas.
2. Thiết lập CloudWatch Alarms & SNS Notification (Cảnh báo tự động)
Giám sát thụ động (vào mở dashboard xem) là chưa đủ. Hệ thống Production bắt buộc phải có cơ chế cảnh báo chủ động đẩy thẳng về Slack, Telegram hoặc Email của đội ngũ kỹ thuật khi có sự cố.
Dưới đây là đoạn script Terraform mẫu để thiết lập CloudWatch Alarm cảnh báo khi CPU của Aurora Writer vượt quá ngưỡng nguy hiểm:
Terraform
# 1. Tạo SNS Topic để nhận thông báo sự cố
resource "aws_sns_topic" "db_alerts_topic" {
name - "aurora-database-alerts"
}
# 2. Cấu hình CloudWatch Alarm cho CPU Utilization quá cao
resource "aws_cloudwatch_metric_alarm" "aurora_high_cpu" {
alarm_name - "hieu-aurora-high-cpu-alarm"
comparison_operator - "GreaterThanThreshold"
evaluation_periods - 2
metric_name - "CPUUtilization"
namespace - "AWS/RDS"
period - 300 # Đánh giá trong chu kỳ 5 phút
statistic - "Average"
threshold - 85 # Ngưỡng cảnh báo 85%
alarm_description - "Cảnh báo: CPU của Aurora Writer đang vượt mức 85% trong 10 phút liên tục!"
alarm_actions - [aws_sns_topic.db_alerts_topic.arn]
dimensions = {
DBClusterIdentifier = aws_rds_cluster.aurora_cluster.id
Role = "WRITER"
}
}
3. Aurora Advanced Auditing & CloudWatch Logs
Bên cạnh Metrics, việc ghi lại log hoạt động của database là yêu cầu bắt buộc đối với các hệ thống tài chính, thương mại điện tử (tuân thủ bảo mật).
-
Audit Logs: Bạn có thể cấu hình Aurora xuất toàn bộ log truy vấn (
General logs,Error logs,Slow query logs, vàAudit logs) trực tiếp sang Amazon CloudWatch Logs. -
Phân tích log: Kết hợp CloudWatch Logs Insights để truy vấn nhanh các hành vi đăng nhập bất thường, các câu lệnh SQL thực thi quá chậm (vượt ngưỡng
long_query_time), hoặc các lỗi hệ thống phát sinh trong đêm.
4. Góc nhìn vận hành cho Backend Engineer
-
Tránh "Alert Fatigue" (Bội thực cảnh báo): Đừng tạo quá nhiều alarm nhỏ nhặt cho những biến động tạm thời (ví dụ CPU vọt lên 90% trong 10 giây rồi xuống ngay). Hãy cấu hình khoảng thời gian đánh giá (
evaluation_periodsvàperiod) hợp lý để đảm bảo chuông chỉ reo khi hệ thống thực sự gặp sự cố cần con người can thiệp. -
Tích hợp ChatOps: Kết nối SNS Topic với Lambda hoặc webhook của Telegram/Slack để đội ngũ backend nhận được thông báo lỗi kèm theo tên cụm database ngay tức khắc, giúp rút ngắn thời gian phản hồi sự cố (
MTTR - Mean Time To Resolution).
All rights reserved