Basic monitoring và detailed monitoring cho EC2 instance
Hệ thống cần tự phát hiện sự cố thay vì chờ khách hàng báo lỗi; cơ chế này dựa trên CloudWatch metric được thu thập liên tục và CloudWatch alarm với ngưỡng (threshold) xác định.
Mỗi dịch vụ AWS gửi metric lên CloudWatch: CPU của EC2, số lần gọi của Lambda, CPU của một ECS service. Một alarm theo dõi một metric, so sánh với ngưỡng (threshold), và khi metric vượt ngưỡng trong số evaluation period đã cấu hình thì thực thi action: gửi thông báo tới SNS topic, thực thi scaling policy của Auto Scaling group, hoặc thực thi EC2 action.
Một điểm thường bị bỏ qua: theo mặc định, EC2 chỉ gửi metric mỗi 5 phút (basic monitoring, không tính phí); detailed monitoring gửi metric mỗi 1 phút và có tính phí. Chạy tình huống livestream hai lần, một lần tắt và một lần bật detailed monitoring:
Tại phút thứ 10, phiên livestream của MFTECH bắt đầu. CPU của Auto Scaling group web tăng đột biến trong khoảng 10 phút rồi giảm.
Chọn tình huống, sau đó chọn Chạy mô phỏng 30 phút. Chạy một lần khi tắt detailed monitoring và một lần khi bật để so sánh.
Lựa chọn metric phù hợp quan trọng tương đương lựa chọn ngưỡng. ECS service scale theo CPU của chính service đó (namespace AWS/ECS, dimension ClusterName, ServiceName). Với Lambda, vòng lặp gọi ngoài ý muốn có thể dùng hết concurrency của account; tài liệu Lambda khuyến nghị alarm báo khi concurrency hoặc số lần gọi tăng đột biến (ConcurrentExecutions, Invocations), vì recursive loop detection chỉ phát hiện vòng lặp qua SQS, S3, SNS, EventBridge custom event bus hoặc giữa các Lambda function.
- Yêu cầu dữ liệu metric theo chu kỳ 1 phút trên EC2: bật detailed monitoring (có tính phí), không cần triển khai thêm thành phần nào.
- Alarm = metric + ngưỡng + số datapoint + action.
- ECS scale theo CPU của service; Lambda nên có alarm trên ConcurrentExecutions.
Basic monitoring and detailed monitoring for EC2 instances
A system should detect incidents itself instead of waiting for customers to report them; this relies on continuously collected CloudWatch metrics and CloudWatch alarms with defined thresholds.
Each AWS service sends metrics to CloudWatch: EC2 CPU, Lambda invocations, the CPU of an ECS service. An alarm watches one metric, compares it with a threshold, and when the metric breaches the threshold for the configured number of evaluation periods it performs an action: sending a notification to an SNS topic, running a scaling policy of an Auto Scaling group, or performing an EC2 action.
A point that is often overlooked: by default, EC2 sends metrics only every 5 minutes (basic monitoring, free of charge); detailed monitoring sends metrics every 1 minute and is charged. Run the livestream scenario twice, once with detailed monitoring off and once with it on:
Tại phút thứ 10, phiên livestream của MFTECH bắt đầu. CPU của Auto Scaling group web tăng đột biến trong khoảng 10 phút rồi giảm.
Chọn tình huống, sau đó chọn Chạy mô phỏng 30 phút. Chạy một lần khi tắt detailed monitoring và một lần khi bật để so sánh.
Choosing the right metric matters as much as choosing the threshold. An ECS service scales on the CPU of the service itself (namespace AWS/ECS, dimensions ClusterName, ServiceName). With Lambda, an unintended invocation loop can use up the account’s concurrency; the Lambda documentation recommends an alarm that fires when concurrency or invocations spike (ConcurrentExecutions, Invocations), because recursive loop detection only detects loops through SQS, S3, SNS, EventBridge custom event buses or between Lambda functions.
- Metric data at a 1-minute period on EC2: enable detailed monitoring (charged), with no extra components to deploy.
- Alarm = metric + threshold + number of datapoints + action.
- ECS scales on the service’s CPU; Lambda should have an alarm on ConcurrentExecutions.