📚 课程目录第4章故障信息收集

4. 故障信息收集

故障定位的第一步不是分析，而是收集。很多工程师在遇到硬件故障时，急于拆机、换件、打波形，结果往往因为缺少关键的过程数据，导致问题无法复现，或者只能靠猜测定位。硬件故障的信息收集，本质上是在构建一个“案发现场”的完整拼图：日志告诉我们系统在崩溃前做了什么，事件告诉我们异常发生的顺序，错误码告诉我们硬件模块的自我诊断结论，系统状态告诉我们资源与链路的健康度，而环境数据（温度、电压、湿度）则揭示了物理层面对电子设备的潜在胁迫。本章将系统讲解这五类信息的采集方法、工具链以及实战中的取舍策略。

上图展示了故障信息采集的完整体系。在实际排障中，这五类数据不是孤立存在的，而是需要按照统一的时间基准进行关联分析。例如，一条 PCIe AER 错误日志（错误码）如果与电源电压跌落（环境数据）在时间上吻合，那么根因方向就会从“链路稳定性”转向“供电完整性”。因此，采集工具的选择和部署方式，直接决定了后续根因分析的效率与准确性。

4.1 系统日志与事件记录的采集方法

核心原理：系统日志是操作系统、驱动、固件和应用对硬件状态的“自述”。Linux 下，内核环形缓冲区（dmesg）记录了从开机到当前时刻的硬件初始化、中断、DMA、PCIe 链路训练等关键事件；而 syslog/journald 则记录了用户态服务与内核交互的异常。事件记录（Event Log）则更侧重于硬件模块自身的状态机变化，例如 IPMI SEL（System Event Log）中的温度告警、电压越限、风扇转速异常等。两者的本质区别在于：日志是“软件视角”，事件是“固件/硬件视角”。

判断方法与操作流程：采集日志时，必须遵循“先保全、后分析”的原则。具体操作流程如下：

立即冻结现场：在系统尚未完全宕机时，第一时间执行 journalctl --since "1 hour ago" > /tmp/syslog_$(date +%Y%m%d_%H%M%S).log，同时执行 dmesg -T > /tmp/dmesg_$(date +%Y%m%d_%H%M%S).log。注意使用 -T 参数将时间戳转换为可读格式。
抓取内核崩溃转储：如果系统已 panic，检查 /var/crash/ 或 /var/lib/systemd/coredump/ 目录，使用 crash 工具或 gdb 分析 vmcore 文件。
读取硬件事件日志：通过 IPMI 工具执行 ipmitool sel elist 查看 SEL 事件，或通过 ipmitool sensor list 获取当前传感器读数。
记录时间基准：执行 date 和 cat /proc/uptime，确认系统运行时长，便于将日志时间戳与外部监控平台对齐。

日志类型	典型来源	采集工具	关键关注点
内核日志	驱动、PCIe、DMA、中断	dmesg -T	Hardware Error、Call Trace、timeout
系统日志	systemd、应用服务	journalctl -xe	服务重启、资源耗尽、I/O error
固件事件	BIOS/UEFI、BMC	ipmitool sel elist	电压/温度阈值告警、开机自检失败
应用崩溃	应用程序	coredumpctl list	段错误、非法指令、堆栈回溯

风险提示：不要在生产环境直接重启服务器来“清空日志”。很多硬件故障在重启后无法复现，而内存中的 dmesg 环形缓冲区会丢失。应先尝试通过网络串口（SOL）或 BMC 的 SOL 功能保存完整启动与运行日志。

4.2 错误码与硬件状态寄存器的读取

核心原理：错误码是硬件模块内部状态机的“黑匣子”。以 PCIe 设备为例，AER（Advanced Error Reporting）能力结构中的 Uncorrectable Error Status 寄存器记录了链路训练失败、ECRC 错误、Malformed TLP 等具体错误类型。而 NVMe 设备则通过 SMART/Health Information 日志返回温度、备用块百分比、不可恢复错误计数等。读取这些寄存器，需要借助特定的诊断工具，如 setpci、nvme smart-log、ethtool -S 等。

