bmc_health 主要用于 iBMC 自身系统健康状态的监控与管理

组件概述 ​

组件是什么、解决什么问题 ​

bmc_health（部署服务 bmc_core.service，D-Bus 总线名 bmc.kepler.bmc_health）是 iBMC 自身系统健康状态的监控与管理组件，负责监控 BMC 系统 CPU、内存、存储等资源的使用情况，并在资源异常时执行清理/告警/杀进程等动作，保障 BMC 自身长期稳定运行。同时对外提供 BMC 系统诊断数据（内存/存储统计）资源协作接口与系统健康事件查询 IPMI 命令。

职责边界：bmc_health 只关注 BMC 自身（管理平面） 的健康，不监控被管服务器（主机侧）的硬件状态——后者由 sensor_mgmt 等组件负责。bmc_health 通过订阅 bmc.kepler.Systems.Events/EventSummary 汇总系统健康事件计数供 IPMI 查询。

核心功能 ​

术语解释 ​

外部系统交互边界 ​

说明：bmc_health 订阅 Events/EventSummary 获取系统健康事件计数、订阅 NandFlash OverWrite 触发文件监控；监控数据源主要来自 /proc 与 shell 命令（df/free/top）。

功能简介 ​

bmc_health 功能主要涉及 iBMC 自身的系统健康状态监控，包括监控系统 CPU、内存使用情况等。当前支持的功能包括以下几个：

1. 监控 CPU 使用率，CPU 不足时记录日志
2. 监控内存使用情况，可用内存小于 400MB 时触发一次内存释放（删除大文件）
3. /tmp 目录被占满时进行清理（30s 检测周期）
4. 支持 coredump 信息收集

此外，bmc_health 还对外提供 BMC 系统诊断数据（内存/存储统计）资源协作接口、系统健康事件查询 IPMI 命令。

关键特性 ​

监控 CPU 使用率 ​

此功能利用了 Linux 系统的一项功能机制（init 进程）。主机系统开始运行之后，Linux 会准备软件运行的环境，并加载所有系统运行所需的程序，包括 BIOS 引导、kernel 加载、系统 init 程序等，其中 init 程序相当于 Linux 系统的第一个程序，其 pid 是 1。init 程序包括系统一些基础的启动项和配置的初始化，包括主机、网络、文件以及其他程序的启动等，这些动作都可以通过 init 的配置项来设置。

利用上述机制，实现 CPU 使用率监控功能可拆成两步走：

1. 一个持续运行不退出的监控 CPU 使用情况的脚本
2. Linux 系统起来的时候运行这个脚本

运行时通过 cpu_mem_metric.lua 周期读取 /proc/stat 两次 CPU jiffies 差值计算各模式（user/nice/system/idle）的 CPU 使用率，并记录 bmc.system.cpu.usage 指标（Gauge，属性 cpu.mode）。

内存使用情况监控与删除大文件 ​

承载此功能的脚本是 partition_usage_monitor.sh，在系统起来的时候通过 systemd 服务机制拉起。通过配置 etc/systemd/system/ 目录下的 partition_monitor.service、partition_monitor.timer，让 systemd 服务定期执行 partition_usage_monitor.sh，实现监控内存使用以及删除大文件的功能。可用内存小于 400MB 时触发一次内存释放。

/tmp 目录清理 ​

此功能核心部分由 C 语言实现，然后通过 Lua 调用。每 30s 检查一次 /tmp 目录空间占用情况（tmp_mem_intf.is_tmp_memory_full()），当占用率到达 100% 时，触发清理动作并记录一条维护日志 Available memory too small, clear tmp directory.（故障码 SVR-0015012）。

清理的方式比较简单：强删 /tmp 目录，再重新创建一个空的 /tmp 目录（并恢复 01777 权限）。

coredump 信息收集 ​

系统发生 coredump 时，获取 maps 信息并转储，只在 debug 包中支持。

使用率信息收集 ​

通过 get_usage_info 每 3 天收集一次磁盘（df -h）、内存（free）与 CPU 占用（top）信息到 /var/log/bmc_health.log，用于日常巡检。

文件监控（NandFlash 写超限） ​

