Giám sát và cảnh báo

Bạn sẽ học được

• Năm tín hiệu cần giám sát trong pipeline.
• Phân biệt cảnh báo hành động được và cảnh báo nhiễu.
• Thiết kế định tuyến cảnh báo theo mức độ.
• Viết kiểm tra độ tươi dữ liệu.
• Xây runbook cho sự cố thường gặp.

Khái niệm cốt lõi

Giám sát pipeline không chỉ là "task có đỏ không". Có năm tín hiệu:

Ba tín hiệu đầu bắt được phần lớn sự cố. Tín hiệu thứ hai đặc biệt quan trọng vì nó bắt được trường hợp pipeline im lặng — không task nào chạy, không lỗi nào hiện.

Vì sao "DAG xanh" không đủ

Ba tình huống DAG xanh nhưng dữ liệu sai:

1. Không có gì chạy. Scheduler dừng, DAG bị tắt, hoặc lịch sai. Không task nào thất bại.
2. Chạy nhưng nguồn rỗng. Task thành công với 0 dòng.
3. Chạy nhưng ghi sai. Trùng dữ liệu, sai ngày, thiếu cột.

Cả ba đều cần giám sát bên ngoài trạng thái task.

Kiểm tra độ tươi

SELECT
  MAX(updated_at) AS lan_cuoi,
  now() - MAX(updated_at) AS tre
FROM fact_orders;

Task giám sát:

from airflow.exceptions import AirflowException

@task
def check_freshness():
    tre = query_one("""
        SELECT EXTRACT(EPOCH FROM now() - MAX(updated_at)) / 3600
        FROM fact_orders
    """)
    if tre > 26:
        raise AirflowException(f"Dữ liệu đã trễ {tre:.1f} giờ")

Ngưỡng 26 giờ cho pipeline hằng ngày: 24 giờ cộng 2 giờ dung sai.

Task này nên nằm trong một DAG giám sát riêng, chạy độc lập với DAG sản xuất. Nếu đặt trong chính DAG sản xuất, khi DAG đó không chạy thì kiểm tra cũng không chạy.

Phát hiện bất thường khối lượng

WITH hom_nay AS (
  SELECT COUNT(*) AS n FROM fact_orders WHERE order_date = CURRENT_DATE - 1
),
lich_su AS (
  SELECT AVG(n) AS tb, STDDEV(n) AS do_lech
  FROM (
    SELECT order_date, COUNT(*) AS n
    FROM fact_orders
    WHERE order_date BETWEEN CURRENT_DATE - 30 AND CURRENT_DATE - 2
    GROUP BY 1
  ) t
)
SELECT h.n, s.tb, s.do_lech,
       (h.n - s.tb) / NULLIF(s.do_lech, 0) AS z_score
FROM hom_nay h CROSS JOIN lich_su s;

z_score dưới −3 là bất thường đáng kiểm tra. Với dữ liệu có mùa vụ, so cùng thứ trong tuần thay vì trung bình 30 ngày.

Cảnh báo có thể hành động

Một cảnh báo tốt phải trả lời được:

• Chuyện gì xảy ra?
• Ở đâu (DAG, task, bảng)?
• Khi nào (logical date)?
• Làm gì tiếp (runbook)?

Ví dụ tốt:

[P1] daily_orders.load thất bại 2 lần
Logical date: 2026-03-11
Lỗi: connection timeout tới warehouse
Runbook: wiki/runbooks/warehouse-timeout

Ví dụ tồi:

Task failed

Cảnh báo tồi tạo thói quen bỏ qua, và khi sự cố thật xảy ra không ai đọc.

Định tuyến theo mức

Mỗi mức cần một người chịu trách nhiệm. Cảnh báo không có người nhận là cảnh báo vô nghĩa.

Runbook

Mỗi sự cố thường gặp cần một trang runbook:

1. Kiểm tra trạng thái task và log lỗi.
2. Xác định logical date bị ảnh hưởng.
3. Kiểm tra nguồn dữ liệu có sẵn không.
4. Nếu lỗi tạm thời: clear task và theo dõi.
5. Nếu dữ liệu sai: sửa, chạy lại theo partition.
6. Xác nhận số dòng và tổng tiền sau khi chạy lại.

Runbook rút ngắn thời gian xử lý và giảm phụ thuộc vào một người.

Chỉ số nên theo dõi

• Tỷ lệ lần chạy thành công theo tuần.
• Thời lượng p95 của từng task.
• Số lần retry trung bình.
• Độ trễ dữ liệu so với cam kết.
• Số cảnh báo mỗi tuần — nếu tăng liên tục, xem lại ngưỡng.

Cảnh báo quá nhiều là dấu hiệu ngưỡng sai, không phải hệ thống tệ.

Lỗi thường gặp

• Chỉ giám sát trạng thái task: bỏ lỡ pipeline im lặng.
• Cảnh báo không có runbook: người nhận không biết làm gì.
• Mọi cảnh báo cùng một kênh: mất phân loại ưu tiên.
• Ngưỡng cố định cho dữ liệu mùa vụ: báo động sai.
• Gửi cảnh báo mỗi lần retry: nhiễu.
• Không có người chịu trách nhiệm: cảnh báo bị bỏ qua.

Thực hành

1. Viết truy vấn độ tươi cho một bảng.
2. Đặt ngưỡng 26 giờ và giải thích.
3. Viết mẫu cảnh báo có đủ bốn thông tin.
4. Thiết kế định tuyến P1–P4.
5. Viết runbook cho lỗi timeout kho dữ liệu.

Lỗi thường gặp

Tóm tắt

• Năm tín hiệu: thất bại, độ tươi, khối lượng, thời lượng, chất lượng.
• "DAG xanh" không đủ để kết luận dữ liệu đúng.
• Cảnh báo phải có chuyện gì, ở đâu, khi nào, làm gì.
• Định tuyến theo mức và có người chịu trách nhiệm.
• Runbook là một phần của hệ thống giám sát.