1.1K 60 100

Đã đăng vào Thứ Tư, 11:39 SA 6 phút đọc

Lab 8.6 - Thiết lập Alerting - Debug Alerting và Best Practices trong Production

Sau phần trước, chúng ta đã kiểm thử thành công toàn bộ vòng đời của Alert:

Inactive
    ↓
Pending
    ↓
Firing
    ↓
Resolved

Chúng ta đã tạo ra các tình huống thực tế:

Backend bị down.
API trả về HTTP 500.
Pod restart liên tục.
CPU tăng cao.

Tuy nhiên, trong môi trường Production, việc tạo được Alert chưa đủ.

Một hệ thống Alert tốt cần đảm bảo:

Alert đúng vấn đề.
Alert đúng thời điểm.
Alert gửi tới đúng người.
Không tạo quá nhiều cảnh báo gây nhiễu.

Nếu thiết kế Alert không tốt, DevOps có thể rơi vào tình trạng:

1000 Alerts / ngày
↓
Không ai đọc Alert nữa
↓
Bỏ qua cả Alert quan trọng

Hiện tượng này gọi là Alert Fatigue

1. Alert Fatigue là gì?

Alert Fatigue (mệt mỏi vì cảnh báo) xảy ra khi hệ thống gửi quá nhiều cảnh báo không cần thiết.

Ví dụ, mỗi ngày nhận:

CPU Warning
CPU Warning
CPU Warning
Memory Warning
Memory Warning
Pod Restart
CPU Warning

Sau một thời gian, DevOps sẽ có xu hướng:

Ignore Email.
Tắt Notification.
Không kiểm tra Alert nữa.

Kết quả:

Một sự cố thật sự xảy ra nhưng không ai phản ứng.

Nguyên tắc tạo Alert

Một Alert tốt phải trả lời được câu hỏi:

"Nếu Alert này xảy ra, tôi có cần hành động ngay không?"

Nếu câu trả lời là Không thì có thể Alert đó không cần tồn tại.

2. Alert nào nên tạo trong Production?

Không phải mọi Metric đều cần Alert.

Ví dụ:

Grafana có thể hiển thị:

CPU.
Memory.
Disk.
Network.

Nhưng không nhất thiết tất cả đều cần Alert.

Nhóm 1: Availability Alert

Đây là nhóm Alert quan trọng nhất.

Mục tiêu: Phát hiện hệ thống không phục vụ được người dùng.

Application Down

Ví dụ:

up{job="todo-api"} == 0

Ý nghĩa: Prometheus không scrape được ứng dụng.

Alert:

alert: TodoApiDown
severity: critical

Đây là Alert cần phản ứng ngay.

Kubernetes Pod Down

Ví dụ:

kube_pod_status_phase{
phase="Failed"
}

Phát hiện:

Pod Failed.
Container crash.

Nhóm 2: Error Rate Alert

Không phải lúc nào ứng dụng Down mới là lỗi.

Một ứng dụng có thể:

Pod Running

Service Running

Container Running

nhưng:

90% request trả về HTTP 500

Người dùng vẫn không sử dụng được.

Ví dụ:

rate(
http_server_requests_seconds_count{
status=~"5.."
}[5m]
)

Alert:

alert: HighHTTP5xxRate

severity: critical

Nhóm 3: Latency Alert

Người dùng thường cảm nhận vấn đề qua tốc độ phản hồi.

Ví dụ:

Bình thường:

50ms

Sau sự cố:

3000ms

Ứng dụng vẫn:

Running

nhưng trải nghiệm người dùng rất tệ.

Ví dụ:

(
rate(
http_server_requests_seconds_sum[5m]
)
/
rate(
http_server_requests_seconds_count[5m]
)
)
> 1

Ý nghĩa:

Latency trung bình:

> 1 giây

Nhóm 4: Resource Alert

CPU

CPU cao liên tục có thể gây:

Response chậm.
Request timeout.
HPA scale.

Ví dụ:

CPU > 90%

trong 10 phút

Memory

Memory nguy hiểm hơn CPU.

Nếu vượt giới hạn:

OOMKilled

Pod bị Kubernetes kill.

Ví dụ:

Memory > 90%

trong 5 phút

Nhóm 5: Kubernetes Stability Alert

Một hệ thống Production cần theo dõi sự ổn định của Pod.

Pod Restart

Ví dụ:

increase(
kube_pod_container_status_restarts_total[10m]
)
> 5

Phát hiện:

CrashLoopBackOff.
Exception.
Configuration Error.

Pending Pod

Ví dụ:

kube_pod_status_phase{
phase="Pending"
}

Nguyên nhân:

Thiếu CPU.
Thiếu Memory.
Node lỗi.

3. Severity trong Alert

Không phải Alert nào cũng quan trọng như nhau.

Thông thường chia thành:

Critical

Warning

Info

Critical

Cần xử lý ngay.

Ví dụ:

severity: critical

Ví dụ:

API Down.
Database Down.
HTTP 500 tăng mạnh.

Notification:

Email

Slack

PagerDuty

Warning

Cần theo dõi.

Ví dụ:

severity: warning

Ví dụ:

CPU 80%.
Memory 85%.
Latency tăng nhẹ.

Notification:

Slack

Info

Chỉ mang tính thông báo.

Ví dụ:

Deployment completed

Không cần gửi Notification.

4. Sử dụng Labels để phân loại Alert

Ví dụ:

labels:
  severity: critical
  team: backend
  service: todo-api

Khi Alert gửi tới Alertmanager: Thông tin này được sử dụng để routing.

Ví dụ:

 team=backend
        ↓
Backend Team nhận

5. Routing Alert trong Alertmanager

