How We Monitor Apache Airflow in Production

Gojek · 2020 · 2. Tăng trưởng · Độ khó: Dễ — bài gốc

Bài hướng dẫn ngắn; giá trị ở danh sách những gì cần đo cho một nền tảng điều phối dữ liệu.

Bối cảnh

Đội Data Engineering của Gojek chạy hơn một nghìn pipeline trên Airflow (2020). Ngoài scheduler, webserver, worker, executor, họ có thêm tiến trình riêng: đồng bộ DAG từ GCS/git, đồng bộ biến Airflow tuỳ biến. Theo họ, càng nhiều thành phần thì càng dễ hỏng.

Đường metric: mỗi tiến trình Airflow (trong pod Kubernetes) bật client statsd trong airflow.cfg, gửi UDP tới Telegraf; tiến trình tự viết cũng phát heartbeat theo cách đó. Telegraf ghi vào InfluxDB; Grafana để xem, Kapacitor để alert.
Sửa tên metric: metric statsd của Airflow lúc đó còn sơ khai, vào InfluxDB không theo cấu trúc họ muốn; họ viết template statsd cho Telegraf để tách tên DAG, task… thành tag (ví dụ dag_duration, dagrun_schedule_delay, dag_loading-duration).
Danh sách nên giám sát: health của scheduler, webserver, worker và tiến trình tự viết (uptime); số worker; số DAG active và thời gian parse DAG; xu hướng dùng pool; trạng thái job, task của executor (running/queued/open slot), theo operator, theo task instance; thời gian của task và sensor quan trọng; thời gian DAG tới trạng thái cuối; schedule delay; thời gian kiểm phụ thuộc. Đo ở mức tổng và từng DAG/task, đặc biệt các operator dễ hỏng hoặc tốn tài nguyên.
Alert bằng TICK script: alert deadman khi heartbeat của scheduler mất 5 phút; ngưỡng warn/crit cho số Celery worker. Họ nhắc phải giám sát cả InfluxDB, Kapacitor, Grafana.

Với nền tảng điều phối, lỗi thường hiện ra là "job không chạy" chứ không phải "job lỗi"; vì vậy heartbeat, schedule delay và thời gian parse quan trọng ngang tỉ lệ lỗi (Pipeline dữ liệu và analytics, Observability và monitoring).

Alert kiểu deadman (không thấy tín hiệu trong N phút) bắt được thành phần chết lặng mà alert ngưỡng không bắt.
Đo độ trễ lập lịch, không chỉ thời gian chạy.
Hệ giám sát cũng cần được giám sát.