Ansible本身不直接检查负载，而是通过setup获取CPU核心数、command读取/proc/loadavg、assert计算标准化负载饱和度（load5/cores≤0.7）来安全断言；也可用自定义脚本+fetch归档或cron定时自治采集，需规避shell解析陷阱并适配异构集群。
Ansible 本身不直接“检查负载”，而是通过执行远程命令或调用模块，收集并判断负载状态。关键在于：用 幂等、安全、可断言 的方式获取负载数据，并基于 CPU 核心数做合理判断，避免误报或漏报。
用 setup + assert 判断负载饱和度
这是最推荐的方式，不依赖 shell 脚本，纯模块化、无副作用：
- 利用
setup模块自动采集ansible_processor_cores（逻辑 CPU 数） - 用
command模块运行awk '{print $1,$2,$3}' /proc/loadavg获取三段负载值 - 用
assert模块对 5 分钟负载做标准化计算：load5 / cores （对延迟敏感服务） - 失败时输出清晰提示，如
"Load saturation (5min) is {{ load5 | float / cores | round(2) }} > 0.7"
用自定义脚本 + fetch 实现巡检归档
适合需要日志留存、多指标联动（如负载+CPU+磁盘）的场景：
- 把负载检查逻辑写进
/tmp/check_load.sh，例如：cores=$(nproc); read one five fifteen - 用
copy模块下发脚本，command执行，fetch拉回结果到控制机 - 脚本输出可直接写入
/var/log/load-check-$(date +%F).log，便于后续 grep 或 ELK 分析
结合 cron + Ansible 定时触发
Ansible 不是守护进程，需借助系统定时任务触发检查：
- 用
ansible.builtin.cron模块在目标节点部署定时任务，例如每 5 分钟运行一次sh /usr/local/bin/load_check.sh >> /var/log/load.log 2>&1 - 再用 Ansible 定期
fetch日志文件，或通过stat检查日志 mtime 判断是否按时执行 - 避免在 playbook 中频繁轮询，减少连接开销；让节点自治采集，Ansible 只负责拉取和校验
规避常见陷阱
实际使用中容易踩坑的地方：
-
shell和command模块默认忽略--check模式，无法真正模拟 —— 若需 check mode 支持，必须加changed_when: false并显式设check_mode: true分支 - 不要只看绝对负载值（如 load=3.2），必须除以
nproc得到饱和度；4 核机器 load=3.2 是健康，32 核机器 load=3.2 是极空闲 - 避免用
uptime解析字符串 —— 输出格式受 locale 影响，/proc/loadavg更稳定可靠 - 若集群异构（不同 CPU 核数），建议用
group_by或when: ansible_processor_cores >= 8区分策略
