Series: Kubernetes từ Zero đến Production

---

Tình huống thực tế

Sau Lab 7, hệ thống Todo đã có đầy đủ Dashboard theo dõi:

• CPU
• Memory
• Request Rate
• Request Latency
• HTTP Status
• JVM Metrics

Mọi thứ đều được hiển thị trên Grafana.

Tuy nhiên, một tối thứ Bảy lúc 2 giờ sáng, Backend xảy ra lỗi.

CPU tăng lên 98%.

Pod liên tục Restart.

Toàn bộ API trả về HTTP 500.

Dashboard vẫn hiển thị đầy đủ.

Nhưng không có ai đang mở Grafana để theo dõi.

Đến sáng hôm sau, Product Owner mới phát hiện hệ thống bị lỗi.

Monitoring giúp chúng ta quan sát.

Alerting giúp hệ thống chủ động thông báo khi có sự cố.

---

Mục tiêu

Sau bài lab này, bạn sẽ:

• Hiểu Alerting hoạt động như thế nào
• Hiểu Alertmanager
• Tạo Alert Rule
• Cấu hình Alertmanager
• Gửi cảnh báo qua Email
• Gửi cảnh báo qua Slack (tùy chọn)
• Kiểm tra Alert hoạt động
• Hiểu vòng đời của một Alert

---

Kiến thức cần chuẩn bị

Đã hoàn thành:

• ✅ Lab 1 → Lab 7

Đã có:

• Prometheus
• Grafana
• Application Metrics

---

Kiến trúc

                 Kubernetes
                      ↓
                Export Metrics
                      ↓
                 Prometheus
                      ↓
                Evaluate Rules
                      ↓
                 Alertmanager
             ┌────────┴────────┐
             │                 │
           Email             Slack
                      ↓
                 DevOps Team

---

Alerting hoạt động như thế nào?

Quy trình gồm 4 bước:

1. Prometheus thu thập Metrics.
2. Prometheus kiểm tra Alert Rules theo chu kỳ.
3. Nếu điều kiện đúng trong một khoảng thời gian, Alert được kích hoạt.
4. Alertmanager gửi thông báo tới các kênh đã cấu hình.

Ví dụ:

CPU > 80%
↓
5 phút
↓
Alert Firing
↓
Email / Slack

---

Bước 1. Kiểm tra Alertmanager

Nếu cài Prometheus bằng chart kube-prometheus-stack, Alertmanager thường đã được cài sẵn.

Kiểm tra:

kubectl get pods -n monitoring

Ví dụ:

alertmanager-kube-prometheus-stack-alertmanager

Running

Kiểm tra Service:

kubectl get svc -n monitoring

---

Bước 2. Truy cập Alertmanager

Forward cổng:

kubectl port-forward svc/alertmanager-operated \
9093:9093 \
-n monitoring

Mở:

http://localhost:9093

Bạn sẽ thấy giao diện Alertmanager.

---

Bước 3. Tạo Alert Rule

Tạo file:

high-cpu-alert.yaml

Ví dụ:

groups:
- name: kubernetes-alerts

  rules:

  - alert: HighCPUUsage

    expr: node_cpu_seconds_total > 80

    for: 5m

    labels:

      severity: warning

    annotations:

      summary: CPU usage is high

      description: CPU usage has exceeded 80%

Trong môi trường thực tế, bạn nên sử dụng các biểu thức PromQL phản ánh tỷ lệ sử dụng CPU (ví dụ dựa trên rate(...) và tính phần trăm), thay vì so sánh trực tiếp với node_cpu_seconds_total như ví dụ đơn giản trên.

Áp dụng Rule.

---

Bước 4. Reload Prometheus

Sau khi thêm Rule:

Kiểm tra:

Status

↓

Rules

Bạn sẽ thấy:

HighCPUUsage

---

Bước 5. Cấu hình Email

Mở cấu hình Alertmanager.

Ví dụ:

receivers:

- name: email

  email_configs:

  - to: devops@company.com

