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 启动恢复任务