Alerting & Thông báo

Từ Grafana 8.0, Grafana giới thiệu Unified Alerting — hệ thống cảnh báo mới dựa trên Prometheus Alertmanager, thay thế cho legacy dashboard alerting (kiểu cũ gắn alert trực tiếp vào từng panel). Từ Grafana 9 nó là mặc định, và legacy alerting đã bị gỡ hẳn ở Grafana 11.

Unified Alerting gồm năm thành phần chính, phối hợp với nhau:

Một alert rule trong Grafana được xây theo mô hình pipeline nhiều bước. Mỗi bước là một "expression" nhận đầu ra của bước trước:

• Query (A): truy vấn tới data source. Với Prometheus là PromQL trả về một chuỗi time series trong khoảng thời gian đánh giá.
• Reduce (B): gộp chuỗi time series thành một con số duy nhất mỗi series — chọn last, mean, max... Alert cần một giá trị đơn để so sánh, không thể so cả một đường.
• Threshold / Condition (C): so con số ở B với ngưỡng (vd IS ABOVE 80). Kết quả là đúng/sai — quyết định instance có vi phạm không.

Ngoài pipeline, mỗi rule còn có các thiết lập điều phối thời gian:

Mỗi alert instance trải qua các trạng thái sau:

Ví dụ cụ thể — cảnh báo CPU > 80% trong 5 phút. Query A dùng PromQL tính phần trăm CPU đang bận theo từng instance:

# Query A (data source: Prometheus) — % CPU không idle
100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

Expression B reduce lấy giá trị cuối cùng của mỗi series, rồi expression C là threshold so với 80:

# B — Reduce: Function = Last, Input = A
# C — Threshold: Input = B, IS ABOVE 80  (đây là điều kiện alert)

# Cấu hình thời gian:
Evaluation group:    infra-cpu
Evaluation interval: 1m
Pending period:      5m      # for: phải >80% liên tục 5 phút
No data:             NoData
Error:               Error

Diễn giải: mỗi 1m Grafana chạy query A cho từng instance, reduce về một số, so với 80. Nếu instance nào vượt 80%, nó vào Pending; nếu vẫn vượt suốt 5m thì chuyển Firing và gửi thông báo. Nếu tụt xuống dưới 80% trước khi hết 5 phút, nó quay về Normal mà không làm phiền ai.

Mỗi alert mang hai loại metadata với vai trò rất khác nhau — đây là điểm hay nhầm lẫn nhất:

Ba annotation quy ước phổ biến (theo chuẩn Prometheus):

• summary: một câu ngắn gọn mô tả sự cố — hiện ở tiêu đề thông báo. Vd "CPU cao trên web-01".
• description: chi tiết hơn, thường nhúng giá trị thực tế qua template.
• runbook_url: link tới tài liệu hướng dẫn xử lý — người trực chỉ việc mở ra làm theo.

Labels và annotations có thể dùng template để chèn giá trị động từ query (cú pháp Go template của Prometheus):

# Labels (dùng cho routing)
severity: critical
team:     infra

# Annotations (dùng cho hiển thị)
summary:     "CPU cao trên {{ $labels.instance }}"
description:  "CPU đang ở mức {{ $values.B.Value | printf \"%.1f\" }}% (ngưỡng 80%)"
runbook_url: "https://wiki.congty.vn/runbooks/high-cpu"

Contact point định nghĩa gửi thông báo đi đâu. Một contact point có thể chứa nhiều "integration" (vd vừa gửi email vừa gửi Slack). Các loại phổ biến:

Cấu hình mẫu — Email. Trước hết phải khai báo SMTP trong grafana.ini (hoặc biến môi trường), nếu không email sẽ không gửi được:

# grafana.ini — bật SMTP
[smtp]
enabled = true
host = smtp.gmail.com:587
user = alerts@congty.vn
password = "<app-password>"
from_address = alerts@congty.vn
from_name = Grafana Alerts

Sau đó tạo contact point loại Email với danh sách người nhận (Alerting → Contact points → New):