Cấu hình SMTP phù hợp với hệ thống của bạn.

Sau khi cập nhật cấu hình, khởi động lại Alertmanager nếu cần.

---

Bước 6. Cấu hình Slack (tùy chọn)

Tạo Incoming Webhook trên Slack.

Ví dụ cấu hình:

slack_configs:

- api_url: https://hooks.slack.com/...

  channel: "#alerts"

Sau khi lưu cấu hình, Alertmanager sẽ có thể gửi cảnh báo tới kênh Slack.

---

Bước 7. Kiểm tra Alert

Thực hiện Load Test:

ab -n 50000 -c 300 \
http://todo.company.local/api/todos

Hoặc:

k6 run script.js

Quan sát:

• CPU tăng
• Request tăng
• Alert bắt đầu ở trạng thái Pending

Nếu điều kiện tiếp tục thỏa mãn sau thời gian for, Alert chuyển sang trạng thái Firing.

---

Bước 8. Theo dõi Alert trên Prometheus

Mở:

Alerts

Ví dụ:

HighCPUUsage

FIRING

Trạng thái thường gặp:

• Inactive
• Pending
• Firing

---

Bước 9. Quan sát Alertmanager

Trong Alertmanager:

Alerts

Bạn sẽ thấy:

HighCPUUsage

Cùng các thông tin:

• Severity
• Start Time
• Labels
• Annotations

---

Bước 10. Khôi phục hệ thống

Dừng Load Test.

Sau một thời gian:

• CPU giảm
• Điều kiện Alert không còn thỏa mãn
• Alert chuyển sang trạng thái Resolved

Thông báo khôi phục có thể được gửi nếu đã cấu hình.

---

Bước 11. Tạo thêm Alert

Pod Restart

Ví dụ:

Pod restart > 5

---

HTTP 5xx

Ví dụ:

HTTP 500 > 5%

trong 5 phút

---

Memory

Ví dụ:

Memory > 90%

---

Target Down

Ví dụ:

up == 0

Đây là một trong những Alert phổ biến nhất để phát hiện dịch vụ hoặc endpoint không còn phản hồi.

---

Bước 12. Thử tạo lỗi

Xóa Backend Pod

kubectl delete pod <backend-pod>

Quan sát:

• Dashboard
• Alert
• HPA

---

Gây lỗi HTTP 500

Tạm thời sửa ứng dụng để trả về lỗi.

Quan sát:

• HTTP Status
• Alert
• Email

---

Tăng CPU

Chạy Load Test liên tục.

Theo dõi:

• Pending
• Firing
• Resolved

---

Dọn dẹp

Nếu không tiếp tục sử dụng Alerting:

• Xóa Alert Rules đã tạo.
• Gỡ hoặc vô hiệu hóa cấu hình Alertmanager theo nhu cầu của môi trường thực hành.

---

Những gì bạn đã học

Sau bài lab này, bạn đã biết:

• ✅ Alertmanager
• ✅ Alert Rule
• ✅ Alert Lifecycle
• ✅ Pending
• ✅ Firing
• ✅ Resolved
• ✅ Gửi Email
• ✅ Gửi Slack
• ✅ Theo dõi Alert
• ✅ Kiểm thử Alert

---

Bài học rút ra

Monitoring giúp bạn nhìn thấy hệ thống.

Alerting giúp hệ thống tự thông báo khi phát hiện bất thường.

Trong môi trường Production, DevOps không thể theo dõi Dashboard liên tục. Thay vào đó, các Alert được thiết kế để phát hiện sớm những sự cố quan trọng như CPU tăng cao, Pod liên tục Restart hoặc dịch vụ không còn phản hồi, từ đó giúp đội ngũ vận hành phản ứng nhanh trước khi ảnh hưởng đến người dùng.

Ở Lab 9, chúng ta sẽ hoàn thiện hệ thống Observability bằng Centralized Logging, nơi toàn bộ log của các Pod sẽ được thu thập và tập trung để hỗ trợ điều tra sự cố sau khi nhận được Alert.