订阅 bmc.kepler.Managers.NandFlash 的 OverWrite 属性变化，当 OverWrite 置 1 时触发 1 小时采集任务：遍历 /proc 获取所有进程 write_bytes，排序取 top10，采集其打开的文件句柄（fd）信息，写入 /var/log/file_monitor.log（6 轮 × 10 分钟间隔，共 7 次采集；日志转储最多保留 3 份 .gz 备份）。

对外接口 ​

资源协作接口 ​

ManagerDiagnosticData 管理组件诊断数据 ​

• Path: /bmc/kepler/Managers/:ManagerId/ManagerDiagnosticData

• Interface: bmc.kepler.Managers.ManagerDiagnosticData.MemoryStatistics / bmc.kepler.Managers.ManagerDiagnosticData.StorageStatistics

MemoryStatistics 属性：

StorageStatistics 属性：

说明：属性为惰性更新，属性被读取（property_read）时通过 diag_status.lua 读取 /proc/meminfo 与 df -kP 实时刷新后再返回。

首发版本： bmc_health 1.130.10（bmcsdk 25.x）

应用场景与限制条件：

• 典型场景：北向（Redfish）或上层组件查询 BMC 自身内存/存储统计，用于资源水位监控与容量规划。
• 限制条件：
  • 属性为惰性更新，读取时才刷新，不产生周期性属性变化信号（emitsChangedSignal=false）；
  • 内存统计来自 /proc/meminfo 的 MemTotal/MemAvailable/MemFree/Buffers/Cached/Shmem，UsedBytes 为 total - free - buffers - cached；
  • 存储统计 FreeStorageSpaceKiB 仅汇总 /dev/mmcblk0p1、p9、p7、gp3 四个分区 df -kP 的 Available 值；
  • df 命令执行失败或 /proc/meminfo 读取失败时对应属性返回 0。

调试示例：

# 1) 查询内存统计属性（读取时实时刷新）
busctl --user get-property bmc.kepler.bmc_health \
    /bmc/kepler/Managers/1/ManagerDiagnosticData \
    bmc.kepler.Managers.ManagerDiagnosticData.MemoryStatistics AvailableBytes
# 相应: t 716428032

# 2) 查询存储统计属性（四个分区 Available 之和，单位 KiB）
busctl --user get-property bmc.kepler.bmc_health \
    /bmc/kepler/Managers/1/ManagerDiagnosticData \
    bmc.kepler.Managers.ManagerDiagnosticData.StorageStatistics FreeStorageSpaceKiB
# 相应: t 1465766

# 3) 遍历查询全部属性
busctl --user introspect bmc.kepler.bmc_health \
    /bmc/kepler/Managers/1/ManagerDiagnosticData

异常与触发条件：

IPMI接口 ​

• 具体参数参考本组件配置文件 ipmi.json

查询系统健康事件 GetSystemHealth ​

输入：

• MfgId（uint32）：厂商 ID，3 字节，按定制规则 Manufacturer 填充
• SubCmd（uint8）：子命令，固定 0x08
• FruId（string）：FRU 标识，长度需小于等于 1（非法时返回 IPMIRequestLengthInvalid）

输出：

• CompletionCode（uint8）：完成码
• MfgId（uint32）：厂商 ID
• MinorEventCount（uint8）：一般事件计数
• MajorEventCount（uint8）：严重事件计数
• CriticalEventCount（uint8）：紧急事件计数

计数来源：多 Host 场景且请求通道为 HOST 时，取该 Host 的 EventSummary 计数；否则取 bmc.kepler.Systems.Events 对象的 MajorCount/MinorCount/CriticalCount。

首发版本： bmc_health 1.130.10（bmcsdk 25.x）

应用场景与限制条件：

• 典型场景：BMC 内部（如升级、巡检）查询系统健康事件统计；DFT（装备测试）流程通过 DftGetSystemHealth 查询。
• 限制条件：
  • FruId 长度需小于等于 1，非法时返回 IPMIRequestLengthInvalid；
  • SubCmd 固定为 0x08（GetSystemHealth）或 0x2a（DftGetSystemHealth）；
  • 多 Host 场景仅当请求通道为 HOST 时才按 Host 维度返回 EventSummary 计数，其他通道返回全局 Events 计数。

调试示例：

# 1) 通过 ipmitool raw 查询系统健康事件（0x30 0x91，MfgId 0x07db，SubCmd 0x08）
#    请求字节：0xdb 0x07 0x00（MfgId 小端） 0x08（SubCmd） 0x00（FruId）
ipmitool raw 0x30 0x91 0xdb 0x07 0x00 0x08 0x00
# 相应: 00 db 07 00 01 02 00   （CC=0 成功；随后 Minor/Major/Critical 计数）

