cgroup_memory_failures指标不存在，无法预警物理内存硬件故障；应监控memory.failcnt、memory.oom_control.under_oom、MCE日志、EDAC计数器及系统稳定性指标。
直接抓取 cgroup_memory_failures 无法预警物理内存硬件故障——这个指标根本不存在，也不是内核暴露的标准 cgroup 指标。
真正该关注的：memory.failcnt 与 memory.oom_control
Linux cgroup v1/v2 中与内存压力强相关的原生指标只有两个：
-
memory.failcnt：当容器尝试分配内存但因超出
memory.limit_in_bytes被拒绝的累计次数。它反映的是“配额超限”，不是硬件错误。 - memory.oom_control.oom_kill_disable 和 memory.oom_control.under_oom：前者控制是否启用 OOM Killer，后者为 1 表示当前正被 OOM Killer 处理中。它们只说明内核已触发内存回收逻辑，不涉及硬件层。
物理内存颗粒故障的可观测信号不在 cgroup 层
硬件级内存故障（如坏块、ECC校验失败、芯片老化）由内核底层捕获，路径是：
- /sys/firmware/acpi/tables/data/ 或 dmesg -T | grep -i "mce\|ecc\|memory.*error" —— MCE（Machine Check Exception）日志是第一手证据；
-
/var/log/kern.log 中持续出现
Hardware error from APEI、Corrected hardware error或Uncorrectable memory error； -
EDAC (Error Detection And Correction) 驱动导出的计数器，例如：
cat /sys/devices/system/edac/mc/mc*/csrow*/ch0_dimm0/ce_count（可纠正错误）cat /sys/devices/system/edac/mc/mc*/csrow*/ch0_dimm0/ue_count（不可纠正错误）。
联合监控落地建议
要实现对内存硬件风险的提前预警，需放弃从 cgroup 抓“假指标”的思路，转向三层协同采集：
-
内核日志层：用 filebeat 或 fluentd 实时收集
dmesg输出和kern.log，设置关键词告警规则（如 5 分钟内出现 ≥2 条Uncorrectable）； -
EDAC 硬件层：通过 Prometheus Node Exporter 的
node_edac_correctable_errors_total和node_edac_uncorrectable_errors_total指标拉取，配置突增检测（如rate(node_edac_correctable_errors_total[1h]) > 10）； -
系统稳定性层：结合
node_memory_MemAvailable_bytes的持续下降趋势 +node_vmstat_pgpgin/pgpgout异常飙升 + 容器container_memory_working_set_bytes波动紊乱，交叉验证是否存在隐性内存异常泄漏或硬件干扰。
硬件故障不会在 cgroup 内存统计里留下痕迹，但会在 EDAC 计数器、MCE 日志和系统行为一致性上暴露破绽。盯住这三个出口，比虚构一个不存在的指标更可靠。
