问题描述
注入内存错误超过CE阈值后，maintenance.log下没有相应的overflow日志记录，但是fdm.log下依然会记录CE次数和overflow。经分析后得知可能是BMC侧做了主动注错限流机制，导致maintenance.log下没有记录对应的日志信息。
请问这个主动限流的策略是怎样的？触发后如何操作可以解除限流机制呢？
相关日志如log.tar.gz
log.tar.gz (8.9 MB)
答案内容由AI生成，仅供参考：
总结
| 项目 | 说明 |
|---|---|
 为何 maintenance.log 没有记录 Overflow |
最可能原因是 MemFaultIsolationEnabled 未启用或日志流控/容量满导致丢弃 |
 是否存在主动限流机制 |
是。BMC 存在日志速率控制、事件聚合和错误风暴抑制机制 |
 如何解除限流 |
启用隔离功能、清除日志、调整注入节奏、使用调试接口 |
 推荐操作 |
启用 MemFaultIsolationEnabled，并通过 Redfish 下载全量日志以确保诊断完整性 |
建议：若用于测试验证，请在注入前确保
maintenance.log可写且空间充足，并开启所有诊断开关以保障日志完整。
点击此处查看详细分析解答
关于内存CE错误注入后 maintenance.log 未记录 Overflow 日志的问题分析
问题描述
在注入内存可纠正错误（Correctable ECC Error, CE）超过阈值后，系统未在 /var/log/maintenance.log 文件中记录对应的 Overflow 相关日志，但 fdm.log 中仍能观测到 CE 错误次数统计和 Overflow 状态。经初步排查，怀疑是 BMC 侧存在主动的日志注错限流机制，导致关键事件未能写入维护日志。
根本原因分析
根据当前知识库内容，可以确认以下几点关键事实：
1. maintenance.log 是系统维护事件的主要记录日志
- 该日志路径为：
/var/log/maintenance.log - 通过 Lua 接口
log:maintenance(level, fault_code, fmt, ...)进行写入。 - 主要用于记录系统运行过程中的维护性事件，如内存隔离、错误统计超限等。
来源：搜索结果【Lua开发框架】中明确指出：“维护日志位置：/var/log/maintenance.log。该日志用于记录系统运行过程中的维护事件。”
2. CE 超阈值与 Overflow 的定义清晰
| 指标 | 描述 | 来源 |
|---|---|---|
CorrectableECCError |
可纠正 ECC 错误次数超过预设门限（Threshold），触发告警 | KG & 搜索文档【资源协作接口】 |
CorrectableECCOverflow |
可纠正 ECC 错误漏斗溢出（即缓冲区溢出），表示系统已无法继续跟踪高频率错误 | KG & 搜索文档【资源协作接口】 |
- 在资源协作接口
bmc.kepler.Systems.FDMDomain.MemoryRAS中：CorrectableECCError: 内存发生多次 CE 错误导致超门限，1 表示超限。CorrectableECCOverflow: 内存发生 CE 漏斗溢出，非零表示溢出。
3. CE Logging Limit 触发 Memory Isolation 是正常行为
- 多次注入 CE 错误达到设定的
Correctable ECC Logging Limit（例如设为 3）后，系统应上报 SEL（System Event Log）事件"Correctable ECC logging limit reached"。 - 此事件会触发 SPPR（Sub-Page Page Retirement）或 ACLS 等内存隔离机制，并通过 BMC 记录到日志中。
示例日志记录（来自 DC 文档 #1）：
3,2025-11-07 10:21:00,P0_C1_D0_Status,Minor,Memory,Asserted,Correctable ECC logging limit reached
2,2025-11-07 10:20:41,P0_C1_D0_Status,Minor,Memory,Asserted,Spare
对应动作：
fault_diagnosis NOTICE: fpc_process: need SPPR
fpc_process: send isolation[1] info to imu success!!!
4. 影响 maintenance.log 是否记录的关键配置：MemFaultIsolationEnabled
- 核心发现来自文档 #2：
“经排查，
MemFaultIsolationEnabled这个属性值需要配置为true才可以” —— Fangzq
- 如果此标志未启用，则即使发生了 CE Overflow 或 Logging Limit Reached，BMC 不会记录 ACLS 相关信息到
maintenance.log。 - 因此，若未看到日志输出，首要检查该项是否开启。
BMC 主动限流机制分析（针对注错日志）
目前尚无直接说明 “注错限流” 的机制，但从相关设计中可推断存在以下几种可能影响日志写入的保护策略：
1. 日志流控与速率限制（Rate Limiting）
- BMC 系统为防止日志泛洪（log spamming），通常会对高频事件进行去重或限流。
- 如
LogAnalysis模块支持趋势识别和早期预警，说明系统具备日志聚合能力，低级别重复日志可能被抑制。 - 特别当出现“错误风暴”（Error Storm）时，系统优先处理故障响应，而非全量记录。
支持证据：
ErrorStormCount字段用于统计 CE/UCE 高频爆发事件。CorrectableECCStormBurstCount专门记录超级 CE 风暴事件。- 存在
CorrectableECCOverfrequencyCount记录错误频次超标次数。
2. 维护日志容量管理机制
- BMC 日志系统可能存在容量限制。
- 当日志满后，默认策略为“停止记录”而非“覆盖”，需手动清除才能恢复。
来源：文档 #5 和 #7 反映的问题：
“BMC传感器日志容量满后没有覆盖（满了之后不再记录除非先clear log）”
解决建议：
# 清除 SEL 日志（谨慎操作）
ipmcset -t maint -d clearlog
3. 内存错误处理优先级机制
- 系统对不同类型错误设有优先级：
- UCE（不可纠正错误） > CE Overflow > CE 超门限 > 单次 CE
- 在大量注入 CE 时，系统可能将多个 CE 聚合成一个事件处理，仅在首次或最后一次记录一次
maintenance.log事件。 - 此为一种事件聚合优化机制，避免日志膨胀。
如何解除或规避“限流”机制？
| 操作 | 方法 | 目的 |
|---|---|---|
| 1. 启用内存故障隔离功能 | 确保 MemFaultIsolationEnabled = true |
允许 BMC 上报并记录 ACLS/Overflow 事件 |
| 2. 修改 CE 阈值和漏斗时间 | BIOS 设置：Funnel Time 和 Correct Error Threshold |
控制 CE 计数窗口，避免漏斗过早溢出 |
| 3. 手动清除日志缓冲区 | 使用命令 ipmcset -t maint -d clearlog 或通过 Redfish API 清空日志 |
释放日志空间，恢复记录能力 |
| 4. 启用调试模式记录 | 使用 log:info_easy() 或 log:notice_easy() 强制输出调试信息 |
绕过部分流控策略 |
| 5. 下载完整日志包 | 通过 Redfish 接口下载全部日志：POST /redfish/v1/Managers/ManagerId/LogServices/Oem/Chinatelecom/DownloadAllLog |
获取包括 fdm.log、sel.log 在内的完整诊断数据 |
Redfish API 支持路径：
Redfish V1 Managers ManagerId LogServices Actions Oem Chinatelecom DownloadAllLog
建议排查步骤
-
确认
MemFaultIsolationEnabled是否开启- 检查 BMC 系统策略配置。
- 若关闭，请联系 BIOS/FW 团队启用该功能。
-
查看
CorrectableECCOverflow是否置位# 查询 MemoryRAS 属性 get_dbus_property bmc.kepler.Systems.FDMDomain.MemoryRAS CorrectableECCOverflow- 如果值 ≠ 0，说明已发生溢出。
-
检查
maintenance.log是否被流控或写满- 查看日志文件大小是否已达上限。
- 检查是否有类似
(Log full)或drop log的提示。
-
对比
fdm.log与maintenance.log时间戳- 确认
fdm.log是否先于maintenance.log更新。 - 判断是否因延迟或丢弃导致未记录。
- 确认
-
使用 Redfish 工具一键导出所有日志
- 访问 URL：
https://<BMC_IP>/redfish/v1/Managers/ManagerId/LogServices/Oem/Chinatelecom/DownloadAllLog - 下载完整日志包进行离线分析。
- 访问 URL：
总结
| 项目 | 说明 |
|---|---|
为何 maintenance.log 没有记录 Overflow |
最可能原因是 MemFaultIsolationEnabled 未启用或日志流控/容量满导致丢弃 |
| 是否存在主动限流机制 |
是。BMC 存在日志速率控制、事件聚合和错误风暴抑制机制 |
| 如何解除限流 |
启用隔离功能、清除日志、调整注入节奏、使用调试接口 |
| 推荐操作 |
启用 MemFaultIsolationEnabled，并通过 Redfish 下载全量日志以确保诊断完整性 |
maintenance.log可写且空间充足，并开启所有诊断开关以保障日志完整。
触发维护日志限流后，maintenance.log日志对应会有关键词“logs start suppressing”，例如这里CE overflow场景即会打印：
2026-01-26 22:44:05 INFO : SVR-0000000,CpuBoard1 DIMM000 CE overflow logs and CE Bucket logs start suppressing
CE overflow限流策略：相同FRU在2小时内触发相同日志次数=5后，触发日志限流
解除限流方法：
1.构建rw版本后，通过资源树debug方法可以查看和设置限流状态
mdbctl lsobj FDMDomain
查询限流功能开关状态：mdbctl call FDMDomain_1_010101 bmc.kepler.Debug.Systems.FDMDomain GetConfigurations 0 "GetMaintenanceLogLimitingEnabled"
限流开关：treu：打开，false：关闭
设置限流开关：mdbctl call FDMDomain_1_010101 bmc.kepler.Debug.Systems.FDMDomain SetConfigurations 0 "SetMaintenanceLogLimitingEnabled" 1
开关：1：开启，0：关闭
备注：执行0关闭场景，才会关闭限流状态
2.通过重启BMC可重新计时计数
- 测试逻辑：目前以了解限流策略，在限流开启时验证符合设计逻辑，重启BMC后重置流量计数，功能均正常。
- 出现问题：使用设置限流开关命令：mdbctl call FDMDomain_1_010101 bmc.kepler.Debug.Systems.FDMDomain SetConfigurations 0 把限流关闭，不重启bmc测试，实际限流状态依然存在。重启bmc后查询限流开关被重置为开启状态。
澄清一下：
mdbctl call FDMDomain_1_010101 bmc.kepler.Debug.Systems.FDMDomain GetConfigurations 0 “GetMaintenanceLogLimitingEnabled”
该调试接口，获取的是限流功能是否使能，不是限流状态，限流使能状态本身不做持久化，所以重启BMC后默认状态依然为true
mdbctl call FDMDomain_1_010101 bmc.kepler.Debug.Systems.FDMDomain SetConfigurations 0 “SetMaintenanceLogLimitingEnabled” 0
该调试接口，0设置限流使能为关闭，执行关闭后同步会清空所有部件限流状态
我们执行成功mdbctl call FDMDomain_1_010101 bmc.kepler.Debug.Systems.FDMDomain SetConfigurations 0 “SetMaintenanceLogLimitingEnabled” 0这个命令，然后再去测试内存注入错误，在注入第六次的时候，依然是有限流提示的，这是正常现象吗？
通过该命令可修改app.log日志级别
busctl --user call bmc.kepler.fault_diagnosis /bmc/kepler/fault_diagnosis/MicroComponent bmc.kepler.MicroComponent.Debug SetDlogLevel a{ss}sy 0 debug 2
麻烦修改日志级别后，提供下复现的一键收集日志