# 2) 查询 DFT 版本系统健康事件（0x30 0x90，SubCmd 0x2a）
ipmitool raw 0x30 0x90 0xdb 0x07 0x00 0x2a 0x00
# 相应: 00 db 07 00 00 01 00

# 3) 通过 D-Bus 查看系统健康事件计数（单 Host 场景取 bmc.kepler.Systems.Events）
busctl --user get-property bmc.kepler.event /bmc/kepler/Systems/1/Events \
    bmc.kepler.Systems.Events MajorCount

异常与触发条件：

查询系统健康事件（DFT） DftGetSystemHealth ​

输入：

• MfgId（uint32）：厂商 ID，3 字节，按定制规则 Manufacturer 填充
• SubCmd（uint8）：子命令，固定 0x2a
• FruId（string）：FRU 标识

输出：

• CompletionCode（uint8）：完成码
• MfgId（uint32）：厂商 ID
• MinorEventCount（uint8）：一般事件计数
• MajorEventCount（uint8）：严重事件计数
• CriticalEventCount（uint8）：紧急事件计数

计数来源与 GetSystemHealth 一致：多 Host + HOST 通道取 EventSummary，其余取 bmc.kepler.Systems.Events。

首发版本： bmc_health 1.130.10（bmcsdk 25.x）

应用场景与限制条件： 由 DFT（装备测试）流程调用，SubCmd 固定 0x2a；其余限制同 GetSystemHealth。

调试示例：

ipmitool raw 0x30 0x90 0xdb 0x07 0x00 0x2a 0x00
# 相应: 00 db 07 00 00 00 00

异常与触发条件： 同 GetSystemHealth（FruId 超长返回 IPMIRequestLengthInvalid）。

配置介绍 ​

服务依赖与订阅 ​

bmc_health（部署服务 bmc_core.service）启动时订阅以下外部接口：

监控任务 ​

运行指标 ​

bmc_health 通过 telemetry metrics 注册以下 Gauge 指标（meter 名称 bmc_health）：

组件扩展案例 ​

扩展能力概述 ​

bmc_health 的扩展能力体现在 监控与指标的可配置扩展：通过投放 shell 脚本/配置文件即可扩展监控对象，无需改动组件 Lua 代码；同时通过 telemetry metrics 对外暴露可观测指标，供监控平台采集。

扩展点说明 ​

二次开发指导 ​

步骤一：新增受监控进程 ​

编辑 /opt/bmc/conf/process_config.ini，每行一个进程，格式为 进程名 内存上限(KB)：

bmc_health 51200
sensor 40960

process_memory_monitor.sh 每小时读取该配置巡检：进程总内存（top 采样 6 次取平均）超过上限时，向 /var/log/app.log、/var/log/maintenance.log 记录告警并 systemctl restart 该进程。

步骤二：扩展 cpumem 采集的进程列表 ​

编辑 /opt/bmc/script/cpumem_usage_info_dump.sh 中的 applications 变量，增加要采集的进程名：

applications="framework bmc_core security alarm hardware om energy ras remote_service interface your_app"

修改后脚本下一次周期执行（由 debug_performance.lua 按 starter 配置周期拉起）即生效，采样结果写入 /var/log/cpumem_usage_info_dump.csv。

步骤三：验证 ​

# 1) 确认监控服务已拉起
systemctl status process_memory_monitor.service memory_monitor.service partition_monitor.service

# 2) 确认指标已注册（telemetry 采集）
# 3) 制造 /tmp 占满（如 dd 大文件）验证 30s 后触发清理
busctl --user get-property bmc.kepler.bmc_health \
    /bmc/kepler/Managers/1/ManagerDiagnosticData \
    bmc.kepler.Managers.ManagerDiagnosticData.MemoryStatistics AvailableBytes

注意事项 ​

1. process_config.ini 中进程名须与 systemd 服务名一致，否则 systemctl restart 会失败；
2. applications 变量增删进程后，脚本会自动检测表头变化并转储 csv（最多保留 3 份 .gz）；
3. 监控脚本写日志受写保护目录 /dev/shm/.nowritetoflash 控制，开启写保护时不落盘；
4. 修改脚本/配置后建议重启对应 systemd 服务使其立即生效。