# Contact point: "email-infra"
Integration:  Email
Addresses:    oncall@congty.vn; sre-team@congty.vn
Single email: false   # mỗi người một email riêng

Cấu hình mẫu — Slack (Incoming Webhook). Vào api.slack.com tạo app, bật Incoming Webhooks, lấy URL dạng https://hooks.slack.com/services/T00/B00/xxxx, rồi:

# Contact point: "slack-alerts"
Integration: Slack
Webhook URL: https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXX
Recipient:   #alerts-prod
Title:       {{ template "slack.title" . }}
Text body:   {{ template "slack.text" . }}

Notification policy là một cây: có một root policy (mặc định) và các nhánh con. Mỗi alert đi từ root xuống, khớp với nhánh con đầu tiên có label matcher trùng; nếu không nhánh nào khớp thì dùng root. Đây là cơ chế quyết định alert nào gửi tới contact point nào.

# Cây định tuyến ví dụ
Root policy  → contact point: email-infra   (group_by: alertname, cluster)
│
├─ matcher: severity = critical  → contact point: pagerduty-oncall
│                                     repeat_interval: 1h
│
├─ matcher: team = infra          → contact point: slack-alerts
│
└─ matcher: env  = staging        → contact point: email-infra
                                      mute timings: ngoai-gio

Ba tham số thời gian điều khiển cách gom nhóm thông báo — cực kỳ quan trọng để chống spam:

Silences — tắt thông báo tạm thời theo label matcher, có thời hạn cụ thể. Alert vẫn được đánh giá và vẫn Firing, chỉ là không gửi đi:

• Dùng khi bảo trì có kế hoạch: vd sắp restart cụm DB, tạo silence matcher cluster="db-prod" trong 2 giờ.
• Tạo nhanh từ một alert đang firing (nút Silence) hoặc thủ công ở Alerting → Silences.
• Có thời điểm bắt đầu/kết thúc rõ ràng và tự hết hạn — không lo quên bật lại.

Mute timings — khác silence ở chỗ nó lặp lại theo lịch và gắn vào notification policy, thay vì một lần theo matcher:

# Mute timing "ngoai-gio" — chỉ mute warning ngoài giờ hành chính
Name: ngoai-gio
Time intervals:
  - weekdays:   'monday:friday'
    times:      '18:00' - '09:00'   # buổi tối
  - weekdays:   'saturday, sunday'       # cả cuối tuần
    location:   'Asia/Ho_Chi_Minh'

Một hệ thống alert tồi còn tệ hơn không có alert: người ta học cách bỏ qua nó (alert fatigue), và rồi cảnh báo thật cũng bị lờ đi. Vài nguyên tắc:

• Mỗi alert phải actionable: khi nó kêu, người nhận phải biết cần làm gì ngay. Nếu câu trả lời là "à để đó tính sau" thì đó không nên là alert — hãy đưa vào dashboard/report.
• Cảnh báo trên triệu chứng, không trên nguyên nhân: báo "latency người dùng > 2s" (ảnh hưởng thật) thay vì "CPU của một node = 90%" (có thể vô hại nếu dịch vụ vẫn ổn).
• Luôn dùng for (pending period) để chống flapping — chỉ báo khi vấn đề kéo dài, bỏ qua spike thoáng qua. CPU nhảy 81% trong 10 giây không đáng đánh thức ai.
• Đặt severity label nhất quán (critical / warning / info) và định tuyến theo nó: critical → gọi điện/PagerDuty, warning → Slack, info → chỉ ghi log.
• Gom nhóm hợp lý qua group_by để một sự cố hạ tầng không tạo ra 200 thông báo. Đặt repeat_interval đủ dài (vài giờ).
• Luôn kèm runbook_url và summary rõ ràng — người trực lúc 3 giờ sáng cần biết ngay phải mở tài liệu nào, không phải đi hỏi cả team.
• Rà soát định kỳ: alert nào kêu suốt mà chẳng ai làm gì → sửa ngưỡng hoặc xoá. Sự cố nào xảy ra mà không có alert → thêm alert.