Series: Kubernetes từ Zero đến Production

---

Tình huống thực tế

Sau Lab 7, hệ thống Todo đã được tích hợp đầy đủ khả năng Application Monitoring.

Thông qua Grafana, DevOps có thể theo dõi gần như toàn bộ trạng thái của hệ thống:

• Nhóm Hạ tầng & Container
  • CPU và Memory của Node
  • CPU và Memory của Pod

• Nhóm Runtime & Hiệu năng Ứng dụng
  • Request Rate
  • Request Latency
  • HTTP Status Code
  • JVM Memory
  • Garbage Collector
  • Live Threads

Mỗi khi người dùng phản ánh ứng dụng chậm hoặc xảy ra lỗi, chỉ cần mở Grafana là có thể nhanh chóng xác định nguyên nhân.

Nhưng, một buổi tối cuối tuần, khoảng 2 giờ sáng, phiên bản mới của Backend được triển khai lên Production.

Sau khi triển khai, ứng dụng xuất hiện lỗi kết nối tới Database.

Kết quả là:

• Backend liên tục trả về HTTP 500
• Pod Restart nhiều lần
• Request Latency tăng đột biến
• CPU của Pod tăng lên gần 100%

Toàn bộ những thông tin này đều xuất hiện trên Dashboard Grafana.

Tuy nhiên...

Không có ai mở Grafana vào thời điểm đó.

Đến sáng hôm sau, Product Owner mới nhận được phản ánh từ khách hàng rằng toàn bộ hệ thống đã không thể sử dụng trong nhiều giờ.

Đây là một tình huống rất phổ biến trong thực tế.

Monitoring giúp chúng ta quan sát hệ thống.

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

Thay vì phải liên tục mở Dashboard để theo dõi, hệ thống sẽ tự gửi cảnh báo tới DevOps khi phát hiện CPU quá cao, Pod liên tục Restart hoặc API trả về quá nhiều lỗi HTTP 5xx.

---

Mục tiêu

Sau khi hoàn thành bài Lab này, bạn sẽ có thể:

• Hiểu Alerting hoạt động như thế nào.
• Hiểu vai trò của Alertmanager.
• Viết Alert Rule bằng PromQL.
• 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 đúng hay không.
• Hiểu vòng đời của một Alert từ khi phát hiện sự cố đến khi được khôi phục.

---

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

Trước khi bắt đầu, bạn nên hoàn thành các bài Lab trước trong series:

• ✅ Lab 1 – Xây dựng Kubernetes Cluster Local
• ✅ Lab 2 – Triển khai ứng dụng Todo lên Kubernetes
• ✅ Lab 3 – Productionize ứng dụng
• ✅ Lab 4 – Horizontal Pod Autoscaler
• ✅ Lab 5 – Monitoring Cluster với Prometheus và Grafana
• ✅ Lab 6 – Application Monitoring với Spring Boot Actuator và Micrometer

Đồng thời hệ thống cần có:

• Kubernetes Cluster
• Prometheus
• Grafana
• Spring Boot Actuator
• Micrometer
• Prometheus đã scrape được Application Metrics

---

Từ Monitoring đến Alerting

Sau Lab 7, kiến trúc Monitoring của chúng ta như sau:

                 Browser
                    ↓
              Spring Boot API
                    ↓
            Spring Boot Actuator
                    ↓
                Micrometer
                    ↓
          /actuator/prometheus
                    ↓
                Prometheus
                    ↓
                 Grafana

• Prometheus liên tục thu thập Metrics từ Kubernetes và Spring Boot.

• Grafana chỉ có nhiệm vụ trực quan hóa dữ liệu. Nếu muốn biết hệ thống đang hoạt động như thế nào, chúng ta phải chủ động mở Dashboard. Điều này hoàn toàn phù hợp trong quá trình phát triển hoặc học tập.

• Nhưng trong môi trường Production, DevOps không thể theo dõi Dashboard 24 giờ mỗi ngày.

• Chúng ta cần một cơ chế tự động phát hiện sự cố và gửi thông báo.

Đó chính là Alerting.

---

1. Kiến trúc Alerting

Sau bài Lab này, kiến trúc của hệ thống sẽ được mở rộng như sau:

	Ảnh Minh hoạ

Lúc này Prometheus không chỉ lưu trữ Metrics mà còn chịu trách nhiệm đánh giá các Alert Rule theo chu kỳ.

