Airflow 监控实战：基于 Grafana + Prometheus 的指标可视化与告警配置

1. 为什么需要监控Airflow作为数据工程师我经历过太多次凌晨被电话叫醒处理Airflow任务延迟的情况。有一次凌晨3点整个数据仓库的ETL流程卡住了没有监控系统的情况下我们花了2个小时才定位到是某个DAG的解析时间过长导致调度器阻塞。如果当时有完善的监控体系可能10分钟就能解决问题。Airflow作为工作流调度系统其核心组件Scheduler、Worker、Webserver等的健康状态直接影响着数据管道的稳定性。实时监控能帮助我们提前发现资源瓶颈如CPU/内存不足快速定位任务延迟的根本原因预警关键指标异常如任务失败率激增优化系统配置如调整DAG扫描间隔2. 监控方案选型为什么是GrafanaPrometheus在对比了多种方案后我最终选择了GrafanaPrometheus的组合主要基于三个实际考量生态兼容性Airflow原生支持StatsD协议输出指标而Prometheus有成熟的StatsD导出器可视化能力Grafana的仪表盘可以灵活组合不同指标告警集成Grafana Alert支持邮件、企业微信等多种通知方式这个方案在我负责的多个生产环境中稳定运行了3年多日均处理超过5万个任务实例。下面分享具体实施细节。3. 实战部署步骤3.1 基础环境准备首先确保已有以下服务正常运行Airflow集群至少包含1个Scheduler和1个WorkerPrometheus服务建议v2.30Grafana服务建议v8.0我建议使用Docker部署StatsD导出器这是经过验证最稳定的方式# 创建映射配置文件目录 mkdir -p /data/statsd_export3.2 配置Airflow指标输出修改airflow.cfg中的metrics配置段[metrics] statsd_on True statsd_host statsd-exporter # Docker服务名或主机IP statsd_port 8125 statsd_prefix airflow-prod statsd_allow_list scheduler,executor,dagrun这里有个关键细节statsd_allow_list建议按需配置初期可以只监控核心组件。全量指标会导致Prometheus存储压力过大。我在生产环境曾因为全量采集导致Prometheus磁盘一天写入了500GB数据。3.3 部署StatsD导出器创建docker-compose.ymlversion: 3 services: statsd-exporter: image: prom/statsd-exporter:v0.22.3 ports: - 9102:9102 # 监控指标暴露端口 - 8125:8125/udp # StatsD接收端口 volumes: - ./statsd_mapping.yml:/tmp/statsd_mapping.yml command: - --statsd.mapping-config/tmp/statsd_mapping.yml - --statsd.listen-udp:8125映射配置文件statsd_mapping.yml需要精心设计。这是我优化过的版本mappings: - match: airflow.scheduler_heartbeat name: airflow_scheduler_heartbeat labels: component: scheduler - match: airflow.dag_processing.last_duration.* name: airflow_dag_processing_duration labels: dag_file: $1 - match: airflow.dagrun.duration.success.* name: airflow_dagrun_duration labels: dag_id: $13.4 配置Prometheus抓取在Prometheus的scrape_configs中添加- job_name: airflow static_configs: - targets: [statsd-exporter:9102] metrics_path: /metrics重启服务后可以在Prometheus的Graph页面查询airflow_开头的指标验证采集是否成功。4. Grafana仪表盘配置4.1 导入官方仪表盘我推荐使用社区维护的仪表盘模板访问Grafana官网的Dashboards页面搜索Airflow选择评分最高的模板如ID为11010下载JSON文件并在本地Grafana导入4.2 关键指标面板根据实战经验这几个面板最重要调度器健康状态心跳间隔应60sDAG解析耗时建议30s任务排队数量资源使用情况各Pool的可用Slot数饥饿任务数量执行中任务数DAG运行质量任务失败率DAG执行延迟关键路径耗时5. 告警规则配置5.1 核心告警规则在Grafana Alert中配置这些规则能覆盖90%的问题场景# 调度器失联告警 - alert: AirflowSchedulerDown expr: rate(airflow_scheduler_heartbeat[1m]) 0 for: 5m # DAG解析耗时告警 - alert: DAGProcessingSlow expr: airflow_dag_processing_duration 60 for: 10m # 关键任务失败告警 - alert: CriticalDAGFailed expr: increase(airflow_dagrun_failed{ dag_id~payment|order.* }[1h]) 05.2 告警通知渠道建议配置分级通知P0级问题如调度器宕机电话通知P1级问题如核心DAG失败企业微信/钉钉P2级问题如资源不足邮件通知6. 常见问题排查指标采集失败检查StatsD导出器日志docker logs statsd-exporter验证网络连通性telnet statsd-exporter 8125检查Airflow日志中是否有指标发送错误数据不准问题确认时区设置一致建议全部使用UTC检查Prometheus的抓取间隔建议15s验证指标映射规则是否正确性能影响StatsD导出器平均增加约3%的CPU开销。如果发现资源消耗过高调整statsd_allow_list减少指标量降低Prometheus抓取频率对指标做采样sample_rate这套监控体系在电商大促期间帮我们提前发现了多个潜在问题比如通过Pool使用率预测提前扩容了Worker节点。监控不是万能的但没有监控是万万不能的。