ansible可通过主动探测与条件触发构建服务异常自动重启机制：先用systemd、command或stat模块检查健康状态，再以failed_when+ignore_errors或until循环触发重启；配置变更则用notify+handlers实现幂等重启，并可集成定时任务或prometheus告警联动。
Ansible 本身不内置实时事件监听能力，但可以通过“主动探测 + 条件触发”的组合方式，构建可靠的服务异常自动重启恢复机制。核心在于用任务检查服务状态，再根据结果决定是否执行恢复动作，整个过程可嵌入定期运行的 playbook 或与外部监控系统联动。
服务健康检查是自动恢复的前提
必须先确认服务是否真的异常，不能仅凭“启动失败”就盲目重启。常用方法包括：
- 用 systemd 模块查服务状态：
state: started并配合enabled: yes确保开机自启，模块会自动判断是否需启动 - 用 command 或 shell 执行检查命令，例如：
systemctl is-failed nginx或curl -f http://localhost:80/health || exit 1 - 用 stat 模块验证关键进程文件（如
/proc/PID）或 socket 文件是否存在
检测到异常后触发重启的两种主流方式
方式一：直接在任务中用 failed_when + ignore_errors 控制流程
- 先执行健康检查任务，设
ignore_errors: yes - 用
failed_when明确定义“什么算异常”，比如result.rc != 0或"failed" in result.stdout - 后续任务用
when: check_result.failed判断是否执行重启
方式二：用 until 循环实现带重试的恢复
- 适合服务启动有延迟或依赖未就绪的场景
- 例如：
shell: systemctl start myapp && systemctl is-active --quiet myapp，配until: result.rc == 0、retries: 3、delay: 5
配置变更类重启推荐用 notify + handlers
这不是响应“异常”，而是响应“配置更新”，但属于运维中最常见的自动恢复场景之一：
- 当 copy、template 或 lineinfile 修改了服务配置文件时，任务返回
changed: true - 此时通过
notify: Restart MyApp触发 handler - handler 中用 systemd 模块执行
state: restarted，确保新配置生效 - 优势是避免无谓重启——只有真正变了才动，幂等且安全
集成进自动化巡检周期
把恢复逻辑封装成独立 playbook，再通过定时任务驱动：
- 用 ansible-pull 模式让受管节点定时拉取并执行恢复剧本
- 在控制节点用 cron 调用
ansible-playbook health-check.yml - 更进一步可结合 Prometheus Alertmanager：告警触发 webhook，调用 Ansible Tower / AWX API 启动恢复任务
