Airflow 1.7 S3连接在Worker节点失败，请求排查解决建议

我之前在维护Airflow 1.7分布式集群时碰到过一模一样的问题，给你整理一套逐步排查的方案，应该能定位到根源：

• 确认Worker节点能读取到Airflow的S3连接配置
  Airflow 1.7默认把连接信息存在元数据库里，Worker必须能正常访问元数据库才能获取连接：

  • 在Worker节点启动Python Shell执行以下代码，检查连接是否存在：

    /usr/local/bin/python2.7
    import airflow.settings
    session = airflow.settings.Session()
    from airflow.models import Connection
    conn = session.query(Connection).filter(Connection.conn_id == 'remote_log_s3').first()
    print(conn)
    

  • 如果输出是None，说明Worker没读到连接：
    • 核对Worker节点airflow.cfg里的sql_alchemy_conn配置，确保和主节点完全一致，且Worker能ping通元数据库地址
    • 如果你是用本地文件存储连接（airflow.cfg里connections配置为文件路径），要确认Worker节点的对应文件里有这个S3连接，且文件权限允许Airflow用户读取

• 直接验证Worker节点的AWS权限（绕开Airflow Hook）
  403 Forbidden通常是权限或凭证问题，先排除Airflow Hook的干扰：

  • 在Worker节点用原生boto库测试S3写入：

    import boto
    # 替换成你连接里的AK/SK和日志桶名
    s3_conn = boto.connect_s3(aws_access_key_id='YOUR_ACCESS_KEY', aws_secret_access_key='YOUR_SECRET_KEY')
    bucket = s3_conn.get_bucket('YOUR_LOG_BUCKET')
    key = bucket.new_key('test/test_worker.txt')
    key.set_contents_from_string('test')
    

  • 如果这个测试也返回403：
    • 检查Worker节点的IAM角色（如果是EC2实例）是否有S3写入权限，或者~/.aws/credentials文件内容是否和主节点一致
    • 确认S3桶的策略没有限制Worker节点的IP或身份
  • 如果这个测试成功，说明问题出在Airflow Hook的配置或缓存上，继续往下排查

• 核对Worker与主节点的Airflow配置一致性
  配置不一致也会导致Hook行为异常：

  • 对比Worker和主节点airflow.cfg里的核心配置：
    • remote_base_log_folder：确认桶名和路径前缀完全一致，没有拼写错误
    • sql_alchemy_conn：再次确认元数据库连接配置
    • 检查Airflow版本，确保Worker节点的版本和主节点完全相同（Airflow 1.7的小版本差异也可能导致Hook问题）

• 检查Worker节点的环境变量差异
  主节点可能设置了AWS相关的环境变量，而Worker节点没同步：

  • 在主节点执行printenv | grep AWS，记下所有AWS相关的环境变量
  • 在Worker节点执行同样命令，对比是否有缺失的变量
  • 如果有缺失，需要在Worker的Airflow启动脚本里添加这些变量，或者在airflow.cfg的[env]段配置

• 清理Worker的Airflow缓存并重启
  Airflow 1.7会缓存连接信息，单纯重启Worker可能无法清除缓存：

  • 停止所有Worker进程：airflow worker stop（或对应你的启动方式）
  • 删除Worker节点的Airflow缓存目录，通常是~/.airflow/cache或者/tmp/airflow下的缓存文件
  • 重新启动Worker进程，再次测试连接

如果以上步骤都试过还是没解决，建议用tcpdump抓取Worker节点和S3的通信包，查看具体的403错误详情（比如是签名错误还是权限不足），能帮你更精准定位问题。

内容的提问来源于stack exchange，提问作者Andrew Kirk