容器反复重启排障
结合退出码、OOMKilled、日志、重启策略与资源压力定位反复重启。
适用范围与前提
Docker Engine 容器；不直接用于 Kubernetes 控制器排障。
- 把 CONTAINER 替换为实际容器名或 ID，确认 Docker context 指向目标环境。
- 保留故障时间和现有容器信息；完整 inspect/env 可能包含密钥，不直接分享。
命令仅供手动复制到获授权的环境执行。站点不会连接服务器；涉及网络的诊断可能产生请求或登录审计记录。
1. 核对状态和退出信息
docker ps -a
docker inspect --format "{{json .State}}" CONTAINER预期现象：检查 ExitCode、OOMKilled、Error 和时间；137 可能是强制终止，不能单凭退出码认定 OOM。
- OOMKilled 为 true → 检查当前资源与限制
- 其他退出或启动错误 → 查看退出前后的有限日志
2. 查看退出前后的有限日志
docker logs --tail 100 --timestamps CONTAINER预期现象：区分配置缺失、依赖连接失败、权限错误和正常退出；日志驱动不支持读取时联系管理员。
- 有明确应用错误 → 修复建议（需人工确认）
- 日志不足或看似正常退出 → 对照重启策略与近期事件
3. 检查当前资源与限制
docker stats --no-stream CONTAINER
docker inspect --format "Memory={{.HostConfig.Memory}} NanoCpus={{.HostConfig.NanoCpus}}" CONTAINER预期现象：当前快照不等于崩溃前峰值；结合历史监控和主机内存压力，不直接取消限制。
- 资源不足或限制不合适 → 修复建议（需人工确认）
- 缺少历史证据 → 升级求助前收集
4. 对照重启策略与近期事件
docker inspect --format "{{json .HostConfig.RestartPolicy}}" CONTAINER
docker events --since 30m --until 1s --filter container=CONTAINER预期现象：查看是否因策略在正常退出后重启；外部编排/健康检查也可能触发重建，不能归因于容器进程本身。
- 策略或启动命令不符业务预期 → 修复建议（需人工确认）
- 疑似外部编排或宿主机事件 → 升级求助前收集
修复建议（需人工确认）
- 修正应用配置或依赖前先备份现有部署定义，经负责人确认后安排重建；避免在运行容器内做不可追踪修改。
- 根据历史用量和主机容量调整资源，不直接移除内存限制；重启不能替代内存泄漏调查。
- 调整重启策略需确认业务目标，不能通过禁用重启来宣称故障已修复。
验证恢复
- 观察跨越原有重启周期的稳定运行，复查退出时间、日志和资源曲线。
- 验证业务健康检查与实际请求，而不只是 docker ps 显示 Up。
升级求助前收集
- 容器状态、退出码、OOMKilled、脱敏日志、资源限制、近期事件及部署变更。