操作流程：以 PCIe 设备错误码读取为例：

# 1. 定位设备 BDF（Bus:Device.Function）
lspci -nn | grep -i "Non-Volatile"
# 输出示例: 01:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981

# 2. 读取 AER 错误状态寄存器（偏移 0x04 为 Uncorrectable Error Status）
setpci -s 01:00.0 ECAP_AER+0x04.w
# 输出示例: 0001  (bit0 表示 Undefined error 已置位)

# 3. 读取 NVMe 健康信息
nvme smart-log /dev/nvme0n1
# 关注: critical_warning、temperature、available_spare、media_errors

案例拆解：某存储服务器出现间歇性 NVMe 掉盘。初始现象为业务侧报 I/O timeout，但系统日志无 PCIe AER 记录。通过 nvme smart-log 发现 temperature 为 78°C（接近 80°C 告警阈值），且 available_spare 从 100% 降至 97%。进一步用 ethtool -S 检查 NVMe 所在 PCIe 插槽的链路重训练计数，发现 link_retraining_count 在故障时段增加了 15 次。结合机箱进风口温度传感器数据（环境数据），确认是机房空调故障导致局部高温，进而引发 NVMe 控制器降频和链路不稳定。更换空调并加装导风罩后，故障消失。此案例中，错误码（SMART 温度）与环境数据（进风口温度）的关联是定位根因的关键。

经验提醒：错误码读取要“快、准、全”。快是指第一时间读取，避免寄存器被驱动重置；准是指明确寄存器偏移和位定义，参考对应芯片的 Datasheet 或 PCIe Base Spec；全是指同时读取 Corrected Error Count 和 Uncorrected Error Status，因为频繁的可纠正错误往往是不可纠正错误的前兆。

4.3 系统状态与资源使用情况的快照采集

核心原理：系统状态数据反映了硬件资源在故障时刻的“压力分布”。CPU 中断分布不均、内存碎片化严重、网卡环形队列溢出、磁盘 I/O 等待队列过长，这些状态往往是硬件故障的诱因或结果。采集系统状态的核心在于“快照”与“趋势”的结合：快照用于定格故障瞬间，趋势用于判断资源耗尽的过程。

判断方法与工具：

CPU 与中断：使用 mpstat -I CPU -P ALL 1 5 观察软中断（softirq）分布，使用 cat /proc/interrupts 查看中断号与 CPU 亲和性。
内存与 I/O：执行 vmstat 1 10 关注 si/so（swap in/out）和 wa（I/O wait），执行 iostat -x 1 5 查看 %util 和 await。
网络与链路：使用 ethtool -S eth0 查看 rx_missed_errors、tx_timeout，使用 ip -s link show eth0 查看丢包与错误计数。
硬件计数器：对于网卡或 HBA，使用 ethtool -d eth0 读取寄存器 dump，或使用厂商工具如 mlxstat（Mellanox）、storcli（LSI RAID）获取内部状态。

实战场景：某视频处理板卡在运行 4K 编码任务时偶发黑屏。采集系统状态发现 /proc/interrupts 中 GPU 中断全部集中在 CPU0，且 mpstat 显示 CPU0 的软中断利用率达到 100%，而其他 CPU 空闲。进一步用 perf top 定位到中断处理函数耗时异常。最终通过调整中断亲和性（将 GPU 中断绑定到多核）解决了问题。此案例说明，系统状态数据不仅用于定位硬件故障，还能发现资源分配不均导致的“软故障”。

4.4 环境数据（温度、电压、湿度）的采集与判读

核心原理：环境数据是硬件可靠性的“物理边界”。电子元器件的失效率与温度呈指数关系（阿伦尼乌斯模型），电压偏离标称值超过 ±5% 就可能导致逻辑电平翻转，湿度超过 60% 则可能引发凝露和爬电。采集环境数据需要分层：板级传感器（如 LM75、TMP117）、机箱级传感器（BMC 管理的进风/出风温度）、以及机房级环境监控（温湿度探头）。

采集方法与工具：

