使用官方docker-compose部署Airflow时容器不健康但日志无报错如何排查

• 先排查数据库连通性：进入卡住的airflow-init容器执行端口连通测试，执行 docker exec -it airflow_airflow-init_1 bash 进入容器后，运行 nc -zv my-db-endpoint 5432 或 telnet my-db-endpoint 5432，确认数据库端口可访问，同时核对数据库账号、密码、目标库是否存在等配置，init容器长期卡住绝大多数原因是数据库连接失败处于重试循环。
• 检查容器内端口监听状态：针对不健康的webserver、flower容器，进入容器后查看对应端口是否有进程监听，执行 docker exec -it airflow_airflow-webserver_1 netstat -tulpn | grep 8080，如果没有返回结果说明对应服务根本没有启动成功，健康检查自然失败。
• 手动执行健康检查命令获取详细报错：直接在容器内运行健康检查的完整命令，看详细返回结果，比如webserver容器执行 docker exec -it airflow_airflow-webserver_1 curl -v http://localhost:8080/，输出的详细请求日志可以帮你定位连接失败的具体原因。
• 检查容器资源使用状态：运行 docker stats 查看所有容器的CPU、内存占用，确认是否存在资源不足导致进程启动缓慢、崩溃的情况，也可以执行 docker inspect 容器ID | grep OOM 查看对应容器是否有被OOM kill的历史记录。
• 核对挂载目录权限：官方docker-compose默认会挂载本地的dags、logs、plugins目录到容器内，执行 ls -ld ./dags ./logs ./plugins 查看本地目录的权限配置，Airflow容器默认使用UID为50000的用户运行，如果本地目录权限不足会导致服务写不了日志、启动失败，你也可以按照日志提示将容器运行的GID修改为0规避权限问题。
• 查看完整日志和历史容器记录：执行 docker logs --tail 1000 容器ID 查看容器的完整运行日志，确认是否有被忽略的报错信息；如果有之前启动失败的容器，执行 docker ps -a 查看所有历史容器，取出异常容器的ID查看其日志定位崩溃原因。
• 检查容器内进程存活状态：进入目标容器后执行 ps aux 查看所有运行的进程，确认webserver、flower对应的启动进程是否存在，如果进程不存在说明服务启动时崩溃，只是父进程dumb-init还在运行，所以容器没有退出。

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