Khi một điều kiện được thỏa mãn trong khoảng thời gian nhất định, Prometheus sẽ gửi Alert tới Alertmanager.

Alertmanager sẽ quyết định:

• Gửi Email
• Gửi Slack
• Gom nhiều Alert thành một thông báo
• Tránh gửi trùng lặp
• Gửi lại sau một khoảng thời gian nếu sự cố vẫn chưa được xử lý

Có thể xem Alertmanager như một "trung tâm điều phối cảnh báo" của toàn bộ hệ thống.

---

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

Quy trình Alerting gồm năm bước.

Bước 1. Prometheus thu thập Metrics

Cứ sau mỗi khoảng thời gian, Prometheus sẽ scrape Metrics từ Kubernetes và Spring Boot.

Ví dụ:

CPU = 35%

Memory = 48%

HTTP 500 = 0

Request Rate = 25 req/s

---

Bước 2. Prometheus đánh giá Alert Rules

Prometheus sẽ liên tục chạy các biểu thức PromQL.

Ví dụ:

up == 0

Hoặc:

increase(
kube_pod_container_status_restarts_total[5m]
) > 3

Nếu điều kiện chưa đúng, Alert vẫn ở trạng thái Inactive.

---

Bước 3. Alert chuyển sang Pending

Giả sử chúng ta định nghĩa:

for: 5m

Điều đó có nghĩa là điều kiện phải được duy trì liên tục trong 5 phút.

Ví dụ:

CPU > 80%
↓
1 phút
↓
2 phút
↓
3 phút
↓
4 phút
↓
5 phút

Trong khoảng thời gian này Alert sẽ ở trạng thái:

Pending

Việc sử dụng for giúp tránh rất nhiều cảnh báo giả.

Ví dụ CPU chỉ tăng cao trong vài giây do một đợt xử lý ngắn thì sẽ không kích hoạt Alert.

---

Bước 4. Alert chuyển sang Firing

Nếu sau thời gian for điều kiện vẫn còn đúng:

CPU > 80%

trong 5 phút

Prometheus sẽ chuyển Alert sang:

Firing

và gửi Alert tới Alertmanager.

Alertmanager sau đó sẽ gửi Email hoặc Slack cho đội vận hành.

---

Bước 5. Alert được Resolve

Khi sự cố được khắc phục:

CPU

85%
↓
70%
↓
45%

Alert sẽ chuyển sang:

Resolved

Nếu được cấu hình, Alertmanager cũng có thể gửi thông báo rằng hệ thống đã hoạt động bình thường trở lại.

---

1.2 Những loại Alert phổ biến

Trong môi trường Production, không phải mọi Metric đều cần tạo Alert.

Một số Alert quan trọng thường được triển khai gồm:

Loại Alert	Mục đích
Pod Down	Phát hiện ứng dụng không còn hoạt động
CPU cao	Phát hiện tải tăng bất thường
Memory cao	Phát hiện nguy cơ Out Of Memory
Pod Restart	Phát hiện CrashLoopBackOff hoặc ứng dụng không ổn định
HTTP 5xx	Phát hiện API lỗi
Request Latency	Phát hiện ứng dụng phản hồi chậm
Target Down	Phát hiện Prometheus không scrape được Metrics

---

2. Alertmanager là gì?

Alertmanager là thành phần chịu trách nhiệm:

• Nhận Alert từ Prometheus.
• Gom nhóm các Alert giống nhau.
• Loại bỏ Alert trùng lặp.
• Tạm dừng gửi Alert trong một khoảng thời gian (Silencing).
• Định tuyến Alert tới các kênh nhận thông báo như Email, Slack, Microsoft Teams hoặc PagerDuty.

Nói cách khác, Prometheus chịu trách nhiệm phát hiện sự cố, còn Alertmanager chịu trách nhiệm thông báo sự cố.

---

2.1 Kiểm tra Pod Alertmanager

Đầu tiên, kiểm tra các Pod trong namespace monitoring:

kubectl get pods -n monitoring

Ví dụ:

NAME                                                 READY   STATUS
grafana-799c9d794-2qfvt                              1/1     Running
prometheus-alertmanager-0                            1/1     Running
prometheus-kube-state-metrics-76444ffd98-tbjq4       1/1     Running
prometheus-prometheus-node-exporter-rs4hg            1/1     Running
prometheus-prometheus-pushgateway-5df4b4d79b-tgzp9   1/1     Running
prometheus-server-c9b8c797f-452ct                    2/2     Running

