生产环境中Docker容器高效运维的核心在于建立轻量闭环机制，覆盖容器、应用、基础设施三层指标：容器层关注运行状态与健康检查，应用层监控HTTP响应码与延迟，宿主机层跟踪磁盘空间与内核OOM日志；推荐Prometheus+cAdvisor+Loki+Grafana技术栈实现可观测性，并结合语义化镜像标签、弹性资源限制与可审计清理策略保障可控性。
监控必须覆盖三层指标
只看 CPU 和内存远远不够。真正影响业务的是容器、应用、基础设施三者的叠加状态：
-
容器层：运行状态（Up/Exited）、重启次数、OOMKilled 事件、健康检查失败率（用
HEALTHCHECK配置） - 应用层：HTTP 响应码分布（尤其是 5xx）、平均响应时间、请求吞吐量（QPS）、队列积压（如消息队列消费者 lag）
-
宿主机层：磁盘 inode 使用率、/var/lib/docker 空间、网络丢包率、内核 OOM 日志（
dmesg -T | grep -i "killed process"）
推荐用 Prometheus + cAdvisor + node_exporter + 应用埋点（如 Micrometer）统一采集，Grafana 做单面板聚合视图——比如一个服务卡片同时显示容器存活率、P95 延迟、错误率、CPU 使用率。
日志不能只靠 docker logs
本地日志随容器销毁而丢失，且无法跨节点检索。生产中必须做到：
- 所有容器日志输出到 stdout/stderr（禁用文件日志），由 Docker daemon 统一收集
- 用 Loki + Promtail 替代 ELK：轻量、原生支持标签（
job=api, env=prod, instance=web-01），查日志时直接关联容器名和 trace ID - 关键服务加结构化日志（JSON 格式），字段包含
service、level、trace_id、span_id，便于过滤与追踪
资源限制要“带弹性余量”
设 --memory=512m 不等于容器只会用 512MB。Java 应用默认堆内存可能占满限制导致 OOM；Go 应用 GC 峰值也可能触发 kill。正确做法是：
- 先用
docker stats观察 7 天峰值使用量，再设 limit = 峰值 × 1.3～1.5 - 对 Java 容器显式指定
-Xmx384m（不超过 memory limit 的 75%） - 用
--memory-reservation设置软限制，避免突发流量被立刻 kill，而是触发内核回收
更新与回滚必须原子化
Watchtower 自动更新方便，但生产环境更需可控性：
- 镜像标签用语义化版本（
v1.2.3）或 Git SHA，禁用latest - 更新前执行健康检查（Watchtower 支持
--stop-timeout和自定义 health check 脚本） - 每次部署保留最近 2 个历史镜像，回滚只需
docker-compose pull & docker-compose up -d，无需重建 - 配合 CI/CD，在流水线中自动打标、推送到私有 Registry，并记录镜像 digest 与变更说明
清理策略要“有依据、可审计”
定期 docker system prune -a 是高危操作。安全做法是：
- 按标签清理：只删
dev-或test-开头的镜像（docker image prune -f --filter "label=env=dev"） - 按时间清理：删除 7 天前未被任何容器引用的镜像（
docker image prune -f --filter "before=2026-07-22T00:00:00"） - 卷清理前先确认：用
docker volume inspect xxx查挂载路径和用途，避免误删数据库卷
所有清理操作写入脚本，加上 echo "[DRY RUN]" 开关，默认只打印将要执行的动作。
