先取证再重启：故障现场的价值

遇到服务器卡死或服务异常，很多人的第一反应是重启。重启确实常常有效，但同时也把最重要的证据清掉了，下一次同样的问题再来，还是只能靠猜。 一、重启会毁掉哪些证据 系统运行中的状态只存在内存里：哪个进程在吃 CPU、哪些连接挂着没断、内核最近报了什么错、服务崩溃前最后打印的日志。重启之后这些全部归零，磁盘上的日志只保留了已落盘的部分，进程临死前的现场往往恰恰没来得及写进去。内存泄漏就是典型：进程跑了几天才异常，重启后一切正常，再泄漏又要几天，没有现场就只能干等复现。举例来说，连接队列打满的问题，netstat -s 里的计数在重启后清零，事后根本无从对证。故障越是偶发，现场就越珍贵。 二、现场该抓哪些信息 把关键命令的输出落盘保存（假设已建好 /tmp/evidence 目录）： top -b -n1 > /tmp/evidence/top.txt ps auxf > /tmp/evidence/ps.txt free -m; df -h > /tmp/evidence/mem_disk.txt iostat -x 1 3 > /tmp/evidence/io.txt netstat -s > /tmp/evidence/netstat_s.txt dmesg -T | tail -200 > /tmp/evidence/dmesg.txt journalctl --since "1 hour ago" > /tmp/evidence/journal.txt dmesg 里出现 Out of memory: Kill process，说明是内存耗尽触发了 OOM 杀进程；netstat -s 里大量 overflow，说明连接队列被打满。这些关键行重启之后就再也看不到了。 三、取证的边界 取证只做只读操作：不改配置、不动业务数据、不重启服务，top、cat、tail、dmesg 这类命令都是安全的。也不要临时在故障机上现装一堆分析工具，先存原始数据，分析放到自己的电脑上做，装包本身就可能改变系统状态。还有一条纪律是快：取证窗口常常只有几分钟，业务方在催着重启，所以清单要背熟或做成脚本。实在来不及，至少抓 top、dmesg、日志尾部这三样再重启，多数场景都来得及。 四、一份最小取证流程 mkdir -p /tmp/evidence-$(date +%F-%H%M) 建带时间戳的目录，按上面清单逐条落盘，再 tar czf /root/evidence.tar.gz /tmp/evidence-* 打包收好。全程一两分钟，对业务没有额外压力。取证完成，再决定是重启还是继续排查。 建议把这份命令清单存成脚本放在常用机器上，出事时一条命令跑完。取证是止损的前置动作，顺序反了，代价是下次故障依旧两眼一抹黑。