Airflow 在生产环境中跑任务，最怕的就是任务失败、调度卡住、资源耗尽这些破事。以前很多人靠肉眼盯着日志，费劲还不及时。其实用 Prometheus 和 Grafana 这对黄金搭档，就能轻松把 Airflow 的底裤扒干净——从任务状态到资源使用，再配上自动预警，出了问题第一时间知道。下面我就用最接地气的方式，手把手教你怎么搭这套监控系统。
一、Airflow 监控到底在监控什么
在动手搭工具之前，先要想清楚我们要盯着哪些指标。Airflow 虽然功能强大，但它的监控盲区也很多，比如任务突然失败了、某个 DAG 跑了几个小时还没结束、调度器负载太高导致任务排队。这些如果没人盯着，用户投诉或者业务受损了才追悔莫及。
1.1 任务状态指标
每个任务在生命周期里有多个状态：running（运行中）、success（成功）、failed（失败）、up_for_retry（准备重试）、queued（排队中）等等。最要命的当然是 failed，但有时候 queued 任务长期不处理、或者重试次数太多，也是危险的信号。我们需要知道实时有多少任务处于各个状态，以及任务失败率的变化趋势。
1.2 DAG 运行指标
DAG 是 Airflow 里的工作流容器，一个 DAG 会周期性地触发。我们要看的是 DAG 每次运行的耗时（duration），以及它的成功/失败次数。如果某个 DAG 的运行时间突然从 5 分钟变成 1 小时，很可能是有任务卡住了或者数据量暴增。另外，DAG 的 schedule_interval 是否正常，如果延迟了也需要关注。
1.3 调度器与执行器资源
Airflow 的调度器（Scheduler）和执行器（Executor，比如 CeleryExecutor）是干活的核心。调度器的心跳是否正常？执行器的工作进程数量够不够？数据库连接池有没有被占满？这些底层指标往往被忽略，但一旦出问题，整个 Airflow 就直接瘫痪。
二、用 Prometheus 采集 Airflow 指标
Prometheus 是一个开源的监控和告警系统，通过拉取（pull）模式定期从目标服务抓取指标。Airflow 本身提供了 Prometheus 指标的导出方式，我们只需要配置一下，就能把上述核心指标暴露出来让 Prometheus 收集。
2.1 安装 Airflow 的 Prometheus Exporter
Airflow 从 2.0 版本开始内置了基于 StatsD 的指标收集，但转换成 Prometheus 格式还需要一个适配器。最简单的方式是使用 airflow-prometheus-exporter 这个插件。在 Airflow 的 requirements.txt 中添加：
# requirements.txt 配置，安装插件（实际内容为纯文本，用yaml代码块表示）
# 注意：这里用yaml代码块只是展示文本内容，并非yaml格式
apache-airflow[prometheus]
然后在 airflow.cfg 中启用 Prometheus 指标导出：
# airflow.cfg 片段
[metrics]
# 开启指标收集
metrics_enabled = True
# 指定导出器类型为 Prometheus
metrics_exporter_type = prometheus
# 指标端点路径，默认是 /metrics
prometheus_endpoint = /metrics
配置完成后重启 Airflow 调度器和 web 服务，就可以访问 http://你的airflow地址:8080/metrics 看到一堆指标了。比如：
# HELP airflow_task_status 当前任务状态计数
# TYPE airflow_task_status gauge
airflow_task_status{dag_id="example_dag",status="failed"} 0
airflow_task_status{dag_id="example_dag",status="success"} 42
2.2 配置 Prometheus 拉取指标
有了指标端点，接下来要告诉 Prometheus 从哪里抓。下面是一个完整的 Prometheus 配置文件示例：
# prometheus.yml
# 全局配置
global:
scrape_interval: 15s # 每15秒抓一次
evaluation_interval: 15s
# 抓取目标配置
scrape_configs:
# Airflow 指标端点
- job_name: 'airflow'
scrape_interval: 30s # 任务状态变化不快，30秒够了
static_configs:
- targets: ['airflow-scheduler:8080'] # 如果是docker-compose，用服务名，否则用IP
labels:
service: 'airflow'
# 如果还监控其他组件的，可以继续添加
注意：这里 targets 的地址要改成你实际 Airflow 服务的地址。如果 Airflow 部署在 Kubernetes 里，可能需要用 Service 的 DNS 名称。
2.3 核心指标字段详解
Airflow 暴露的指标非常多，这里挑几个最实用的：
airflow_task_status：按 DAG 和状态统计的任务个数，比如airflow_task_status{dag_id="my_dag", status="failed"}。airflow_dag_duration：DAG 运行总时长，是个 histogram 类型，可以看分位值。airflow_scheduler_heartbeat：调度器最后心跳时间戳，如果长时间不更新说明调度器挂了。airflow_executor_open_slots：执行器空余槽位，如果是 0 说明全部占满，任务会排队。airflow_db_connections_usage：数据库连接池使用率，过高可能导致 SQL 错误。
这些指标在 Prometheus 的查询语言中可以直接使用，比如：increase(airflow_task_status[5m]) 可以看最近5分钟失败任务的增量。
三、用 Grafana 搭建可视化看板
光有原始指标数据不够直观，得做成漂亮的图表放在一起看。Grafana 就是干这个的，它连上 Prometheus 数据源，随便拖拽就能画出看板，还能配置预警规则，在指标异常时给你发邮件、钉钉或 Slack 通知。
3.1 配置 Grafana 数据源
首先确保 Grafana 已经启动并能访问 Prometheus。在 Grafana 的配置目录（比如 /etc/grafana/provisioning/datasources/）下创建一个 YAML 文件来自动添加数据源：
# datasource.yml
apiVersion: 1
datasources:
- name: Prometheus
type: prometheus
access: proxy
url: http://prometheus:9090 # Prometheus 服务地址
isDefault: true
editable: true
配置好后重启 Grafana，数据源就会自动出现。
3.2 设计关键图表
进入 Grafana 点击新建仪表盘，添加 Panel。这里介绍几个常用的指标查询示例，方便大家直接拿来用：
任务失败数折线图
查询语句：sum(increase(airflow_task_status{status="failed"}[5m])) by (dag_id)
这个会展示每个 DAG 在过去5分钟内新增的失败任务数，适合放在 Dashboard 顶部。
DAG 运行耗时分布
查询语句：histogram_quantile(0.95, sum(rate(airflow_dag_duration_bucket[5m])) by (le, dag_id))
这能得到95%分位的运行耗时，如果某个 DAG 的耗时突然飙升，说明有问题。
调度器健康状态
查询语句：time() - airflow_scheduler_heartbeat 如果结果超过60秒，说明调度器心跳丢失。
可以用 singlestat 面板显示当前值，并设置颜色变化。
执行器槽位使用率
查询语句：1 - (airflow_executor_open_slots / airflow_executor_max_slots)，用 gauge 面板显示百分比。
3.3 配置异常预警规则
预警是重点。我们可以在 Grafana 的 Alerting 模块中直接创建规则，也可以像下面这样用配置文件预置规则。Grafana 支持多种告警渠道，比如 Email、Webhook、钉钉等。
假设我们要在任务失败数连续5分钟大于0时发告警，可以在 Grafana 的 provisioning 目录创建告警规则文件：
# alert_rules.yml
apiVersion: 1
groups:
- name: airflow_alerts
rules:
- alert: TaskFailureTooFrequent
condition: >
avg() OF (A) IS ABOVE 0
annotations:
summary: "任务失败过多"
description: "过去5分钟失败任务数大于0，请立即检查"
dashboardUid: "your-dashboard-uid"
panelId: 1
更灵活的方式是在 Grafana 的界面里直接创建告警规则。比如在某个 Panel 的 Alert 选项卡设置：
- 条件：
MAX(airflow_task_status{status="failed"}) > 0持续5分钟 - 通知渠道：选择你配好的钉钉机器人或邮件
这样一旦指标异常，你就能在手机或电脑上第一时间收到告警。
四、应用场景与注意事项
4.1 适用场景
这套方案非常适合以下情况：
- 生产环境有几十上百个 DAG，每天成千上万次任务运行，人工检查不现实。
- 需要长期保留历史指标，方便事后分析任务失败原因。
- 团队需要及时收到告警，而不是等用户投诉。
- 想监控 Airflow 本身的性能瓶颈，比如调度器、数据库、执行器。
4.2 技术优缺点
优点：
- Prometheus 和 Grafana 都是开源、成熟、社区活跃，生态完善。
- 指标数据格式统一，查询语言灵活。
- 可视化非常强大，拖拽就可以做漂亮看板。
- 告警规则支持复杂表达式，还能对接多种通知方式。
缺点：
- 需要额外部署和配置 Prometheus、Grafana 以及 Airflow 的 metrics 插件，对刚入门的开发者有门槛。
- Prometheus 的存储是本地文件，如果数据量大需要合理规划磁盘和保留时间。
- 告警规则的配置不算直观，特别是复杂条件，需要反复调试。
4.3 常见坑点
- 指标端点访问不到：检查 Airflow 的 metrics 是否真的开启了，且防火墙没阻挡
/metrics路径。 - 指标名冲突：Airflow 不同版本导出的指标名可能略有不同，先 curl 一下看看实际名称再写 PromQL。
- 告警抖动：任务失败可能是临时网络波动，建议设置宽松的持续周期（比如连续2次才触发），避免频繁通知。
- 资源消耗：Prometheus 本身会消耗内存，如果指标数量巨大（比如几千个任务），建议调整 scrape_interval 或限制收集标签。
五、文章总结
用 Prometheus 加 Grafana 监控 Airflow 其实并不复杂，核心就是三步：第一步，在 Airflow 里打开 Prometheus 指标导出；第二步，让 Prometheus 定时拉取这些指标；第三步，在 Grafana 里画图表、配告警。要盯的指标就那几个——任务状态、DAG 耗时、调度器心跳、执行器槽位。剩下的就是根据自己业务需求微调告警阈值。这套方案一旦搭起来，每天上班先看 Grafana 仪表盘，心里就有底了。再结合钉钉或 Slack 告警，基本能保证问题在路上就被发现，而不是等到用户骂上门。希望这篇文章能帮你把监控真正用起来，不再做一个“盲人摸象”的调度管理员。
Comments