Linux SRE 生产故障排查实践指南

场景

某电商平台核心应用服务器突然出现响应延迟，用户反馈页面加载超时。服务器为 CentOS 7，64核CPU，256GB内存，运行 Nginx 和 Java 应用。

症状

• SSH 登录缓慢，输入命令后延迟2-3秒才出现输出。
• uptime 显示 load average 55.23, 48.19, 32.54（超过64核CPU的80%）。
• 通过 top 观察到数个 java 进程 CPU 使用率高达 3000%（多线程）。
• iostat -x 1 显示磁盘 %util 持续 99%，await > 100ms。

诊断步骤

第一步：整体资源检查

# 查看负载、内存、IO
top -b -n1 | head -20
free -h
vmstat 1 5
iostat -x 1 3

发现 CPU 用户态高，系统态低；内存剩余充足；磁盘 IO 异常。

第二步：定位 IO 源头

# 找出哪些进程在读写磁盘
iotop -oP
# 查看文件系统状态
df -h
dstat --top-io --top-bio 1 5

发现 Java 进程的日志文件写入量极大，且日志目录所在磁盘分区 /var/log 使用率 95%。

第三步：深入分析日志写入

# 检查日志文件大小
ls -lh /var/log/app/*.log
# 使用 strace 跟踪特定 PID 的写操作（注意：仅限非生产负载时使用）
strace -p <PID> -e trace=write -c -S time 2>&1 | head -20

确认是日志框架配置为同步写入，每次触发 gc 都会产生大量日志。

风险控制

• 切勿直接 kill -9 关键进程。
• 调整日志级别前先通知团队，避免丢失审计信息。
• 使用 ionice 降低日志进程的 IO 优先级：ionice -c 2 -n 7 -p <PID>。
• 临时剪切日志文件（需先停止写入或使用 copytruncate）：logrotate -f /etc/logrotate.d/app。

解决方案与回滚

短期：压缩并轮转日志

# 手动轮转
mv /var/log/app/current.log /var/log/app/current.log.$(date +%Y%m%d%H%M%S)
kill -HUP <PID>  # 通知进程重新打开文件
# 配置 logrotate 为每天压缩轮转，保留7天

长期：修改日志配置为异步写入

修改 log4j2.xml 中的 Appender 为：

<RollingFile name="RollingFile" fileName="/var/log/app/app.log" filePattern="/var/log/app/app-%d{yyyy-MM-dd}-%i.log.gz">
  <PatternLayout pattern="%d{ISO8601} [%t] %-5p %c - %m%n"/>
  <Policies>
    <TimeBasedTriggeringPolicy/>
    <SizeBasedTriggeringPolicy size="100 MB"/>
  </Policies>
  <DefaultRolloverStrategy max="7"/>
  <AsyncLogger>
    <AppenderRef ref="RollingFile"/>
  </AsyncLogger>
</RollingFile>

重启应用前先在预发布环境测试。

回滚

如果修改后出现问题，恢复原日志配置文件并重启服务：

cp /etc/app/log4j2.xml.bak /etc/app/log4j2.xml
systemctl restart app

验证

• 再次运行 iostat -x 1，确保 %util 降至 30% 以下，await < 10ms。
• 使用 ab 或 wrk 对 Nginx 进行压力测试，响应时间恢复正常。
• 监控 load average 连续5分钟低于 CPU 核心数的 70%。

何时提交 OpsGlobal 工单

• 当问题根源不明确，上述步骤无法定位时。
• 需要内核参数优化（如 vm.dirty_ratio）但缺乏生产环境权限时。
• 疑似硬件故障（如磁盘坏道）需更换硬件时。
• 排查时间超过2小时仍无进展时。

请通过 OpsGlobal 控制台提交工单并附上以下信息： - 问题时间窗口、影响范围。 - 已执行的诊断命令及输出（敏感信息脱敏）。 - 系统版本、内核参数、相关配置文件的备份。