sosreport 分析实战培训

1. sosreport 是什么

sosreport 是 Red Hat / CentOS / Fedora 等企业级 Linux 发行版自带的诊断工具包,可一键收集系统运行状态、日志、配置、硬件信息,用于故障复盘、性能分析、合规审计和供应商技术支持。

2. 核心价值

• 无需登录目标主机,即可获取完整系统状态
• 跨越登录限制(机房禁登、VPN 不通)的远程诊断手段
• 完整保留故障现场,避免事后日志被覆盖
• 供应商支持必需文件(Red Hat GSS、Dell PERC 等)

3. 收集内容分类

4. 收集命令

# RHEL 10 收集 sosreport
sos report --all-logs

# RHEL 7/8/9
sosreport --all-logs

# 收集结果
sos_commands/   var/log/
etc/            proc/
boot/           sos_reports/

5. 解压后目录结构

sosreport-hostname-timestamp.tar.xz
├── sos_commands/        # 各类诊断命令的输出快照
├── var/log/             # 系统日志
├── etc/                 # 配置快照
├── proc/                # 运行时内核参数
├── boot/                # 引导配置
└── sos_reports/         # sosreport 自身报告

6. 常用触发场景

1. 七步证据链

证据链分析法通过系统性地收集从用户报告到硬件层的多维度证据,确保根因判断有充分依据。

1. 用户报告的症状 — 故障现象、影响范围、首次发生时间、持续时间
2. 确认时间窗口 — 故障时间 vs. SOS 收集时间 vs. 系统 uptime,确认日志是否覆盖
3. 日志证据 — messages · dmesg · journal · audit · sos_commands/kernel/dmesg
4. 运行时证据 — ip · ps · df · mount · multipath · systemctl · ethtool · netstat
5. 配置证据 — /etc 配置文件 · 网络脚本 · SELinux 策略 · sysctl 参数
6. 驱动 / 固件 / 硬件证据 — dmidecode · lspci · lsmod · ethtool -i · megaraid logs
7. 综合评估 — 严重度定级 · 置信度 · 行动项,输出结构化分析报告

2. 严重度定级标准

3. 首次必检文件清单

• etc/os-release
• sos_commands/kernel/uname_-a
• sos_commands/host/uptime
• sos_commands/date/date
• proc/cmdline
• var/log/messages
• var/log/dmesg
• sos_commands/kernel/dmesg

> 不要凭单一计数器下结论。累计计数器 ≠ 当前增长,需结合时间线与 Uptime 共同判断。

1. 确认系统基本信息

确认 OS / 内核版本、主机名、运行时间、是否重启过(BOOT TIME)。

cat etc/os-release
cat sos_commands/kernel/uname_-a
cat sos_commands/host/uptime
who -b && last reboot | head -3

2. 全局关键错误扫描

搜索 panic、OOM、I/O error、硬件错误、内核崩溃等关键词,500 行上限防止输出过大。

grep -RniE "panic|oom-killer|I/O error|Call Trace|hung task|soft lockup|hard lockup|MCE|PCIe Bus Error|segfault" \
  var/log sos_commands 2>/dev/null \
  | head -500

3. 症状映射到分析模块

根据故障类型选择对应专项参考文件,精准定位,避免大海捞针。

4. 时间线与置信度评估

回答 5 个关键问题,判断分析结论的可信程度:

1. 何时收集?
2. 运行多久?
3. 是否重启?
4. 日志覆盖故障窗口?
5. 错误在重启前还是之后?

1. 症状描述

用户反映部分服务连接超时,访问延迟升高,iperf3 测速带宽显著下降,TCP 重传率超 5%。

2. 证据收集步骤

# 接口错误计数器
ethtool -S eth0 | grep -E "rx_crc_errors|rx_frame_errors"
ip -s -d link       # RX errors 计数持续增长

# 协商状态
ethtool eth0       # Speed / Duplex / Auto-neg 状态

# Bonding 信息
cat /proc/net/bonding/bond0    # bond 模式和 slave 状态

# TCP 重传统计
netstat -s | grep retransmits

# 错误关键字扫描
grep -Ei "error|drop|crc|miss|fifo|overrun|carrier" \
  sos_commands/networking/ethtool_-S_* \
  2>/dev/null

3. 关键文件清单

• sos_commands/networking/ethtool_-S_<iface>
• sos_commands/networking/ethtool_<iface>
• sos_commands/networking/ip_route_show_table_all
• sos_commands/networking/netstat_-s
• proc/net/bonding/bond0

4. 根因分析

5. 建议行动

• 检查网线 / 光模块物理状态并更换确认
• 确认交换机端口 speed/duplex/auto-neg 配置一致
• 检查光纤弯曲半径是否达标,光功率是否在范围
• 如有持续 CRC 报错,更换 NIC 光模块或整卡
• 更新驱动或固件至厂商推荐版本
• 建立持续监控:CRC errors > 0 立即告警

1. 症状描述

应用报错 "Read-only file system",所有写入操作失败。dmesg 中可见 "EXT4-fs error" 或 "XFS internal error",日志显示 "Remounting filesystem read-only"。

2. 证据收集步骤

# 1. 找只读触发点
grep "Remounting filesystem read-only" var/log/messages

# 2. 挂载状态
cat sos_commands/filesys/mount | grep -v "^proc"

# 3. 多路径状态(是否 all paths down)
multipath -ll

# 4. 块设备拓扑
lsblk

# 5. RAID 控制器日志
megaraid / mpt3sas / nvme logs | grep -i "reset"