数据类别	采集方式	典型工具/命令	判读标准
板级温度	I2C 总线读取传感器	sensors-detect / sensors	核心芯片结温 < 105°C（参考规格书）
电压轨	PMBus / 万用表测 TP	ipmitool sensor list / multimeter	±5% 以内（如 12V 轨：11.4V~12.6V）
湿度	机房环境监控	SNMP 读取 / 手持式温湿度计	40%~60% RH（无凝露）
气流/风扇	BMC 风扇转速	ipmitool sdr list	转速在设定 PWM 曲线的 ±20% 内

案例拆解（完整闭环）：某通信基站主控板出现随机死机，重启后恢复正常，但故障频率逐渐升高。初始现象为系统日志无任何异常，错误码寄存器干净。团队决定部署环境数据采集：在 PCB 关键位置（CPU 附近、DDR 颗粒旁、电源模块输出端）焊接细线连接至数据采集仪，同时通过 BMC 记录机箱进风温度。经过 72 小时连续监测，发现死机前 2 分钟，CPU 附近板温从 78°C 快速攀升至 96°C，同时 1.0V 核心电压轨从 1.01V 跌落至 0.94V。分析判断：电压跌落并非由负载瞬变引起（因为电流并未同步增加），而是由于板温升高导致 DC-DC 转换器的 MOSFET 导通电阻增大，效率下降，进而输出电压跌落。当电压低于 DDR 控制器的最低工作门限时，触发内部 POR（上电复位），表现为死机。实际操作步骤：1) 更换导热垫片，增大 CPU 散热器与 PCB 的接触面积；2) 在 DC-DC 反馈回路中增加一个 NTC 热敏电阻进行温度补偿；3) 修改 BMC 风扇调速策略，将 75°C 时的风扇转速提高 20%。结果对比：改造后连续运行 30 天，板温稳定在 70°C 以下，电压轨波动小于 ±2%，死机现象消失。复盘经验：环境数据采集不能只看平均值，要关注“变化率”和“事件前后的相关性”。如果只采集了温度而没有同步采集电压，这个案例的根因极难定位。

风险说明：焊接测试线到 PCB 上存在风险，操作不当可能损伤走线或焊盘。建议优先使用 PCB 上预留的测试点（TP），若无 TP，则使用探针夹持，避免在通电状态下焊接。另外，万用表测量电压时，要使用带宽足够的示波器（至少 100MHz）观察纹波，而不仅仅是直流平均值。

4.5 常见误区与总结复盘

误区一：只收集日志，不收集环境数据。很多工程师认为日志是“主要线索”，环境数据是“辅助参考”。实际上，硬件故障中超过 40% 的根因与热、电应力相关。没有环境数据，日志中的错误码往往只是“果”而非“因”。

误区二：时间戳不同步。系统日志使用本地时间，BMC SEL 使用 RTC 时间，而外部监控平台可能使用 NTP 时间。如果时间偏差超过 1 分钟，关联分析就会失真。务必在采集前统一时间基准，或记录各数据源的时间偏移量。

误区三：采集工具影响故障现场。例如，使用 top 或 perf 等工具本身会消耗 CPU 资源，在系统已经过载时可能加剧故障。建议优先使用无侵入式的 BMC 带外管理接口（如 IPMI、Redfish）采集数据，避免在故障系统上运行重型诊断工具。

误区四：忽略“负数据”的价值。故障发生前 5 分钟一切正常的数据，与故障发生时的异常数据同样重要。例如，电压在故障前一直稳定在 12.02V，故障瞬间跌至 11.5V，这组对比数据能帮助判断是电源本身的问题还是负载瞬变引起的。

总结复盘：故障信息收集的核心目标是构建一条完整、可回溯、时间对齐的“证据链”。建议团队建立标准化的采集脚本包（包含 dmesg、journalctl、ipmitool、ethtool、sensors 等命令），并定期演练。在每次重大故障复盘时，应检查以下问题：我们是否在第一时间保全了现场？五类数据是否齐全？时间戳是否对齐？是否有数据被覆盖或丢失？只有将信息收集做到“肌肉记忆”级别，才能在真正的重大故障面前从容应对。