单纯靠Docker重启策略无法实现真正可靠的无人值守运维，必须将重启动作嵌入监控告警闭环，结合健康检查、分级重启策略、智能Agent决策与可操作告警，形成“发现异常→判断原因→执行恢复→验证结果→通知留痕”自动链路。
单纯靠 docker 重启策略无法实现真正可靠的无人值守运维。必须把重启动作嵌入监控告警闭环中，让“发现异常→判断原因→执行恢复→验证结果→通知留痕”形成自动链路。
用健康检查作为重启的前置判断依据
Docker 自身的 HEALTHCHECK 是重启策略生效前的关键过滤器。它不依赖外部工具，直接在容器内验证服务真实可用性。
- 配置
--start-period=15s给应用冷启动留出缓冲时间，避免刚启动就被误判为失败 - 设置
--retries=3防止瞬时网络抖动或慢查询导致误标 unhealthy - 健康脚本应检测业务级状态，比如数据库连接、下游API连通性、本地端口可写性，而非仅检查进程是否存在
重启策略要匹配故障类型，不能一概用 always
盲目启用 --restart=always 可能掩盖严重问题，比如配置错误或内存泄漏引发的持续崩溃。
- 长期运行的 Web 服务推荐
unless-stopped：宿主机重启后自动拉起，且允许运维手动停机维护 - 有状态组件（如 MySQL）建议用
on-failure:3：只在非零退出码时重试，避免因磁盘满、权限错等根本性问题无限重启 - 任务型容器（如数据同步 Job）适合
no或on-failure，成功退出（code 0）不应被干扰
智能 Agent 做决策中枢，不止于发告警
监控系统不能只当“广播员”，而要成为“调度员”。Agent 需结合多维指标做复合判断：
- 当某容器 1 小时内重启超过 5 次，且每次间隔小于 30 秒 → 触发“疑似崩溃循环”，暂停自动重启并推送高优告警
- 若同时检测到该宿主机 CPU >95%、内存使用率 >92%，则判定为资源争抢，优先扩容或迁移容器，而非反复重启
- 采集
docker inspect -f '{{.State.Health.Status}}'和{{.RestartCount}}，把健康状态与重启次数一起上报，供告警规则交叉分析
告警通知必须带可操作上下文
一条有效告警不是“容器 web-service 不健康”，而是能直接指导下一步动作的信息包：
- 包含容器 ID、镜像版本、所在宿主机 IP、最近一次退出码和日志末尾 10 行
- 附带一键执行命令：
docker logs --tail 50 web-service或docker exec -it web-service curl -v http://localhost:8080/health - 若已集成 CI/CD 系统，可自动触发回滚到上一个稳定镜像的审批流程