Trong Production thường có nhiều team:

Backend Team

Frontend Team

Database Team

Infrastructure Team

Không nên gửi tất cả Alert cho mọi người.

Ví dụ:

route:
  routes:
  - match:
      team: backend
    receiver: backend-slack
  - match:
      team: database
    receiver: database-slack

Kết quả:

Todo API Error
        ↓
 Backend Team

PostgreSQL Down
        ↓
Database Team

6. Tránh Alert dựa trên một Metric đơn lẻ

Một lỗi phổ biến:

Tạo Alert:

CPU > 80%

Ngay lập tức.

Vấn đề: Một hệ thống có thể bình thường khi CPU tăng trong thời gian ngắn.

Ví dụ:

Deploy Application
        ↓
     CPU 95%
        ↓
     30 giây
        ↓
  CPU bình thường

Không cần Alert.

Nên dùng:

for: 10m

Ví dụ:

CPU > 90%
liên tục 10 phút

7. Sử dụng Multi-condition Alert

Alert tốt thường kết hợp nhiều điều kiện.

Ví dụ: CPU cao + Request tăng.

CPU > 90%

AND

Request Rate > 1000 req/s

Điều này chính xác hơn.

8. Không Alert mọi thứ

Một số Metric chỉ nên xem trên Grafana.

Ví dụ: Không nên Alert.

CPU tăng 60%

Disk I/O tăng nhẹ

Thread tăng 10%

Vì đây chỉ là thông tin quan sát.

Nên Alert:

User Impact

System Failure

Data Loss Risk

9. Checklist Debug khi Alert không hoạt động

Khi Alert không chạy, kiểm tra theo thứ tự.

Bước 1: Prometheus có Metric không?

Ví dụ:

up{job="todo-api"}

Nếu không có dữ liệu:

Kiểm tra:

Service.
Endpoint.
Scrape Config.

Bước 2: Prometheus có Load Rule không?

Vào:

Prometheus
↓
Status
↓
Rules

Phải thấy:

todo-alerts

Bước 3: Test PromQL

Copy biểu thức Alert vào Query.

Ví dụ:

up{job="todo-api"} == 0

Nếu không có kết quả:

Alert không thể chạy.

Bước 4: Kiểm tra Alertmanager

Prometheus:

Status
↓
Runtime & Build Information

Kiểm tra:

Alertmanagers

Bước 5: Kiểm tra Alertmanager Log

kubectl logs \
prometheus-alertmanager-0 \
-n monitoring

10. Production Alert Checklist

Một hệ thống Kubernetes Production nên có tối thiểu:

Alert	Mức độ
Application Down	Critical
HTTP 5xx tăng cao	Critical
Database Down	Critical
Pod Restart	Warning
Pod Pending	Warning
Memory gần giới hạn	Warning
CPU cao kéo dài	Warning
Node Down	Critical
Disk đầy	Critical
Certificate hết hạn	Warning

11. Tổng kết Lab 8

Sau toàn bộ Lab 8, chúng ta đã xây dựng được hệ thống Alerting hoàn chỉnh:

Bạn đã hiểu:

✅ Alert Rule
✅ PromQL Alert Expression
✅ Alert Lifecycle
✅ Pending
✅ Firing
✅ Resolved
✅ Alertmanager
✅ Email Notification
✅ Slack Notification
✅ Severity
✅ Routing
✅ Alert Best Practices

Bài học rút ra

Monitoring trả lời câu hỏi:

"Điều gì đang xảy ra với hệ thống?"

Alerting trả lời câu hỏi:

"Khi nào chúng ta cần hành động?"

Một hệ thống Production tốt không chỉ cần Dashboard đẹp.

Nó cần khả năng:

Tự phát hiện sự cố.
Thông báo đúng người.
Giảm thời gian phản ứng.
Giúp DevOps xử lý vấn đề trước khi người dùng bị ảnh hưởng.

Chuẩn bị cho Lab 9

Ở Lab 9, chúng ta sẽ hoàn thiện bộ ba Observability:

Metrics
+
Alerting
+
Logging

Chúng ta sẽ triển khai:

Centralized Logging.
Thu thập log từ Kubernetes Pod.
Loki.
Promtail.
Grafana Logs Explorer.

Khi đó DevOps có thể đi theo toàn bộ quy trình xử lý sự cố:

Alert nhận được
↓
Xem Metrics
↓
Xác định vấn đề
↓
Xem Logs
↓
Tìm nguyên nhân gốc

Đây chính là quy trình vận hành một hệ thống Kubernetes Production thực tế.

1. Alert Fatigue là gì?

Nguyên tắc tạo Alert

2. Alert nào nên tạo trong Production?

Nhóm 1: Availability Alert

Application Down

Kubernetes Pod Down

Nhóm 2: Error Rate Alert

Nhóm 3: Latency Alert

Nhóm 4: Resource Alert

CPU

Memory

Nhóm 5: Kubernetes Stability Alert

Pod Restart

Pending Pod

3. Severity trong Alert

Critical

Warning

Info

4. Sử dụng Labels để phân loại Alert

5. Routing Alert trong Alertmanager

6. Tránh Alert dựa trên một Metric đơn lẻ

7. Sử dụng Multi-condition Alert

8. Không Alert mọi thứ

9. Checklist Debug khi Alert không hoạt động

Bước 1: Prometheus có Metric không?

Bước 2: Prometheus có Load Rule không?

Bước 3: Test PromQL

Bước 4: Kiểm tra Alertmanager

Bước 5: Kiểm tra Alertmanager Log

10. Production Alert Checklist

11. Tổng kết Lab 8

Bài học rút ra

Chuẩn bị cho Lab 9

Mục lục