OpenBMC: coredump自动发现及调试实践
BMC（Baseboard Management Controller）是一种服务器上的独立微控制器，BMC 在提供 7*24 的硬件监控和管理功能的同时，还承担着诸多关键职责，为整个系统的可靠性、管理性提供了基础支持。
背景
BMC 介绍
关键职责和功能：
- 硬件监控与诊断：BMC 负责监控计算机硬件的状态，包括处理器、内存、存储、风扇、温度传感器等关键组件。通过实时监测，提供各组件的实时状态信息。
- 散热管理：BMC 负责监控所有的部件板卡的部件温度， 动态的调整服务器系统的风扇转速。
- 远程管理与控制：BMC 具备远程管理功能，允许运维人员无需物理接触硬件即可对系统进行监控和管理。通过 KVM ，查看和控制 server， 运维人员可以执行如开关机、重启、甚至是 OS 装机。
- 事件日志与报警：BMC 记录系统事件日志，其中包括硬件错误、警告和其他重要事件。运维人员可以通过检查事件日志及时发现潜在问题。
- 固件更新：BMC 提供服务器上大多数固件的远程更新， 包含 BIOS ， 多种 CPLD ， 电源， Retimer ， Box等…
OpenBMC 简单介绍
OpenBMC 项目的目标是一个开放、灵活、可定制的开源BMC解决方案, 主要基于 Yocto 作为构建组件及 Systemd 和 D-Bus 作用应用层的基础组件。
痛点
在 7*24 小时监控的环境中，我们提供多种服务并应对各种硬件配置的挑战，在安全且稳定的基础上提供高效服务。在这个复杂的情境中，我们不可避免地面临着在线上极低概率下产生 coredump 的可能性，通常这些 coredump 会带来一些不可预测的后果。同时还会遇到一些难以复现的问题，这些问题会消耗大量的人力和时间成本，而且这些问题可能发生在无法直接访问的业务机器上。
coredump 自动发现及调试实践
面对故障无法及时发现、日志无法及时收集以及复现环境成本可能过高等痛点，STE 团队提出了一套集成化流程，即 coredump 感知、收集、上报以及自动化分析。这一流程的实施解决了上面提到的问题。通过该流程，我们能够更快速地检测故障，实时收集相关日志，并在需要时重现环境，大大降低了故障排查的难度和成本。整体流程的图示如下：
感知
-
systemd-coredump 是一个 systemd 提供的一个 daemon，用于配置 linux coredump 和监听 coredump 的生成。它通过感知异常终止的进程并收集相关的 coredump 文件。
-
内部一个 daemon（debug-collector） ， 用于 watch coredump 产生， 主动触发 coredump 收集流程。
收集 coredump
在 BMC 固件内部， 监听到 coredump 事件产生之后， 会主动发起日志收集流程。主要包含工作包含：
日志收集
- coredump 文件：这是最关键的信息，包含了异常终止进程的内存快照。
- Journal 日志：包括核心转储进程的 PID 以及与其相关的所有系统日志。这有助于全面了解故障上下文。
- os-release 信息：指示固件版本，为问题溯源提供环境信息。
- 其他日志：包括系统和应用程序的其他关键日志，为问题定位提供更多上下文。
日志上传
等待所有日志收集完成， 打包所有日志并推送指定的服务器， 并标记日志为 coredump。
日志告警
服务器接收到日志， 如果日志为 coredump， 将日志信息推送到告警平台。
如何 debug （Offline）
准备 rootfs
Legacy Solution：
- git clone 代码并且切换 coredump 发生的版本上。
- 每次可能需要现场编译， 每次固件可能需要较长时间也可能因为编译环境的缺失/版本不兼容原因耗费一部分时间。
- 根据 coredump 异常的组件， 查找依赖， 手动拷贝相关的 debug 依赖的文件。
Current Solution：
IPK 包（ipk）是一种用于嵌入式 Linux 系统的软件包格式，通常用于嵌入式设备。这种软件包格式是用于轻量级 Linux 发行版的一种标准，具有简单、紧凑、易于管理的特点。 Ipk/opkg 之于 debian 相当于 deb/apt 的关系。 可以用 opkg 命令进行安装
将所有的包（包含 debug/src 包）准备为独立的 ipk 包:
https://subscription.packtpub.com/book/iot-and-hardware/9781785281952/5/ch05lvl2sec44/ipk-packages
Yocto 提供一种能力， 使得我们可以将所有的包（包含 debug/src 包）准备为独立的 ipk 包。并且可能根据编译依赖， 生成正确的依赖分析， 使得安装时能够自动安装依赖包。
$ bitbake package-index
随后可以正确的在 Yocto 目录 $BUILDDIR/tmp/deploy/ipk下找到对应的 ipk 包。
- 每次编译将所有 ipk 包 推送至远程文件服务器中， 并持久化存储。
- 将上述工作集成中 CI 中。
启动 debug
使用 GDB + 准备好的 rootfs + core file。
自动化
基于以上方案， 我们已经可以在本地环境， 使用一个集成的 debug_dump 的脚本集成 debug 工具。
- 收到告警信息后， 包含 coredump 日志 所在的 日志 URI， 可以下载指定的日志地址。
- 根据 coredump 日志包， 获取指定版本，待调试的 core 文件。
- 根据 coredump 产生所属的 binary 文件， 分析所来源的 ipk 包。
- 通过 opkg 命令， Install 指定的 ipk 包， 生成待调试的 rootfs
- 启动 gdb 并调试
Example:
~ ./debug_dump.py -u https://<path/to/your/ipk/source>/bmc_dump/obmcdump_coredump_22_67.tar.gz
INFO:debug_dump:Found core execfn /lib/systemd/systemd-journald
INFO:debug_dump:Downloading from https://<path/to/your/ipk/source>/bmc_ipk/ipks.tar to /tmp/ipkdbg_n_zlxpd3/ipks.tar
...
Installing systemd (250.3) on root.
Downloading file:///tmp/ipkdbg_n_zlxpd3/./ipk/arm1176jzs/systemd_250.3-r0_arm1176jzs.ipk.
...
Core was generated by `/lib/systemd/systemd-journald'.
Program terminated with signal SIGABRT, Aborted.
#0 __pthread_kill_internal (threadid=<optimized out>, signo=6) at pthread_kill.c:45
45 pthread_kill.c: No such file or directory.
#0 __pthread_kill_internal (threadid=<optimized out>, signo=6) at pthread_kill.c:45
#1 0x76be7fd0 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#2 0x76bd2428 in __GI_abort () at abort.c:79
....
接下来是进一步提高自动化的一些方法：将告警 bot 和 debug_dump 联动起来。
- Dump 分析服务：此服务接受 coredump 的日志链接， 接受到链接之后会执行 debug_dump 脚本进行分析。
- 告警 Bot: 生成 Dump 分析服务的一键到达的链接， 展示在相关的卡片中， 用户点击相关链接即可一键分析。
- WebUI: 用户可点击一键分析链接之后，即可在浏览器中打开WebUI，自动执行debug_dump，并可在webshell中直接进行gdb分析。
总结
通过这套流程，我们显著提升了 coredump 处理效率，减少了人力和时间成本，大幅提高了故障排查的速度和准确性。未来，我们将继续优化这一流程，确保在复杂的线上环境中提供高效稳定的服务, 我们未来的改进方向包括以下:
- 智能化分析：引入机器学习算法，对历史 coredump 数据进行分析，提前预测潜在问题，进一步提升系统的稳定性和预防性维护能力。
- 扩展自动化工具集：开发更完善的自动化调试工具，支持更多类型的故障和环境。
- 实时监控与响应：提升实时监控能力，确保在第一时间发现并处理coredump事件，减少系统宕机时间，保障业务连续性。
- 社区合作与反馈：积极参与 OpenBMC 社区，与其他开发者共享我们的经验和改进建议，吸收社区反馈，持续优化我们的解决方案。
通过这些改进，我们相信能够进一步提高 OpenBMC 固件的稳定性和可靠性，为用户提供更优质的服务体验。同时，我们也期待与业界同行深入交流合作，共同推动 BMC 技术的发展与创新。