问题定界指南 ​

典型问题定界 ​

关键日志与故障码 ​

调试方法 ​

# 查看 bmc_health 服务实时日志
journalctl -u bmc_core.service -f

# 过滤监控相关日志
journalctl -u bmc_core.service | grep -iE "tmp|memory|cpu|OverWrite|file_monitor|diag"

# 查看监控脚本日志
cat /var/log/bmc_health.log
cat /var/log/file_monitor.log
cat /var/log/app.log
cat /var/log/maintenance.log

复现方法：

• /tmp 清理：dd if=/dev/zero of=/tmp/big bs=1M count=300 填满 /tmp，30s 内观察日志出现 Available memory too small... 且 /tmp 被重建（01777）。
• 文件监控：确认 NandFlash OverWrite 属性置 1 后，观察 1 小时内 7 次采集写入 file_monitor.log。
• 诊断数据：busctl 读 ManagerDiagnosticData 属性，观察日志中 diag 相关刷新动作。

日志说明 ​

一键日志收集 ​

一键日志收集（AppDump/日志导出）涉及 bmc_health 的日志文件如下：

关键日志信息 ​

FAQ ​

Q1：/tmp 目录突然被清空、文件丢失？ ​

一句话答案： /tmp 占用率达到 100% 时 bmc_health 会强删并重建 /tmp。

根因： monitor_tmp_memory 每 30s 调用 tmp_mem_intf.is_tmp_memory_full()，占用率满时执行 utils.remove_file('/tmp/') 并重建（01777），同时记录 SVR-0015012。

解决方案： ① 清理 /tmp 下大文件或临时文件；② 排查写入 /tmp 的异常进程；③ 避免在 /tmp 存放需持久化的数据。

规避方案： 暂无配置开关；可通过写保护目录 /dev/shm/.nowritetoflash 限制日志落盘，但 /tmp 清理动作不随之关闭。

适用版本： 全版本。

Q2：GetSystemHealth 查询的系统健康事件计数恒为 0？ ​

一句话答案： bmc_health 未订阅到 bmc.kepler.Systems.Events/EventSummary 对象。

根因： 计数来源为事件组件对象；事件组件未就绪、订阅未建立或对象不在位时计数为 0。

解决方案： ① 确认事件组件（event）服务正常并已创建 Events 对象；② 重启 bmc_health 重建订阅；③ busctl --user tree bmc.kepler.event | grep Events 确认对象存在。

适用版本： bmc_health 1.130.10。

Q3：某 BMC 进程被自动重启，怀疑是 bmc_health 干的？ ​

一句话答案： 是的，进程内存超限时 process_memory_monitor.sh 会 systemctl restart 该进程。

根因： process_memory_monitor.sh 按 /opt/bmc/conf/process_config.ini 配置巡检，进程内存（top 采样平均）超上限即重启。

解决方案： ① 查看 /var/log/app.log、/var/log/maintenance.log 的 memory_monitor ERROR/WARN 确认触发；② 定位该进程内存增长原因；③ 必要时调整 process_config.ini 上限。

适用版本： 全版本。

Q4：NandFlash 写超限，file_monitor.log 却没有采集内容？ ​

一句话答案： OverWrite 属性未置 1、订阅未建立或采集失败。

根因： 采集由 NandFlash OverWrite 属性变化（值为 1）触发；OnNandFlashPropertiesChanged 订阅失败、对象不在位或 collecting 标志防重入都会导致不采集。

解决方案： ① 确认 bmc.kepler.Managers.NandFlash 对象在位且 OverWrite=1；② 重启 bmc_health 重建订阅；③ 查看日志 OverWrite asserted / collection failed。

适用版本： bmc_health 1.130.10。

Q5：ManagerDiagnosticData 属性查询恒为 0？ ​

一句话答案： /proc/meminfo 或 df 命令执行失败，属性返回 0。

根因： 属性为惰性更新，读取时执行 cpumem_metrics.read_meminfo() 与 vos.popen_s('df -kP')，任一步失败对应属性置 0。

解决方案： ① 确认系统可正常读 /proc/meminfo、执行 df；② 查看日志 failed to read meminfo / failed to update storage；③ 确认 bmc_health 服务正常。

适用版本： bmc_health 1.130.10。