zops 任务卡住后管理节点 CPU 使用率过高

问题现象:

问题由 zops（ZStack Ops）任务卡住、并遗留大量 ansible-playbook 进程导致。

适用环境

• 产品：ZCF
• 版本：未指定
• 组件：Zstack Cloud
• 部署形态：任何使用 zops 执行维护或运维任务的 ZStack Cloud 部署

判断方法

1. 使用 ps -ef | grep ansible-playbook | wc -l 。
2. 在云平台 UI 上尝试发起云主机创建或运维相关操作，确认任务是否有卡顿。
3. 执行 top 监控，确认管理节点 CPU 使用率和负载状态。

问题根因

• zops 任务调度卡住：任务不再被消费，每次重试都会生成新的 ansible-playbook worker 进程。
• 某一个失败任务持续占用 worker 池：zops 日志中反复出现该失败任务， 导致资源持续耗尽。
• 管理节点底层资源争抢（内存、I/O 或上游服务延迟）导致任务无法完成。

解决方案

1. 确认管理节点的 CPU 使用率和平均负载

• 在受影响的管理节点上执行命令：

  top

• 预期结果：CPU 使用率超过 90%，平均负载达到数百（如 200 以上）。确认存在持续性的 CPU 饱和现象。

2. 识别占主导地位的进程族

• 执行命令统计 ansible-playbook 进程数：

  ps -ef | grep ansible-playbook | grep -v grep | wc -l

或

  ps -ef | grep ansible-playbook

• 预期结果：会返回数百甚至数千个（如 1,800+）ansible-playbook 进程.
• 解读：ansible-playbook worker 不断堆积，说明 zops 服务没有正常消费其任务队列。

3. 检查 zops 任务日志，定位反复失败的任务

• 检查 zops 日志目录（通常在 /var/log/zops/）：

  tail -n 200 /var/log/zops/zops.log

• 预期结果：出现大量失败任务日志，指向同一个任务或同一类任务。该任务即占用 worker 池的根因。
• 记录失败时间戳和任务名称，便于事后排查。

4. 重启 zops 服务

• 在管理节点上执行服务重启的 命令：

  systemctl restart zops

• 预期结果：zops 服务重启后，堆积的 ansible-playbook 进程自动退出，CPU 使用率和平均负载迅速回落至正常范围。

5. 持续观察服务状态

• 重启一小时后，定期检查系统负载和进程数量：

  top
  ps -ef | grep ansible-playbook | wc -l

• 预期结果：CPU 使用率保持正常（低于 50%），且 ansible-playbook 进程保持在低水平。

验证方法

1. 确认 ps -ef | grep ansible-playbook | wc -l 返回正常的少量数值
2. 在云平台 UI 上尝试发起云主机创建或运维相关操作，确认任务无卡顿。
3. 执行 top 监控，确认管理节点 CPU 使用率和负载恢复正常。

关联信息

• 相关命令：top、ps -ef、systemctl restart zops。
• 相关组件：zops 任务队列、ansible-playbook worker 池、管理节点资源监控。