物理主机 ECC 错误巡检：从内核事件到告警验收

数据库进程意外退出，内核日志同时出现内存错误时，重启应用只能恢复进程，不能解释故障来源。ECC 能纠正部分内存错误，却不会自动完成事件留存、趋势判断和工单取证。物理主机上线验收应确认一条完整链路：硬件报告、内核接收、事件保存、监控识别、告警送达。

CloudSFP 的 AMD EPYC 7543P 物理主机采用 DDR4-3200 ECC，提供 128GB 与 256GB 两档。以下以 Debian 12 为例建立巡检流程，命令在宿主操作系统执行，不在来宾系统执行。不同内核与固件暴露的信息可能不同，缺少数据源必须单独记录，不能当作零错误。

一、先区分错误与监控缺口

可纠正错误通常标为 CE，表示相关错误已被纠正；不可纠正错误通常标为 UE，表示对应错误无法由该纠错机制修复。具体影响还取决于错误位置、内核处理方式和受影响进程，不能仅凭缩写推断业务数据一定完好。

CE 的判断重点是增量、重复位置及发生时的负载。一次孤立事件与同一位置持续出现的事件，应有不同处理优先级。UE 则需要优先保护数据，检查进程退出、系统异常和已有备份，停止增加相关负载。

“没有记录”只有在采集链已确认可用时才具有参考价值。EDAC 目录为空、采集服务停止和事件数据库不可读，都属于监控缺口，不是健康证明。

ECC 也不替代数据校验、存储冗余和备份。应用返回错误结果、文件损坏与内存错误之间，需要时间和业务证据关联，不能直接建立因果关系。

二、确认内核实际提供的数据源

先记录启动标识和内核版本，再检查内存控制器目录及内核事件。这些命令只读取现状，不加载驱动，也不修改硬件设置。

uname -r
cat /proc/sys/kernel/random/boot_id
ls -ld /sys/devices/system/edac/mc
find /sys/devices/system/edac/mc -maxdepth 2 -type f \
  \( -name ce_count -o -name ue_count -o -name mc_name \) \
  -print -exec cat {} \;
sudo journalctl -k -b --no-pager \
  --grep='EDAC|MCE|Hardware Error|memory error'

目录中的 mc_name 用于确认控制器名称，ce_count 和 ue_count 是对应控制器的累计计数。首次读到非零值时，先保存为基线，不把全部历史计数当成刚发生的告警。

目录不存在或没有控制器条目时，应保留命令输出，并检查内核日志中的驱动初始化信息。驱动支持、固件设置和平台报告路径都可能影响可见性，不建议通过反复加载未知模块试探生产机器。

内核日志中的 MCE 或 Hardware Error 也不一定代表内存故障；事件可能来自其他硬件单元。必须保留完整上下文，不能只抓一行包含“error”的文本就归类。

三、建立 rasdaemon 记录与计数基线

Debian 12 可使用发行版软件包安装 rasdaemon。变更前保存现有服务配置；安装后同时检查服务状态、启动参数和实际进程。

sudo apt-get update
sudo apt-get install rasdaemon
sudo systemctl enable --now rasdaemon
systemctl status rasdaemon --no-pager
systemctl cat rasdaemon
ps -C rasdaemon -o pid,args
sudo ras-mc-ctl --status
sudo ras-mc-ctl --summary
sudo ras-mc-ctl --errors

--status 只是检查的一部分，不是完整健康结论。还应查看服务日志是否存在事件订阅失败、权限错误或数据库写入问题。

sudo journalctl -u rasdaemon -b --no-pager

记录进程不等于记录落盘

检查启动参数是否启用了 -r 或 --record，并确认当前软件包具有数据库支持。服务运行但没有持久化记录时，重启采集进程可能造成证据断层。数据库位置应以实际软件包配置为准，不硬套其他发行版的路径。

每次采样至少保存机器编号、启动标识、采样时间、控制器名称及 CE、UE 计数。计数增量必须在同一启动标识和同一数据源下比较；系统重启、模块重载或计数回退时，重新建立基线，而不是算出负数后忽略。

rasdaemon 与 EDAC 的数据范围未必完全相同。比较时先核对事件类型、采集起点和控制器，不要求两套记录总数机械一致。

四、让告警表达风险而不是堆积消息

建议把监控分成三类：采集链失效、CE 新增、UE 新增。采集链失效包括服务停止、读数失败和数据库查询错误，应独立告警，不能用数值零覆盖异常。

CE 新增通知应携带本次增量、控制器与原始事件。若记录提供位置字段，可按位置聚合重复事件，但不设一个适用于所有机器的“安全次数”。事件速率、集中程度和业务症状应共同决定升级处理。

UE 新增应提升优先级，保存现场后检查业务完整性。不要以压力测试进一步验证故障，也不要为了清空计数先重启机器。

告警链验收可以使用离线样本：构造前后两份计数输入，分别验证零增量、CE 增量、UE 增量、读数失败和启动标识改变。测试消息明确标注演练，只进入监控解析器，不写入真实硬件事件库。

生产主机不通过错误注入验收通知。通知测试成功仅证明解析和投递可用；硬件事件是否能被内核接收，仍须依据驱动状态、事件源及实际记录单独确认。

五、保留能推进硬件调查的证据

出现重复错误后，先导出当前启动周期的内核日志、rasdaemon 服务日志和事件查询结果，再保存计数快照。取证目录限制访问权限，向工单附文件前检查是否包含地址、账户或业务敏感信息。

工单内容按以下顺序组织：

• 机器编号、系统与内核版本、启动标识。
• 首次发现时间及明确时区，错误是否持续新增。
• CE、UE 的原始事件和前后计数，不只附告警截图。
• 报告中的控制器及位置字段，缺失字段如实注明。
• 同期业务症状，以及已经执行的操作和结果。

事件中的 DIMM 标签或地址，不应自行换算成物理插槽编号；平台映射可能不同。硬件定位交由支持人员结合机器信息完成，租用方负责保护操作系统、业务数据和备份。

巡检的最终交付物不是一张“全绿”截图，而是可复核的基线、明确的数据源覆盖范围、经过演练的告警链和完整故障证据。内核更新或机器重新启动后，应重新确认这些条件，避免采集失效被误认为错误消失。

常见问题