Airflow运行数周后出现日志文件不存在报错、DAG随机失败如何解决？
Log file does not exist: airflow_path/1.log
Fetching from: http://:8793/airflow_path/1.log
*** Failed to fetch log file from worker. The request to ':///' is missing either an 'http://
该报错的本质是Airflow Scheduler/Webserver构造日志拉取请求时，无法获取到执行任务的Worker节点的有效可访问地址，导致请求URL中Host字段为空，请求格式非法。此前运行稳定、近期才出现异常，通常是最近集群配置变更、组件状态异常导致的，常见触发原因如下：
- Worker节点的
worker_hostname配置被修改，或者启动参数中--hostname字段为空，Worker注册到集群时就没有上报有效地址 - 使用CeleryExecutor的场景下，Flower服务状态异常，无法正常返回Worker的地址信息给Scheduler
- 使用KubernetesExecutor的场景下，集群DNS服务异常、Worker Pod的hostname生成规则被修改，导致Scheduler拿到的Pod地址无效
- Airflow元数据库压力过高或存在数据损坏，读取Worker地址时返回空值
- 集群网络策略变更，Scheduler到Worker的8793端口通信被阻断，拉取地址的请求超时返回空
第一步：验证Worker基础配置
登录所有Worker节点，检查airflow.cfg中[core]段的worker_hostname参数，确保取值为Scheduler可以正常访问的IP或域名。如果Worker是通过命令行启动，检查启动命令是否加了--hostname参数，确认参数值不为空，正确的Celery Worker启动示例如下：airflow celery worker --hostname 10.0.0.xx --concurrency 4
第二步：验证网络连通性
登录Scheduler节点，执行命令测试到所有Worker节点8793端口的连通性：nc -zv <Worker的IP/hostname> 8793
如果连接失败，检查Worker节点的防火墙规则、集群网络策略，放开8793端口的入站规则。
第三步：CeleryExecutor场景专项排查
访问Flower服务UI，查看已注册的Worker列表，确认所有Worker的hostname字段都有有效值，没有空值或非法值。如果存在异常，先重启Flower服务，再依次重启所有Worker节点重新注册即可。
第四步：KubernetesExecutor场景专项排查
检查airflow.cfg中[kubernetes]段的worker_pod_hostname_template配置，确保模板可以正常生成可解析的Pod hostname；同时检查集群CoreDNS服务的运行状态，确认最近没有报错日志。
第五步：检查元数据库状态
连接Airflow元数据库，查询失败任务对应的Worker字段是否为空，示例查询语句（适配2.x版本）：select task_id, run_id, worker from task_instance where state='failed' and execution_date > 'xxxx-xx-xx';
如果返回的worker字段为空，说明Worker注册时就没有上报有效地址，回到第一步重新配置Worker的hostname参数即可。
临时快速恢复方案
如果需要先恢复业务，可以先开启远程日志存储，修改airflow.cfg中[core]段的remote_logging = True，配置日志存储到共享存储或者对象存储中，Scheduler会直接从远程存储读取日志，不需要再从Worker拉取，可暂时规避该问题。
内容的提问来源于stack exchange，提问作者VenuGupta
