Docker 容器监控与日志实践：cgroups 资源限制、Prometheus 与日志驱动

不设限制的后果：
  - 一个容器吃光所有 CPU → 影响其他容器与宿主机
  - 内存泄漏 → 触发 OOM，可能拖垮节点
  - 磁盘 IO 打满 → 整机卡顿

cgroups 让 Docker 能按容器隔离并限制资源：
  - CPU：--cpus（核数）、--cpu-shares（权重）
  - 内存：--memory、--memory-swap、--memory-reservation
  - IO：--device-read-bps、--device-write-bps

# 限制为 2 核、内存 1G、交换 512M
docker run \
  --cpus=2 \
  --memory=1g \
  --memory-swap=1.5g \
  --name api \
  myapp:1.0

# compose 中同样配置
# deploy.resources.limits.cpus / limits.memory

为什么合理设置很重要：
  - 给足资源但留上限 → 防"单容器拖垮全机"
  - 设置内存上限 → 内存泄漏有边界（重启优于蔓延）
  - 关键服务预留 → 用 cpu-shares 给重要容器更高权重

docker stats              # 所有运行容器
docker stats api db       # 指定容器
# 显示：CPU%、内存用量/上限、网络 IO、磁盘 IO、PID

# 带格式化输出方便脚本
docker stats --no-stream --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"

cAdvisor（Google 开源，现已并入 cadvisor）：
  作为容器运行，暴露 /metrics（Prometheus 格式）
  采集每个容器的 CPU/内存/网络/磁盘指标

部署（compose）：
  cAdvisor 容器挂载 /var/lib/docker 与 cgroups，暴露 8080
  → Prometheus 用 kubernetes_sd/file_sd/static_config 抓取
  → Grafana 用官方 cadvisor 仪表盘展示

# 运行 cAdvisor（简化版）
docker run -d \
  --name cadvisor \
  --privileged \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -v /:/rootfs:ro \
  -v /var/lib/docker/:/var/lib/docker:ro \
  -v /sys/fs/cgroup:/sys/fs/cgroup:ro \
  -p 8080:8080 \
  gcr.io/cadvisor/cadvisor:latest

Docker 的容器日志默认 json-file（存在节点磁盘）
  → docker logs 能看到，但：
    - 文件无限增长会撑爆磁盘
    - 多节点不便集中查看/检索

logging driver 把容器 stdout/stderr 转送到统一后端：
  - json-file（默认，本地）
  - syslog / journald（系统日志）
  - fluentd / fluent-bit（Fluent 生态）
  - gelf（Graylog）
  - loki（Grafana Loki）
  - awslogs / gcp / splunk 等云服务

# 全局配置（daemon.json）
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "50m",      # 单文件上限
    "max-file": "5"          # 保留轮转文件数
  }
}

# 或单容器指定
docker run --log-driver=json-file \
  --log-opt max-size=10m --log-opt max-file=3 myapp

日志轮转是必做项：
  不轮转 → 日志文件无上限增长 → 磁盘被日志写满
  设置 max-size + max-file 是防"日志撑爆磁盘"的第一道闸

Loki 方案（轻量，与 Grafana 一体）：
  promtail 或 docker 的 loki logging driver 收集
  → Loki 存储、Grafana 查询（LogQL）

Fluentd 方案（生态广）：
  docker 的 fluentd driver 把日志送到 fluentd 集群
  → 可再转 Elasticsearch/Kafka 等

生产建议：
  中小规模 → Loki（简单、便宜）
  已有 ELK/EFK → 直接接 fluentd/fluent-bit
  日志量大 → 采样 + 分级（错误全量、INFO 采样）

# Dockerfile 里定义健康检查
FROM myapp
HEALTHCHECK --interval=30s --timeout=5s --retries=3 \
  CMD curl -fsS http://localhost:8080/health || exit 1

# 或运行时/compose 指定
docker run --health-cmd="curl -fsS http://localhost/health" \
  --health-interval=30s --health-timeout=5s \
  --health-retries=3 myapp

# --restart 策略控制崩溃后行为
docker run --restart=unless-stopped myapp
#   no / always / on-failure[:N] / unless-stopped

# Swarm/K8s 层面：失败自动重建到期望副本数
# 本地 compose：restart: unless-stopped

健康检查 + 重启策略的组合：
  探活失败 → 标记 unhealthy → 编排/重启拉起
  单机 docker：on-failure 重启，配日志定位根因

告警维度（容器级）：
  - 内存使用率 > 90% 持续 5m
  - CPU 长时间打满
  - 容器频繁重启（restart 计数）
  - 日志增长异常 / 错误日志激增

容量规划：
  - 记录容器峰值资源 → 定合理 limits
  - 节点可用资源 vs 所有容器 requests 之和
  - 预留余量，避免"容器全挤一个节点"

工具：Prometheus 规则 + Alertmanager 告警到 IM/邮件

# Prometheus 告警示例：容器内存持续超限
- alert: ContainerMemoryHigh
  expr: (container_memory_usage_bytes / container_spec_memory_limit_bytes) > 0.9
  for: 5m
  annotations:
    summary: "容器内存使用率超过 90%"

□ 所有容器设 cpus/memory limits（防单容器拖垮）
□ 关键服务用 cpu-shares 保证权重
□ docker stats 只用于当场排障，长期用 cAdvisor+Prometheus
□ Grafana 建容器看板（CPU/内存/网络/磁盘）
□ 日志驱动选 Loki 或 fluentd，接集中后端
□ 配 max-size/max-file 日志轮转
□ HEALTHCHECK + restart 策略 + 告警
□ 记录峰值，做容量规划
□ Alertmanager 告警进 IM/邮件

Docker 可观测性 = cgroups 设边界 + cAdvisor 采指标 + 日志驱动集中收，
三者齐了，容器才算"看得清、防得住、查得了"。