资源限制与监控告警必须联动：cgroup设硬限制，cAdvisor采集指标，Prometheus按占比告警（如内存>85%），Alertmanager带上下文通知，再对接自动化响应形成闭环。
资源限制和监控告警必须联动，否则限制只是“纸面配额”，超限了也无人知晓。关键在于：限制定义容器的“安全边界”，监控确认是否越界，告警推动人工干预或自动处置。
用 cgroup 限制资源，同时让指标可采集
Docker 启动时通过 --memory、--cpus 等参数设置硬限制，底层实际写入 cgroup 文件（如 /sys/fs/cgroup/memory/xxx/memory.limit_in_bytes）。cAdvisor 能自动读取这些值，并暴露为 Prometheus 可用指标：
-
container_spec_memory_limit_bytes{container="nginx"}—— 容器内存上限 -
container_memory_usage_bytes{container="nginx"}—— 当前已用内存 -
container_cpu_usage_seconds_total{container="nginx"}—— CPU 使用累计值
只要容器启动时加了资源限制，cAdvisor 就能拿到“分母”，监控才有“百分比”可算。
在 Prometheus 中写带上下文的告警规则
不能只看绝对值，要结合限制值动态计算使用率。例如内存超限告警应基于占比而非固定字节数：
- 正确写法（推荐）：
container_memory_usage_bytes / container_spec_memory_limit_bytes > 0.85
—— 自动适配不同容器的内存 limit，85% 即触发 - 错误写法：
container_memory_usage_bytes > 4000000000
—— 对 2G 限制的容器永远不触发，对 8G 的又太早触发
同理，CPU 使用率可用 rate(container_cpu_usage_seconds_total[2m]) / (1 * 0.5) 计算（假设限制为 0.5 核），再与阈值比较。
告警触发后不只是发消息，还要带定位信息
Alertmanager 接收到告警后，靠 labels 和 annotations 实现精准通知。一个实用的告警配置示例：
-
labels：添加
severity: critical、service: user-api、host: prod-node-3 -
annotations：写明可操作信息，例如：
summary: "Memory usage > 90% on {{ $labels.container }}"description: "Usage: {{ $value | humanize }} / {{ $labels.container_spec_memory_limit_bytes | humanize }} ({{ $value / $labels.container_spec_memory_limit_bytes * 100 | humanizePercentage }})"
这样 Slack 或邮件里会直接显示 “user-api 容器当前用了 1.8GiB / 2GiB（90%）”，运维人员无需再查指标就能判断是否需扩容或排查内存泄漏。
配合自动响应动作，形成闭环
告警本身是被动通知，但可对接自动化脚本实现主动干预：
- 收到连续 3 次
HighContainerMemoryUsage告警 → 调用 Docker API 执行docker exec -it xxx jstack抓 Java 线程快照 - 某容器 CPU 长期 > 95% 且 limit 已设满 → 自动触发
docker update --cpus=1.0 xxx临时扩容（需提前授权） - OOM Killer 日志被采集（通过 journalctl 或日志系统）→ 触发告警并关联最近的
container_memory_usage_bytes曲线，确认是否因限制过低导致
这类动作不替代人工分析，但能把“发现异常”到“开始调查”的时间从分钟级压缩到秒级。