Nếu thấy Pod:

prometheus-alertmanager-0

ở trạng thái Running, nghĩa là Alertmanager đã được triển khai thành công.

---

2.2 Kiểm tra Service của Alertmanager

Tiếp theo, liệt kê các Service:

kubectl get svc -n monitoring

Ví dụ:

NAME                                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
grafana                               ClusterIP   10.110.17.23    <none>        80/TCP     4d1h
prometheus-alertmanager               ClusterIP   10.99.184.223   <none>        9093/TCP   4d4h
prometheus-alertmanager-headless      ClusterIP   None            <none>        9093/TCP   4d4h
prometheus-kube-state-metrics         ClusterIP   10.96.21.129    <none>        8080/TCP   4d4h
prometheus-prometheus-node-exporter   ClusterIP   10.104.116.55   <none>        9100/TCP   4d4h
prometheus-prometheus-pushgateway     ClusterIP   10.108.131.6    <none>        9091/TCP   4d4h
prometheus-server                     ClusterIP   10.103.48.229   <none>        80/TCP     4d4h

Trong đó:

prometheus-alertmanager

là Service dùng để truy cập Alertmanager từ bên trong Kubernetes Cluster.

---

2.2 Port Forward Alertmanager

Để truy cập giao diện Alertmanager từ máy tính cá nhân, sử dụng kubectl port-forward.

Thực hiện:

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

Nếu thành công:

Forwarding from 127.0.0.1:9093 -> 9093
Forwarding from [::1]:9093 -> 9093

Giữ nguyên Terminal này trong suốt quá trình thực hành.

---

2.3 Truy cập Alertmanager

Mở trình duyệt và truy cập:

http://localhost:9093

Nếu mọi thứ hoạt động đúng, bạn sẽ thấy giao diện của Alertmanager.

Ví dụ:

Ở thời điểm này, chưa có Alert Rule nào được cấu hình nên giao diện sẽ gần như trống.

Đây là điều hoàn toàn bình thường.

---

2.4 Làm quen với giao diện Alertmanager

Trong bài Lab này, chúng ta chủ yếu làm việc với:

• Alerts
• Status

Giao diện Alertmanager khá đơn giản, gồm các mục chính sau:

Mục	Chức năng
Alerts	Danh sách các Alert đang hoạt động
Silences	Tạm thời vô hiệu hóa Alert
Status	Kiểm tra cấu hình Alertmanager

---

2.5 Kiểm tra trạng thái Alertmanager

Chọn:

Status

Bạn sẽ thấy thông tin về:

• Phiên bản Alertmanager.
• Thời gian khởi động.
• Cấu hình hiện tại.
• Danh sách Receiver.

Ban đầu, cấu hình thường rất đơn giản vì chúng ta chưa thêm Email hoặc Slack.

Ví dụ:

---

2.6 Kiểm tra Prometheus đã kết nối tới Alertmanager

Prometheus cần biết địa chỉ của Alertmanager để gửi Alert.

Port Forward Prometheus:

kubectl port-forward \
svc/prometheus-server \
9090:80 \
-n monitoring

Mở:

http://localhost:9090

Chọn:

Status
    ↓
Runtime & Build Information

hoặc:

Status
    ↓
Configuration

Tìm phần:

alerting:
  alertmanagers:

Ví dụ:

alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - prometheus-alertmanager:9093

Điều này cho thấy Prometheus đã biết địa chỉ của Alertmanager và sẵn sàng gửi Alert khi có Rule được kích hoạt.

Tổng kết

Đến đây, chúng ta đã:

• Kiểm tra Alertmanager trong cụm Kubernetes.
• Triển khai hoặc kích hoạt Alertmanager nếu cần.
• Cấu hình Alertmanager bằng Helm.
• Chuẩn bị môi trường để Prometheus có thể gửi Alert khi phát hiện sự cố.
• Xác nhận Alertmanager đã được triển khai.
• Truy cập thành công giao diện Alertmanager.
• Hiểu vai trò của Alertmanager trong hệ thống Monitoring.
• Kiểm tra Prometheus đã biết địa chỉ của Alertmanager.

Ở phần tiếp theo, chúng ta sẽ bắt đầu tạo Alert Rules đầu tiên bằng PromQL và tích hợp chúng vào Prometheus để tự động phát hiện các sự cố của ứng dụng Todo.