容器重启策略需与监控工具协同实现故障可观测性：通过on-failure、always等策略暴露异常模式，结合healthcheck探针、prometheus/cadvisor、elk日志及zabbix集成，将重启行为转化为可告警信号，并规避live-restore未启用、--start-period过短等常见断点。
容器重启策略本身不直接提供监控能力，但它和运维工具配合后，能显著提升故障发现与自愈效率。关键在于把“是否该重启”变成“为什么重启”，再把“重启行为”变成可观测信号。
用 restart 策略暴露异常模式
重启策略不是兜底开关，而是异常指标的放大器：
- on-failure:3 配合日志采集工具（如 Filebeat + ELK），连续三次重启会集中产生相似错误日志，自动触发告警
-
always 或 unless-stopped 容器若在 1 分钟内反复启动/退出，说明健康检查失败或进程闪退，Prometheus 可通过
container_restarts_total指标识别该模式 - 避免用 no 策略运行核心服务——它会让故障“静默”，失去监控入口
健康检查（HEALTHCHECK）是监控的数据源
Docker 原生健康状态是轻量级、标准化的监控信号：
- 在 Dockerfile 中定义
HEALTHCHECK --interval=30s --retries=3 CMD curl -f http://localhost/health || exit 1，让每个容器自带探针 - 用
docker inspect --format='{{.State.Health.Status}}' container_name获取实时状态，脚本可定时拉取并上报到 Zabbix 或 Prometheus Pushgateway - Swarm 或 Kubernetes 会自动消费该状态：Swarm 将 unhealthy 容器从 ingress 路由中剔除；K8s 的 livenessProbe 失败则触发重启
与主流监控栈集成的关键配置
不需要重写逻辑，只需打通数据链路：
-
Prometheus + cAdvisor：cAdvisor 默认暴露
container_last_seen和container_health_status，搭配 Grafana 看板可直观看到“哪些服务最近频繁重启” -
Zabbix：通过自定义 key（如
docker.health.status[web]）调用 shell 脚本执行docker inspect，状态为unhealthy时触发告警 -
ELK 日志分析：在容器启动命令中加入标识，例如
sh -c 'echo "[START] $(date)" >> /var/log/app.log && exec your-app'，结合重启次数统计，快速定位是启动失败还是运行中崩溃
避免常见断点
策略生效但监控失效，往往卡在这几个环节：
- 宿主机 Docker daemon 未启用
live-restore: true，系统重启后容器状态丢失，监控中断 - HEALTHCHECK 的
--start-period设置过短（如 5s），应用还没初始化完就被判定失败，造成误重启和误告警 - 监控工具只采集
docker ps输出，而该命令不显示 health 状态——必须用docker inspect或 API 接口
