Cuộc Gọi Đánh Thức Lúc 2:14 Sáng
Chiếc pager (máy nhắn tin cảnh báo) rú vang lúc 2:14 sáng. Một microservice quan trọng bị đánh dấu là ‘unhealthy’. Tôi đăng nhập vào với đôi mắt ngái ngủ, nhưng chỉ thấy một màu xanh hy vọng. CPU đang chạy không tải ở mức 12%, bộ nhớ ổn định, và mọi pod đều ở trạng thái ‘Running’. Thế nhưng, các ticket hỗ trợ thì tràn ngập: người dùng ở Berlin không thể hoàn tất thanh toán. Đây là cái bẫy kinh điển. Chúng ta đang đo lường máy móc, nhưng quên mất việc đo lường trải nghiệm của con người.
Sau khi triển khai chiến lược SRE này cho một nền tảng xử lý 5.000 yêu cầu mỗi giây, tỷ lệ ‘báo động giả’ của chúng tôi đã giảm 60%. Thay vì đuổi theo những bóng ma, chúng tôi tập trung vào các Mục tiêu Cấp độ Dịch vụ (SLOs). Nếu bạn đang chìm trong những cảnh báo rác trong khi người dùng vẫn gặp lỗi, đã đến lúc phải vượt xa việc giám sát ngưỡng đơn thuần.
Giám Sát Hạ Tầng và Độ Tin Cậy SRE
Ban đầu, chúng tôi theo dõi mọi thứ: I/O đĩa, ngắt mạng, và chuyển ngữ cảnh (context switches). Tôi gọi đây là cách tiếp cận ‘Từ dưới lên’ (Bottom-Up). Nó giải thích tại sao một máy chủ có thể chậm, nhưng lại không cho biết liệu khách hàng có thực sự gặp vấn đề hay không. Đó là quá nhiều dữ liệu nhưng lại thiếu thông tin.
Site Reliability Engineering (SRE) đảo ngược điều này với cái nhìn ‘Từ trên xuống’ (Top-Down). Chúng tôi ưu tiên Chỉ số Cấp độ Dịch vụ (SLI)—một số liệu thực sự quan trọng với người dùng, chẳng hạn như độ trễ (latency) khi thanh toán. Sau đó, chúng tôi thiết lập Mục tiêu Cấp độ Dịch vụ (SLO), là mục tiêu cho chỉ số đó (ví dụ: 99,9% các khoản thanh toán phải hoàn tất trong dưới 500ms).
| Tính năng | Giám sát truyền thống | Giám sát dựa trên SLO |
|---|---|---|
| Trọng tâm cốt lõi | Tài nguyên hệ thống (CPU/RAM) | Trải nghiệm người dùng (Thành công/Độ trễ) |
| Kích hoạt cảnh báo | Vượt ngưỡng tức thời | Tốc độ tiêu thụ Error Budget |
| Kết quả | Phản ứng thụ động và thường gây nhiễu | Dựa trên dữ liệu và mang tính chiến lược |
Thực Tế Về Các Quy Tắc Prometheus Thủ Công
Bạn có thể xây dựng các cảnh báo SLO trực tiếp trong Prometheus bằng PromQL. Tôi đã thử cách này từ sớm. Nó yêu cầu tính toán tỷ lệ lỗi trên các khung thời gian thay đổi—1 giờ, 6 giờ và 3 ngày—cùng một lúc. Đó là một gánh nặng bảo trì khó có thể mở rộng.
Ưu điểm
- Không phụ thuộc vào các binary bên ngoài.
- Kiểm soát hoàn toàn logic PromQL gốc.
Nhược điểm
- Việc vật lộn với toán học burn rate đa khung thời gian rất dễ gây sai sót.
- Mỗi nhóm lại tạo ra các phiên bản hơi khác nhau, không tương thích.
- Việc sao chép-dán các cảnh báo dài 50 dòng dẫn đến những lỗi ‘đánh máy’ khó tránh khỏi.
Đây là lúc Sloth thay đổi cuộc chơi. Sloth là một bộ tạo (generator). Nó nhận một định nghĩa YAML rõ ràng và tự động tạo ra hàng nghìn dòng quy tắc ghi (recording rules) và cảnh báo Prometheus đã được kiểm chứng thực tế.
Bộ Công Cụ Độ Tin Cậy Khuyên Dùng
Đối với môi trường Kubernetes cấp độ sản xuất, tôi tin dùng bộ công cụ cụ thể này:
- Prometheus: Công cụ thu thập và lưu trữ các số liệu thô của bạn.
- Sloth: Kiến trúc sư định nghĩa và tạo ra các quy tắc độ tin cậy.
- Grafana: Cửa sổ nhìn vào ‘Error Budget’ (thời gian chết còn lại của bạn).
- Alertmanager: Bộ định tuyến gửi các thông báo quan trọng chỉ khi mục tiêu 30 ngày của bạn gặp rủi ro.
Triển Khai: Thiết Lập Sloth
Hãy chuyển từ lý thuyết sang terminal. Chúng ta sẽ định nghĩa một SLO cho ‘Checkout Service’ (Dịch vụ Thanh toán) với cam kết tỷ lệ yêu cầu thành công là 99,9%.
1. Cài đặt Sloth
Mặc dù Sloth hoạt động như một Kubernetes operator, việc sử dụng CLI là cách nhanh nhất để học. Tải xuống binary cho môi trường của bạn:
curl -L -o sloth https://github.com/slok/sloth/releases/download/v0.11.0/sloth-linux-amd64
chmod +x sloth
sudo mv sloth /usr/local/bin/2. Định nghĩa Cấu hình SLO
Tạo file checkout-slo.yaml. File này mô tả chính xác thế nào là trạng thái ‘tốt’ đối với doanh nghiệp của bạn.
version: "prometheus/v1"
service: "checkout-service"
slos:
- name: "requests-availability"
objective: 99.9
description: "99,9% phản hồi thanh toán phải thành công trong khung thời gian 30 ngày liên tục."
sli:
events:
error_query: sum(rate(http_requests_total{service="checkout", code=~"5.."}[{{.window}}]))
total_query: sum(rate(http_requests_total{service="checkout"}[{{.window}}]))
alerting:
name: "CheckoutAvailabilityAlert"
labels:
severity: "critical"
team: "core-commerce"3. Tạo các Quy Tắc
Hãy để Sloth đảm nhận phần việc nặng nhọc. Lệnh này chuyển đổi file YAML đơn giản của bạn thành một cấu hình Prometheus phức tạp:
sloth generate -i checkout-slo.yaml -o prometheus-rules.yamlMở prometheus-rules.yaml và bạn sẽ thấy các quy tắc ghi (recording rules) tinh vi. Những quy tắc này đảm bảo cảnh báo của bạn chỉ kích hoạt khi có mối đe dọa thực sự đối với mục tiêu độ tin cậy 30 ngày, ngăn chặn các cảnh báo ‘chập chờn’ (flapping) trong các sự cố nhỏ.
4. Kết nối với Prometheus
Trỏ Prometheus tới các quy tắc mới trong cấu hình chính của bạn:
rule_files:
- "prometheus-rules.yaml"Sau khi tải lại, các chỉ số mới như slo:error_budget:burn_rate sẽ xuất hiện trong trình duyệt của bạn. Đây chính là nhịp đập sức khỏe dịch vụ của bạn.
Trực Quan Hóa Error Budget
Error Budget là công cụ mạnh mẽ nhất của bạn. Với SLO 99,9%, bạn được phép có 0,1% sự kiện ‘xấu’. Nếu dịch vụ của bạn xử lý 1 triệu yêu cầu, bạn có thể chấp nhận chính xác 1.000 lỗi mỗi tháng. Không hơn.
Trong Grafana, hãy ngừng nhìn vào tỷ lệ phần trăm ‘uptime’. Thay vào đó, hãy theo dõi Error Budget còn lại. Nếu bạn đã tiêu hết 80% ngân sách vào tuần thứ hai của tháng, hãy đóng băng tất cả việc triển khai tính năng mới. Chuyển trọng tâm sang nợ kỹ thuật (technical debt) và sự ổn định. Điều này chuyển cuộc hội thoại từ ‘ai làm hỏng bản build?’ thành ‘làm thế nào để chúng ta bảo vệ cam kết về độ tin cậy?’
Việc triển khai điều này đã đưa đội ngũ của chúng tôi từ những người lính cứu hỏa thụ động trở thành những kỹ sư chủ động. Chúng tôi không còn phải thức giấc vì một lỗi 500 đơn lẻ. Chúng tôi chỉ nhận cảnh báo khi lời hứa với người dùng thực sự gặp nguy hiểm.
