BMC 无法正常显示内存占用率信息

交流互助区
2

答案内容由AI生成，仅供参考：

关于 openUBMC 平台内存占用率信息无法正常显示的问题分析

根据您提供的详细信息，以下是针对 openUBMC 25.09 SDK 开发环境下，BMC Web 首页内存占用率概率性不显示问题的系统性分析与解答。

:magnifying_glass_tilted_left: 问题现象总结

  • 在 openUBMC 25.09 SDK 开发环境中，BMC Web 首页的内存占用率信息概率性不显示，表现为“–”。
  • 系统已检测到完整硬件信息（内存总量 128GB，8 条在位），但监控数据显示“当前值 --”。
  • 页面提示：“您必须先在服务器OS侧安装BMA 2.0，并完全启动后，方可查看内存占用率信息”，表明依赖带内（in-band）数据上报。
  • 日志分析显示：
    • host_agent 能够正确获取 MemUsage、TotalSystemMemoryGiB 等指标。
    • compute 组件中的 BandwidthPercent 值为 255，表示无效或未更新状态。

:red_question_mark:疑问一：host_agent 已能获取 MemUsage 等属性，是否说明带内信息已正常传递至 BMC？

:white_check_mark: 是的，这表明带内信息已经成功传递到 BMC 的 host_agent 层。

依据如下：

  1. AppDump/host_agent/mdb_info.log 中存在有效数据：

    .MemUsage          value: 3.43
.TotalSystemMemoryGiB  value: 126.22
.UsedSystemMemoryGiB   value: 4.33

    表明：

    • BMA（Baseboard Management Agent）已在主机 OS 侧正常运行，并通过带内通道（如 IPMI、SMBIOS 或 Redfish 插件）向 host_agent 上报了内存使用数据。
    • host_agent 成功接收并存储了这些数据至 D-Bus 或 MDB（Memory Database）系统。

  2. host_agent 的作用定位：

    • 它是运行在 BMC 上、负责与 Host OS 通信的代理模块。
    • 主要职责包括：接收来自 Host 的传感器数据（CPU、内存、磁盘占用率等）、固件版本、系统事件等。

:pushpin: 结论：带内链路正常，Host → host_agent 的数据传输已完成。

:red_question_mark:疑问二：为何 host_agent 已有数据，还需 compute 处理？计算流程是什么？

虽然 host_agent 获取了原始数据，但 Web UI 显示的数据是由 compute 组件提供。两者职责不同，需经过中间处理流程。

:white_check_mark: 数据流转路径详解（从 Host 到 Web UI）

graph LR
    A[Host OS + BMA 2.0] -->|IPMI/SMBIOS/Redfish| B(host_agent)
    B --> C[MDB / D-Bus 总线]
    C --> D{compute 组件}
    D --> E[bmc.kepler.Systems.Memory.MemoryMetrics]
    E --> F[Web UI / Redfish API]

各环节职责说明：

模块 职责
BMA 2.0 (Host侧) 收集 OS 层内存使用率（如 /proc/meminfo），封装为 IPMI OEM 命令或 Redfish 扩展接口，发送至 BMC。
host_agent (BMC侧) 接收 BMA 上报的数据，解析后写入 MDB（内存数据库）或发布到 D-Bus 总线上供其他服务订阅。
MDB / D-Bus 作为组件间通信的中枢，实现数据共享与事件通知。
compute 组件 是 BMC 的核心业务逻辑组件之一，负责聚合传感器数据，管理 bmc.kepler.Systems.* 资源树，将原始内存数据转化为 MemoryMetrics 指标。
MemoryMetrics 类 提供标准化接口如 BandwidthPercent, TotalSystemMemoryGiB 给 Web UI 和 Redfish 使用。

:counterclockwise_arrows_button: BandwidthPercent 的计算逻辑

尽管命名为“带宽”，但在内存上下文中，BandwidthPercent 实际上表示的是内存占用率百分比（历史命名兼容性原因）。

其值由 compute 从以下数据推导得出：

memory_usage_percent = (UsedSystemMemoryGiB / TotalSystemMemoryGiB) * 100

然后：

  • 若计算成功 → 写入 BandwidthPercent = int(memory_usage_percent)
  • 若数据缺失或异常 → 保留默认值 255（表示无效）

:magnifying_glass_tilted_right: 问题定位：为什么 compute 中 BandwidthPercent = 255？

您在 AppDump/compute/mdb_info.log 中观察到：

.BandwidthPercent       value: 255
.TotalSystemMemoryGiB   value: 0
.SystemMemoryCachedGiB  value: 0

这说明：

  • compute 未能从 MDB 中读取到有效的内存使用数据，导致无法更新 MemoryMetrics。
  • 虽然 host_agent 有数据，但 compute 没有正确消费。

:warning: 可能原因分析：

