在做 Airflow 運維的這幾年里，我發現光是把 DAG 部署上去遠遠不夠，真正的挑戰是：如何持續觀測和監控系統的運行情況。

這篇文章是我閱讀和實踐 Airflow 2.x 后整理的筆記，重點聊聊兩個層面：

1. 核心 Airflow 組件的監控（scheduler、數據庫、triggerer、executors、web server）

2. DAG 自身的監控（日志、告警、SLA、性能分析）

寫這篇文章的出發點很簡單：很多團隊一開始都低估了監控的重要性，結果問題爆發時手忙腳亂。我自己也踩過不少坑，所以想用更接地氣的方式總結一下。

主動監控 vs 抑制監控

在正式展開之前，先厘清兩個概念：

? 主動監控（active monitoring）定期去探測服務的健康狀態，比如調用 /health 接口，如果發現掛了就觸發告警。?? 舉例：Prometheus 定時拉取 Airflow scheduler 的指標。

? 抑制監控（suppressive monitoring）系統定期主動匯報“我沒問題”，如果長時間沒收到消息，才認為有問題。?? 舉例：用 Healthchecks 這類工具，讓 DAG 每次跑完就 ping 一下，如果沒收到，就認為 SLA miss。

這兩個模式在 Airflow 運維里都會用到。

一、監控核心 Airflow 組件

Airflow 的核心組件如果掛了，整個系統就可能停擺。所以，至少要有一條監控規則：它們是不是還活著？

最簡單的方式就是查詢 Web Server 的 /health/ API，返回的 JSON 能告訴你各個組件的狀態。

1. Scheduler

Scheduler 是 Airflow 的心臟，必須 7x24 小時健康運轉。常見的指標有：

? scheduler.scheduler_loop_durationScheduler 循環一次調度所需的時間。如果這個值越來越高，說明調度壓力過大，任務可能開始延遲甚至 miss SLA。

? scheduler.tasks.starving有多少任務因為資源不夠而無法調度。長期高企，說明你的池（pool）或資源配置有問題。

? scheduler.tasks.executable等待執行的任務數量。如果這個值一直很大，意味著 worker 不夠用了。

?? 小技巧：有些團隊會加一個 canary DAG（只含一個簡單任務），用它來確認調度器是否真的能調度任務，而不僅僅是“活著”。

2. Metadata Database

元數據庫是 Airflow 的“黑匣子”，記錄了所有 DAG 和任務的運行歷史。一旦出問題，后果極其嚴重。

需要重點關注：

? 連接池大小/使用率：防止連接被占滿。

? 查詢性能：延遲高可能拖慢整體系統。

? 磁盤空間：數據庫滿了，Airflow 基本就廢了。

? 備份狀態：必須有災備方案。

?? 我的建議：用云廠商的托管數據庫，別自己運維 PostgreSQL/MySQL，省心又穩。

3. Triggerer

Triggerer 負責異步任務的調度（deferrable operators），Airflow 2.0 之后特別重要。

監控指標：

? triggers.blocked_main_thread：主線程被阻塞的次數。增長過快要警惕。

? triggers.running：當前運行的 triggers 數量。如果太多，說明要加 Triggerer 實例。

4. Executors / Workers

不同執行器需要不同的監控方式：

? Kubernetes Executor：重點關注 Pod 的 CPU/內存資源使用，避免 OOM 或調度延遲。

? Celery Executor：

Worker 的 CPU/內存

消息隊列（Redis/RabbitMQ）的健康度

隊列長度（queue length）：如果任務堆積，說明 worker 數量不夠

?? 推薦用 Flower 來監控 Celery，更直觀。

5. Web Server

Web Server 既是 UI，也是 REST API 接口，性能也要盯著：

? 響應時間

? 錯誤率（4xx / 5xx）

? 請求速率

? 系統資源利用率

? 吞吐量

特別是你用 API 控制調度的時候，Web Server 的穩定性至關重要。

二、監控你的 DAGs

核心組件健康只是第一步，更重要的是確認 DAG 本身是否“靠譜”。

1. 日志（Logging）

Airflow 的日志是分層的：DAG → Task → 嘗試次數。你可以在 UI 里直接看，也可以把日志送到外部系統（S3、Elasticsearch、GCS 等）。

?? 寫自定義 Operator 時，用標準的 Python logging 模塊即可，Airflow 會幫你處理。

2. 告警（Alerting）

Airflow 提供了多種方式：

? Email：配置 email_on_failure 或 email_on_retry。

? Callbacks：更靈活，可以觸發自定義動作。常見的有：

on_failure_callback：強烈推薦，DAG 出問題必須有告警。

sla_miss_callback：DAG 超過 SLA 時觸發。

on_retry_callback / on_execute_callback：慎用，容易太吵。

?? 我的經驗：少而精，別把團隊淹沒在告警風暴里。

3. SLA 監控

Airflow 自帶的 SLA 功能不太好用，很多人都說“幾乎是壞掉的”。我更推薦用 Healthchecks 這種外部工具：

? 每次 DAG 成功就 ping 一下

? 如果長時間沒 ping 到，就自動觸發告警

這種方式更直觀，也符合“抑制監控”的思路。

4. 性能分析（Profiling）

Airflow UI 自帶了一些好用的工具：

? Gantt 圖：看任務執行順序和耗時，定位瓶頸。

? 任務持續時間趨勢：找出是否有任務越來越慢。

? Landing time：DAG 結束和任務完成之間的差值，可以反映 Scheduler 是否壓力過大。

其他常見指標：

? 任務啟動時間：對 K8s executor 特別有用，可以看出調度延遲。

? 任務失敗/重試次數：穩定性的重要參考。

? DAG 解析時間：如果 DAG 文件加載很慢，Scheduler 整體都會受影響。

總結

這一章我整理的重點是：

? 核心 Airflow 組件監控：Scheduler、數據庫、Triggerer、Executors、Web Server。

? DAG 監控：日志、告警、SLA、性能分析。

? 兩種監控模式：主動 vs 抑制。

我的經驗是：別等到生產掛掉才去想“我們是不是應該監控一下”。Airflow 本質上是個調度系統，只有持續監控，才能確保它真的在“調度”而不是“掉隊”。