在做 Airflow 運(yùn)維的這幾年里，我發(fā)現(xiàn)光是把 DAG 部署上去遠(yuǎn)遠(yuǎn)不夠，真正的挑戰(zhàn)是：如何持續(xù)觀測和監(jiān)控系統(tǒng)的運(yùn)行情況。

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

1. 核心 Airflow 組件的監(jiān)控（scheduler、數(shù)據(jù)庫、triggerer、executors、web server）

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

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

主動監(jiān)控 vs 抑制監(jiān)控

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

? 主動監(jiān)控（active monitoring）定期去探測服務(wù)的健康狀態(tài)，比如調(diào)用 /health 接口，如果發(fā)現(xiàn)掛了就觸發(fā)告警。?? 舉例：Prometheus 定時拉取 Airflow scheduler 的指標(biāo)。

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

這兩個模式在 Airflow 運(yùn)維里都會用到。

一、監(jiān)控核心 Airflow 組件

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

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

1. Scheduler

Scheduler 是 Airflow 的心臟，必須 7x24 小時健康運(yùn)轉(zhuǎn)。常見的指標(biāo)有：

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

? scheduler.tasks.starving有多少任務(wù)因?yàn)橘Y源不夠而無法調(diào)度。長期高企，說明你的池（pool）或資源配置有問題。

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

?? 小技巧：有些團(tuán)隊(duì)會加一個 canary DAG（只含一個簡單任務(wù)），用它來確認(rèn)調(diào)度器是否真的能調(diào)度任務(wù)，而不僅僅是“活著”。

2. Metadata Database

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

需要重點(diǎn)關(guān)注：

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

? 查詢性能：延遲高可能拖慢整體系統(tǒng)。

? 磁盤空間：數(shù)據(jù)庫滿了，Airflow 基本就廢了。

? 備份狀態(tài)：必須有災(zāi)備方案。

?? 我的建議：用云廠商的托管數(shù)據(jù)庫，別自己運(yùn)維 PostgreSQL/MySQL，省心又穩(wěn)。

3. Triggerer

Triggerer 負(fù)責(zé)異步任務(wù)的調(diào)度（deferrable operators），Airflow 2.0 之后特別重要。

監(jiān)控指標(biāo)：

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

? triggers.running：當(dāng)前運(yùn)行的 triggers 數(shù)量。如果太多，說明要加 Triggerer 實(shí)例。

4. Executors / Workers

不同執(zhí)行器需要不同的監(jiān)控方式：

? Kubernetes Executor：重點(diǎn)關(guān)注 Pod 的 CPU/內(nèi)存資源使用，避免 OOM 或調(diào)度延遲。

? Celery Executor：

Worker 的 CPU/內(nèi)存

消息隊(duì)列（Redis/RabbitMQ）的健康度

隊(duì)列長度（queue length）：如果任務(wù)堆積，說明 worker 數(shù)量不夠

?? 推薦用 Flower 來監(jiān)控 Celery，更直觀。

5. Web Server

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

? 響應(yīng)時間

? 錯誤率（4xx / 5xx）

? 請求速率

? 系統(tǒng)資源利用率

? 吞吐量

特別是你用 API 控制調(diào)度的時候，Web Server 的穩(wěn)定性至關(guān)重要。

二、監(jiān)控你的 DAGs

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

1. 日志（Logging）

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

?? 寫自定義 Operator 時，用標(biāo)準(zhǔn)的 Python logging 模塊即可，Airflow 會幫你處理。

2. 告警（Alerting）

Airflow 提供了多種方式：

? Email：配置 email_on_failure 或 email_on_retry。

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

on_failure_callback：強(qiáng)烈推薦，DAG 出問題必須有告警。

sla_miss_callback：DAG 超過 SLA 時觸發(fā)。

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

?? 我的經(jīng)驗(yàn)：少而精，別把團(tuán)隊(duì)淹沒在告警風(fēng)暴里。

3. SLA 監(jiān)控

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

? 每次 DAG 成功就 ping 一下

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

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

4. 性能分析（Profiling）

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

? Gantt 圖：看任務(wù)執(zhí)行順序和耗時，定位瓶頸。

? 任務(wù)持續(xù)時間趨勢：找出是否有任務(wù)越來越慢。

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

其他常見指標(biāo)：

? 任務(wù)啟動時間：對 K8s executor 特別有用，可以看出調(diào)度延遲。

? 任務(wù)失敗/重試次數(shù)：穩(wěn)定性的重要參考。

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

總結(jié)

這一章我整理的重點(diǎn)是：

? 核心 Airflow 組件監(jiān)控：Scheduler、數(shù)據(jù)庫、Triggerer、Executors、Web Server。

? DAG 監(jiān)控：日志、告警、SLA、性能分析。

? 兩種監(jiān)控模式：主動 vs 抑制。

我的經(jīng)驗(yàn)是：別等到生產(chǎn)掛掉才去想“我們是不是應(yīng)該監(jiān)控一下”。Airflow 本質(zhì)上是個調(diào)度系統(tǒng)，只有持續(xù)監(jiān)控，才能確保它真的在“調(diào)度”而不是“掉隊(duì)”。