# 6. 关键字扫描
grep -RniE "xfs|ext4|read-only|I/O error|journal commit|metadata" \
  var/log sos_commands 2>/dev/null \
  | head -200

3. 关键文件清单

• var/log/messages · var/log/dmesg · sos_commands/kernel/dmesg
• sos_commands/filesys/df_-h · sos_commands/filesys/mount
• sos_commands/multipath/multipath_-ll
• sos_commands/block/lsblk · sos_commands/block/blkid

4. 根因分析

只读是症状,非根因 —— 底层存储出现问题才触发保护性只读。

5. 建议行动

切勿先执行 fsck / xfs_repair!先查存储链路。

• 检查 HBA / RAID 控制器健康状态(megaraid -adpAllInfo)
• 确认 multipath -ll 显示所有路径状态(active ready)
• 联系存储团队 / SAN 网络管理员确认链路连通性
• 必要时执行 storage array consistency check
• 修复底层问题后,以 mount -o remount,rw 重新挂载为读写
• 修复后建议跑一次 SMART short test 确认磁盘健康

1. 症状描述

系统意外重启或 panic,dmesg / messages 中可见 "Kernel panic"、"Oops"、"BUG:"、"Call Trace" 或 "soft lockup"。部分场景下系统 hang 住被 NMI watchdog 重置。

2. 证据收集步骤

# 1. 找 panic/BUG/Call Trace
grep -Ei "panic|BUG:|Call Trace|NMI|watchdog" var/log/messages | head -50

# 2. 上下文(Call Trace 周围 10 行)
cat sos_commands/kernel/dmesg | grep -A10 "Call Trace"

# 3. 重启时间线
last | head -10

# 4. kdump 配置
cat etc/kdump.conf
cat proc/cmdline | grep crashkernel
ls -lh /var/crash/  # 是否有 vmcore

# 5. 内核 Tainted 状态
uname -a | grep -o "Tainted:.*"
lsmod | head -30

# 6. 关键字扫描
grep -RniE "panic|oops|BUG:|soft lockup|hard lockup|NMI watchdog|tainted" \
  var/log sos_commands 2>/dev/null \
  | head -100

3. 关键文件清单

• var/log/messages · var/log/dmesg · sos_commands/kernel/dmesg
• sos_commands/last/last · sos_commands/host/uptime
• etc/kdump.conf · proc/cmdline · boot/grub2/grub.cfg
• sos_commands/kernel/uname_-a(看 Tainted 标志)
• /var/crash/<日期>/vmcore(如已配置 kdump)

4. 根因分析

找第一个 panic/oops,而非后续级联反应。

5. 建议行动

• 如有 vmcore 文件 → 联系 Red Hat GSS / 厂商支持做 crash dump 分析
• 检查 lsmod 输出,排除加载的可疑第三方模块(out-of-tree 驱动)
• 核对内核版本与所有驱动版本的兼容性(厂商 HCL)
• 检查硬件日志:MCE / EDAC / AER 是否有 hardware error 记录
• 确认 kdump 配置正确且有足够 crashkernel 内存
• 如是 NVMe 设备,检查固件版本是否有已知 bug(查厂商 advisory)
• 建议:保留 vmcore、dmesg、messages 原始文件供供应商分析

1. 场景描述

拿到 sosreport 后,客户说"Slot 4 槽位那块盘报黄灯,需要现场更换"。需要从 /dev/sda 倒推回物理槽位,或者反过来。

2. 五步法定位流程

通过 Dell perccli64 工具,从目标盘 → VD → OS 设备名,或反之。

步骤 1:获取所有磁盘 SN 和 Slot 信息

perccli64 /call show AliLog
# 找到目标磁盘的 Serial Number(如 WBMANNDN)和 Slot 槽位号(如 Slot 4)。
# 所有磁盘均列出,可用 SN 精确定位目标盘。
# SN=WBMANNDN → Slot 4 (E251/S4)

步骤 2:确认该盘详细属性与 DriveGroup

perccli64 /call/e252/s4 show all
# 确认该盘详细属性:SN、型号、容量、WWN、Firmware,以及 DriveGroup=3、Span=0、Row=0
# DriveGroup:3 · Span:0 · Row:0 · SN:WBMANNDN

步骤 3:找到 DriveGroup 对应的 Virtual Drive

perccli64 /call/vall show all
# 找到该 DriveGroup=3 对应的 Virtual Drive(VD=236),并确认该 VD 由哪个物理盘组成(E252:Slot4)。
# DG=3 · VD=236 · RAID0 · Optl · /dev/sda 对应 E252:4

步骤 4:查看 VD 详细属性,获取 OS Drive Name

perccli64 /call/v236 show
# 查看 VD 236 详细属性,其中 OS Drive Name 字段即为该 VD 在 Linux 中的设备名(如 /dev/sda)。
# OS Drive Name: /dev/sda(VD 236 对应 OS 设备)

步骤 5:用 lsblk 确认挂载状态

lsblk
# 确认 /dev/sda 的分区情况和挂载点。本例中 sda/sdb/sdc 均无挂载(2.2TB 盘),sdd 为系统盘有 / 和 /boot/efi 分区。
# sda 无挂载 · sdd2 → /(系统盘)

3. 注意事项

• 不同 PERC 卡使用不同版本 perccli
• RAID 和 NON-RAID 磁盘定位命令不同
• 需根据实际配置调整命令参数
• Dell PowerEdge 推荐用 perccli64
• storcli64 与 perccli64 用途类似但格式不同
• 定位完成后务必用 lsblk 确认设备名
• 涉及 RAID 操作前请先备份数据