服务器死机后的日志分析思路

当服务器突然躺平：我的日志分析求生指南

上周五凌晨3点，我被刺耳的电话铃声惊醒——生产环境服务器挂了。作为运维老鸟，这种半夜惊魂早就习以为常，但每次打开终端查看日志时，那种面对海量数据的茫然感依然挥之不去。今天就来分享下我这些年总结的服务器死机日志分析套路。

第一步：先别急着重启

新手最容易犯的错误就是直接reboot。有次我手快重启后，老板追查事故原因时，我只能对着空荡荡的/var/log/messages干瞪眼。现在我的流程是：

1. 立即用手机拍下显示器上的内核panic信息（如果有）
2. 通过IPMI/iDRAC等带外管理保存当前屏幕截图
3. 尝试用ssh -v连接测试网络栈是否存活

第二步：定位关键时间点

相信我，用grep直接扫全部日志就像大海捞针。我习惯先用这些命令锁定范围：

# 查看最后记录的时间戳
tail -n 50 /var/log/syslog | grep -E 'Jun|Jul|Aug'

# 检查OOM killer是否出手
dmesg -T | grep -i 'killed process'

# 快速定位错误集中时段
journalctl --since "2 hours ago" | grep -E 'err|fail|crit'

有次发现MySQL崩溃前有大量swap操作，顺藤摸瓜找到了内存泄漏的PHP脚本。

第三步：必查的五个日志文件

根据我的血泪史，这些文件出镜率最高：

• /var/log/kern.log – 内核级错误（硬盘SMART报警就在这里）
• /var/log/syslog – 系统服务的集体吐槽大会
• /var/log/dmesg – 硬件设备的临终遗言
• 应用日志 – 比如Nginx的error.log会有worker process exited
• ~/.bash_history – 别笑！真遇到过实习生误操作删库

第四步：逆向推理时间线

我习惯用这个命令把关键事件串成故事：

zgrep -h 'error' /var/log/syslog* | sort -k3M -k4n | less

曾经发现一个有趣的现象：每次死机前20分钟，都有个cronjob在跑数据分析脚本。后来用strace跟踪才发现脚本会耗尽inode。

最后的忠告

经历过无数次深夜救火后，我总结出三条铁律：

1. 日志轮转配置一定要测试（有次logrotate自己把日志切丢了）
2. 关键业务服务器必须配置netconsole远程日志
3. 养成给可疑日志打tag的习惯，比如logger -t "KERN_PANIC"

现在我的手机相册里除了孩子照片，就是各种服务器崩溃截图。如果你也有奇葩的死机经历，欢迎在评论区分享——毕竟运维的快乐，就是大家一起踩坑啊！