使用Ansible管理AWS机器时Python脚本仅部分运行的问题排查

这种场景我在运维AWS集群时碰到过好几次，给你梳理几个核心排查方向，一步步来定位问题：

1. 先抓Ansible的详细执行日志 #

别只看表面的成功/失败，加-vvv参数重新跑一遍playbook，把每台机器的执行细节打出来：

ansible-playbook your_playbook.yml -vvv

重点盯失败机器的输出，看看这几个关键点：

• 脚本script.py是不是真的传到目标机器了？有没有权限问题？比如是不是忘了给脚本加执行权限，或者运行Ansible的用户没读脚本的权限？
• 执行python3 script.py的时候有没有报错被吞？比如脚本依赖的Python库没装，或者有些机器上python3命令不存在（得用python代替）。

2. 注意无限循环脚本的后台运行问题 #

你跑的是while True的持续脚本，Ansible默认会等着命令执行完才结束会话，但这种无限循环的脚本会让Ansible一直挂着，很容易因为超时、网络波动被强制终止。
刚好成功的是5台，大概率是Ansible默认的并发数（forks=5）刚好跑完这5台，剩下的在排队时触发了超时，或者会话被打断了。
解决办法是把脚本放到后台运行，同时重定向输出避免阻塞会话，比如用：

nohup python3 script.py > /var/log/script_run.log 2>&1 &

更靠谱的方式是把脚本做成systemd服务，这样系统会自动托管进程，就算机器重启也能自动启动，还方便查看状态。

3. 检查失败机器的系统资源状态 #

有些时候脚本没运行是因为机器本身资源不够：

• 用free -h看看内存是不是满了，Python进程启动需要一点内存，内存不足会被OOM killer直接干掉；
• 用ulimit -u检查当前用户的最大进程数，是不是已经到上限了；
• 翻系统日志，比如/var/log/syslog或者/var/log/messages，搜python3或者script.py，看看有没有被系统杀掉的记录。

4. 调整Ansible的并发数试试 #

Ansible默认的并发数是5，刚好你有5台成功，剩下的可能还在排队或者因为并发限制没被执行？
要么改ansible.cfg里的forks参数，要么跑playbook时加-f 10（或者更大的数）强制提高并发：

ansible-playbook your_playbook.yml -f 10

看看剩下的机器能不能正常执行。

5. 手动在失败机器上跑脚本排除问题 #

把script.py拷到一台失败的机器上，手动执行python3 script.py，看看能不能正常运行。有时候脚本里可能有依赖机器环境的逻辑，比如读取某个特定路径的文件，而那台机器上没有这个路径，就会直接报错退出，Ansible如果没捕获到错误（比如后台运行时没返回码），就会显示“成功”但实际脚本没起来。

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