为什么要有采集脚本
内存类问题的排障过程往往是重复的：先看配置、再看内核错误记录、再看 BMC 事件，然后发现还缺一项数据又要重新上机取一次。用一段固定脚本把这几类证据一次采集并打包，能把这种往返降到一次，也方便把完整的证据包直接转给厂商支持。脚本的价值不仅在省时间，更在于采集口径统一——同一机型不同时间取到的数据可以横向对比。
基本信息
| 运行环境 | Linux 服务器，需 root 权限（读取 DMI 与日志） |
|---|---|
| 采集内容 | 硬件配置、内核错误记录、BMC 事件、近期日志 |
| 输出形式 | 按时间命名目录，打包为单个压缩文件 |
| 配合信息 | 附加机型、序列号与固件版本 |
| 使用建议 | 脚本纳入运维工具库并固定输出路径 |
| 外发要求 | 日志可能含业务信息，按流程脱敏 |
典型使用场景
- 内存报错后的证据固化，减少反复上机取数
- 厂商报修：一次提供完整证据包
- 更换决策：用同一口径的数据横向比较多台机器
- 复盘归档：把故障现场数据与工单一起保存
- 批量巡检：定期采集形成历史数据序列
采集脚本（bash）
采集脚本（bash）
OUT=/tmp/mem_report_$(date +%F_%H%M)
mkdir -p "$OUT"
# 硬件配置：内存槽位、容量与速率
dmidecode -t 16 -t 17 > "$OUT/dmi.txt"
# 内核侧错误记录：EDAC 与机器检查相关
dmesg -T | grep -iE "edac|mce|memory error" > "$OUT/kernel_mem.txt"
# BMC 事件日志：硬件侧记录
ipmitool sel elist > "$OUT/sel.txt" 2>/dev/null
# 近期内核日志中的同类记录（journal 环境）
journalctl -k --since "7 days ago" | grep -iE "edac|mce" > "$OUT/journal_mem.txt"
# 打包为单个证据文件
tar czf "$OUT.tgz" -C /tmp "$(basename "$OUT")"
ls -lh "$OUT.tgz"采集项与用途
| 采集项 | 来源 | 用途 |
|---|---|---|
| 内存配置 | DMI 表 | 确认条数、槽位与运行速率 |
| 内核错误记录 | 内核环形缓冲 | 捕获最近的硬件错误信息 |
| BMC 事件 | IPMI SEL | 获取带位置的硬件侧记录 |
| 历史日志 | journal 或日志文件 | 补齐被缓冲冲刷的记录 |
| 机型与版本 | DMI 与固件查询 | 供厂商判断平台基线 |
把脚本放进运维工具库并固定输出路径：长期对比同一机型的历史证据包，比每次临时写命令高效得多。
证据包含主机名、序列号与配置信息：外发前按内部规范做脱敏与审批，不要直接发送到公共渠道。