1. Viết Alert Rules trong Prometheus
Bước đầu tiên là định nghĩa các quy tắc cảnh báo (Alert Rules) dựa trên các chỉ số quan trọng của hệ thống Hybrid Cloud. Chúng ta sẽ tạo file cấu hình riêng biệt để dễ dàng quản lý và mở rộng.
Tạo file cấu hình alert rules tại đường dẫn /etc/prometheus/rules/alerts.yml. Nội dung file này định nghĩa điều kiện kích hoạt cảnh báo, mức độ nghiêm trọng (severity) và thời gian giữ trạng thái cảnh báo (for).
groups:
- name: hybrid_cloud_critical
rules:
- alert: HighCPUUsage
expr: avg_over_time(node_cpu_seconds_total{mode="idle"}[5m]) < 0.2
for: 5m
labels:
severity: critical
team: infrastructure
annotations:
summary: "CPU usage cao bất thường trên {{ $labels.instance }}"
description: "CPU usage đã vượt quá 80% trong 5 phút liên tục trên node {{ $labels.instance }}. Cần kiểm tra ngay lập tức."
- alert: HighMemoryUsage
expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100 > 90
for: 10m
labels:
severity: warning
team: infrastructure
annotations:
summary: "Memory usage cao trên {{ $labels.instance }}"
description: "Memory usage đã vượt quá 90% trong 10 phút trên node {{ $labels.instance }}. Rủi ro OOM."
- alert: ServiceDown
expr: up == 0
for: 1m
labels:
severity: critical
team: sre
annotations:
summary: "Dịch vụ {{ $labels.job }} đã ngừng hoạt động"
description: "Prometheus không thể scrape được target {{ $labels.instance }} trong 1 phút."
- alert: HighLatencyP99
expr: histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service)) > 1
for: 5m
labels:
severity: warning
team: backend
annotations:
summary: "Độ trễ P99 cao cho service {{ $labels.service }}"
description: "Độ trễ 99% của request đã vượt quá 1 giây cho service {{ $labels.service }}."
Sau khi lưu file, hãy reload cấu hình Prometheus để áp dụng các quy tắc mới mà không cần restart service.
curl -X POST http://localhost:9090/-/reload
Kết quả mong đợi: Trả về JSON {"status":"success"}. Truy cập vào tab "Status" -> "Rules" trên UI Prometheus, bạn sẽ thấy các rule ở trên đã chuyển sang trạng thái "Pending" hoặc "Firing" nếu điều kiện được đáp ứng.
2. Cấu hình Alertmanager: Phân loại và Định tuyến
Alertmanager đóng vai trò trung tâm để nhận cảnh báo từ Prometheus, thực hiện deduplication, grouping, và routing đến các kênh thông báo phù hợp (Email, Slack, PagerDuty).
Tạo file cấu hình Alertmanager tại /etc/alertmanager/alertmanager.yml. Cấu hình này chia tách các kênh thông báo dựa trên nhãn severity và team.
global:
resolve_timeout: 5m
smtp_smarthost: 'smtp.example.com:587'
smtp_from: 'alertmanager@example.com'
smtp_auth_username: 'alertmanager@example.com'
smtp_auth_password: 'your_smtp_password'
route:
receiver: 'default-email'
group_by: ['alertname', 'cluster', 'service']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
routes:
- match:
severity: critical
receiver: 'pagerduty-critical'
continue: true
routes:
- match:
team: backend
receiver: 'slack-backend'
- match:
severity: warning
receiver: 'slack-infrastructure'
receivers:
- name: 'default-email'
email_configs:
- to: 'ops-team@example.com'
send_resolved: true
- name: 'pagerduty-critical'
pagerduty_configs:
- service_key: 'your_pagerduty_routing_key'
severity: 'critical'
send_resolved: true
- name: 'slack-backend'
slack_configs:
- api_url: 'https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK'
channel: '#backend-alerts'
title: '🚨 Critical Alert: {{ .CommonLabels.alertname }}'
text: '{{ range .Alerts }}{{ .Annotations.description }}{{ end }}'
send_resolved: true
- name: 'slack-infrastructure'
slack_configs:
- api_url: 'https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK'
channel: '#infra-alerts'
title: '⚠️ Warning: {{ .CommonLabels.alertname }}'
text: '{{ range .Alerts }}{{ .Annotations.description }}{{ end }}'
send_resolved: true
Khởi động lại Alertmanager để áp dụng cấu hình mới. Đảm bảo service đang chạy trước khi reload.
systemctl restart alertmanager
systemctl status alertmanager
Kết quả mong đợi: Alertmanager khởi động thành công. Truy cập UI Alertmanager tại http://localhost:9093, tab "Configuration" sẽ hiển thị trạng thái "Success" nếu cấu hình hợp lệ.
3. Tích hợp Alerting vào Grafana
Ngoài Prometheus Alerting, chúng ta cần thiết lập Alert Rules trực tiếp trong Grafana để tận dụng dashboard visualization và gửi cảnh báo qua các channel mà Grafana hỗ trợ (như Webhook, OpsGenie, Discord).
Trước tiên, cần cấu hình Alerting trong grafana.ini để bật tính năng Alerting v2 (Unified Alerting) nếu đang dùng phiên bản Grafana mới (v8.1+).
vi /etc/grafana/grafana.ini
Trong file grafana.ini, thêm hoặc sửa phần [alerting] như sau:
[alerting]
enabled = true
eval_interval = 1m
execution_error_message = "An error occurred while executing the alert rule"
max_alerts = 10000
Tiếp theo, trong giao diện Grafana, vào Dashboard đã tạo ở Phần 5, chọn biểu đồ (Panel) cần giám sát, bấm vào nút "Alerting" ở góc trên bên phải của panel.
# Hướng dẫn thực hiện trong UI Grafana (không cần command terminal)
# 1. Chọn Panel -> Click nút "Alerting"
# 2. Bật "Enable alerting"
# 3. Chọn Condition: "Alert when metric is outside these bands"
# 4. Thiết lập threshold: ví dụ "Greater than 80%"
# 5. Trong tab "Notifications", chọn Alert Rule Group và chọn Alert Channel (Slack/Email) đã cấu hình
Sau khi cấu hình xong, hãy lưu Dashboard. Grafana sẽ tự động tạo Alert Rule trong phần "Alerting" của menu bên trái.
Để verify, kích hoạt một tình huống giả lập (ví dụ: làm tăng CPU cao), sau đó vào menu "Alerting" -> "Alert Rules" để xem trạng thái của rule chuyển từ "Normal" sang "Firing".
4. Thiết lập Deduplication và Silencing
Để tránh bị spam bởi hàng loạt cảnh báo cùng lúc (ví dụ: mất điện toàn bộ datacenter), cần cấu hình cơ chế Deduplication (gộp cảnh báo trùng lặp) và Silencing (tạm tắt cảnh báo).
Deduplication được cấu hình sẵn trong group_by của Alertmanager (đã làm ở mục 2). Tuy nhiên, Silencing cần được thực thi thủ công hoặc qua API khi đang bảo trì.
Để tạo một Silence (tạm tắt) cho toàn bộ các alert của service "backend" trong 1 giờ, sử dụng command API của Alertmanager:
curl -X POST http://localhost:9093/api/v2/silences \
-H "Content-Type: application/json" \
-d '{
"matchers": [
{"name": "alertname", "value": "HighLatencyP99", "isRegex": false},
{"name": "service", "value": "backend", "isRegex": false}
],
"startsAt": "2023-10-27T10:00:00Z",
"endsAt": "2023-10-27T11:00:00Z",
"createdBy": "sysadmin",
"comment": "Maintenance window for backend service"
}'
Thay đổi startsAt và endsAt thành thời gian thực tế. Command này sẽ tạo một window thời gian mà các alert khớp với matcher sẽ bị chặn không gửi đi.
Để xóa Silence sau khi bảo trì xong, lấy ID của silence từ response của command trên (hoặc từ UI Alertmanager tab "Silences") và xóa:
curl -X DELETE http://localhost:9093/api/v2/silences/{SILENCE_ID}
Kết quả mong đợi: Khi tạo silence, Alertmanager trả về JSON chứa id của silence. Khi trigger cảnh báo trong khoảng thời gian đó, bạn sẽ không nhận được email/Slack, nhưng trên UI Alertmanager tab "Silences" sẽ hiển thị trạng thái "Active".
5. Verify toàn bộ hệ thống Alerting
Để đảm bảo toàn bộ pipeline hoạt động chính xác từ Prometheus -> Alertmanager -> Kênh thông báo, hãy thực hiện test giả lập cảnh báo.
Trigger một cảnh báo thử nghiệm bằng cách tạo một metric giả hoặc tạm thời sửa threshold trong Prometheus để kích hoạt rule "ServiceDown" hoặc "HighCPUUsage".
# Giả lập bằng cách gửi một request sai để làm service down (tùy vào ứng dụng)
# Hoặc đơn giản hơn, chỉnh sửa file alerts.yml, giảm threshold xuống 0.01 để force firing
# Sau đó reload Prometheus:
curl -X POST http://localhost:9090/-/reload
Kiểm tra trạng thái trên UI Prometheus (tab Rules) xem alert đã chuyển sang "Firing". Sau đó kiểm tra UI Alertmanager (tab Alerts) xem alert đã được nhận và route đúng receiver chưa.
curl http://localhost:9093/api/v2/alerts
Kết quả mong đợi: JSON trả về chứa danh sách các alert đang firing. Kiểm tra email, Slack hoặc PagerDuty xem đã nhận được thông báo với nội dung đúng (Summary, Description) và đúng channel theo cấu hình ở mục 2.
Điều hướng series:
Mục lục: Series: Series: Xây dựng hệ thống observability toàn diện (Logging, Metrics, Tracing) cho môi trường Hybrid Cloud với Prometheus, Grafana và OpenTelemetry
« Phần 5: Tích hợp và trực quan hóa dữ liệu: Xây dựng Dashboard với Grafana
Phần 7: An ninh và bảo mật cho hệ thống Observability »