原因 说明 支持证据
1. compute 启动时机早于 host_agent 数据就绪 BMC 启动过程中，compute 可能在 host_agent 尚未完成数据上报前就初始化了 MemoryMetrics，导致初始化失败。 “概率性”出现，符合异步初始化竞争条件特征
2. MDB 资源路径映射错误或订阅失败 compute 未正确监听 host_agent 发布的内存数据路径（如 /bmc/kepler/Systems/1/Sms/1/...），导致数据未触发更新。 不同命名空间下数据隔离导致消费失败
3. CSR 配置缺失或不一致 MemoryMetrics 类的动态关联机制未配置正确的数据源路径。 CSR 文档中提到该字段来源于 CSR 配置和 MDB
4. 数据类型不匹配或格式错误 host_agent 上报的是字符串 "null" 或浮点，compute 解析失败。 日志中 .TotalPhysicalMemoryGiB value: "null" 存在类型问题
5. Signal 信号未触发更新 即使数据写入 MDB，若未发出 PropertiesChanged 信号，compute 不会重新计算。 OpenUBMC 框架依赖 D-Bus 信号驱动更新

:white_check_mark: 解决方案建议

:white_check_mark: 1. 确保 BMA 2.0 正常运行

  • 在 Host OS 执行：
    systemctl status bma-agent
  • 检查日志是否有上报错误：
    journalctl -u bma-agent | grep memory

:white_check_mark: 2. 验证 host_agent 是否持续更新数据

检查 host_agent 是否定时刷新内存数据（如每 30s 一次）：

# 查看 mdb_info 是否周期更新
watch -n 10 "mdbctl getprop /bmc/kepler/Systems/1/Sms/1/ComputerSystem/Systems/1/Summary.MemUsage"

:white_check_mark: 3. 检查 compute 是否订阅了正确路径

确认 compute 配置文件中是否包含对 /bmc/kepler/.../Summary 路径的监听，可通过以下方式验证：

  • 查看 compute 的日志：
    journalctl -u compute | grep -i memory
    观察是否有类似：
    INFO: Subscribing to /bmc/kepler/Systems/1/Sms/1/ComputerSystem...
ERROR: Failed to get property MemUsage from remote object

:white_check_mark: 4. 检查 CSR 配置项 MemoryMetrics

参考文档《CSR配置字典之MemoryMetrics类》：

  • BandwidthPercent 默认值为 255 表示未初始化。
  • 应配置数据源关联 Summary.MemUsage 或自动计算。

建议添加动态数据绑定（未来版本支持）或手动注册监听器。

:white_check_mark: 5. 重启 compute 服务测试

临时验证是否为启动时序问题：

systemctl restart compute
sleep 5
mdbctl getprop /bmc/kepler/Systems/1/Memory.BandwidthPercent

若此时值变为非 255，说明是启动顺序导致的初始化失败。

:white_check_mark: 6. 启用可观测性调试功能（高级）

启用指标采集，监控 compute 内存处理流程：

# 设置采样率，强制触发数据上报
mdbctl setprop modify Dashboard_0 bmc.kepler.Dashboard.Observability.Traces SamplingRate 1

查看 Prometheus/Grafana 是否能捕获 MemoryMetrics 更新轨迹。

:puzzle_piece: 附加建议：提高稳定性

优化项 建议
延迟 compute 初始化 添加对 host_agent 服务就绪的依赖，确保数据源可用后再加载 MemoryMetrics
增加重试机制 若首次加载失败，在后台定时尝试重新拉取数据
增加健康检查 若 BandwidthPercent == 255 超过一定时间，记录事件日志或生成告警
日志增强 在 compute 中增加 INFO: Updating MemoryMetrics from host data... 类日志，便于追踪

:white_check_mark: 总结回答

问题 回答
1. host_agent 能获取 MemUsage 是否意味着带内信息正常传递？ :white_check_mark: 是的，这表明 BMA 已成功将内存数据通过带内通道上报至 BMC，host_agent 已接收并写入 MDB，带内链路正常。
2. 为什么还需要 compute 处理？计算流程是什么？ compute 是系统级资源聚合器，负责将 host_agent 提供的原始数据转换为统一模型（如 MemoryMetrics），供 Web UI 和 Redfish 使用。BandwidthPercent 实际由 (Used/Total) × 100 计算而来。当前 value=255 表示 compute 未能成功获取或处理数据，可能是初始化时序、订阅失败或解析错误所致。

:white_check_mark: 推荐下一步动作：

  1. 检查 compute 日志，确认是否订阅了 /bmc/kepler/.../Summary 路径；
  2. 重启 compute 服务，观察 BandwidthPercent 是否恢复正常；
  3. 确认 CSR 配置与动态绑定逻辑，确保 MemoryMetrics 正确关联数据源；
  4. 若问题依旧，提交完整 AppDump 日志供进一步分析。

:speech_balloon: 注：本文档基于 OpenUBMC 25.09 SDK 架构及您提供的日志证据，结合知识库中的 Redfish API、host_agent、compute、MemoryMetrics、MDB 等组件关系进行综合分析，未引入外部假设。

相关链接：

  1. 安装iBMA后ubmc的首页没有上传cpu和内存信息
  2. 【社区文档月度报告】一图读懂12月社区文档更新清单
  3. bmc内存占用率过高
  4. 【教学培训篇】体验openUBMC
  5. 持久化机制常见问题 | 文档中心 | openUBMC