cAdvisor在短生命周期容器场景下因未及时清理已退出容器监控元数据，导致内存堆积“幽灵指标”并引发OOM；需通过精简指标维度、启用cgroup v2、配合Prometheus过期策略三方面协同治理。
这个问题本质是 cAdvisor 在短生命周期容器场景下，因未及时清理已退出容器的监控元数据，导致内存中堆积大量“幽灵指标”，进而引发内存持续增长甚至 OOM。核心不在僵尸进程本身，而在 cAdvisor 的指标生命周期管理与容器实际生命周期不同步。
理解污染根源：cAdvisor 的指标缓存机制
cAdvisor 默认会为每个观察到的容器（包括已退出的）保留一段时间的指标快照，用于计算速率、趋势和历史对比。当容器秒级启停（如 K8s HPA 触发的高频扩缩容），cAdvisor 会不断新建监控对象，但旧对象不会立即释放——尤其在 cgroup v1 环境或未启用自动清理策略时，这些“历史容器”的内存统计（如 memory.usage_in_bytes、memory.max_usage_in_bytes）仍驻留内存，形成时序数据污染。
关键配置项：关闭冗余历史保留
启动 cAdvisor 容器时，显式禁用非必要历史缓存：
- 添加参数 --housekeeping_interval=10s：缩短资源扫描周期，加快状态同步
- 设置 --max_housekeeping_interval=30s：防止扫描间隔被动态拉长
- 强制启用清理：加上 --disable_metrics=percpu,process,disk,accelerator（只保留 cpu/memory/network 基础指标）
- 最关键：使用 --global_housekeeping_interval=20s 并配合 --event_storage_age_limit=2m 和 --event_storage_event_limit=default=0，限制事件存储生命周期
升级到 cgroup v2 + 启用容器元数据过滤
cgroup v2 提供更精确的进程归属识别，能显著降低“已退出容器残留指标”的误判率：
- 确保宿主机启用 cgroup v2（Linux 5.8+ 默认，检查 /proc/sys/fs/cgroup/unified_cgroup_hierarchy == 1）
- 启动 cAdvisor 时挂载 /sys/fs/cgroup:/sys/fs/cgroup:ro（而非旧式 /cgroup）
- 通过环境变量 CADVISOR_DISABLE_CONTAINER_HISTORY=true（v0.48+ 支持）跳过对已终止容器的状态重建
Prometheus 侧协同治理：从源头截断污染指标
即使 cAdvisor 发出了“僵尸指标”，也可在 Prometheus 抓取层过滤掉：
- 在 scrape config 中添加 metric_relabel_configs，丢弃 container_state!="running" 且 uptime_seconds < 60 的指标
- 用 PromQL 聚合时显式排除：container_memory_usage_bytes{container!=""} unless on(container) container_last_seen{container!="",container_state="running"}
- 设置 Prometheus staleness_delta 为 90s（默认 5m），让短命容器指标更快标记为过期并被回收
不复杂但容易忽略：污染不是由 cAdvisor “做错”引起，而是它默认行为与弹性场景不匹配。调整这三处——精简指标维度、绑定 cgroup v2 生命周期、配合 Prometheus 过期策略——就能让高频扩缩容下的内存占用回归稳定基线。
