服务器重启如何排查原因

本文目录导读：

1. 第一阶段：紧急处置与现场保全
2. 第二阶段：分类排查（按可能性从高到低）
3. 第三阶段：针对不同重启情况的专项排查
4. 第四阶段：无法启动到系统（系统盘损坏）的处理
5. 总结：排查 Checklist（按顺序）

服务器重启（非计划内）是一个非常严重的故障信号，要排查原因，核心思路是先救火（恢复服务），后验尸（分析根因）。

如果服务器正在发生重启（或已经停机），请按照以下顺序进行排查：

第一阶段：紧急处置与现场保全

目的：尽快恢复业务，同时保留用于分析问题的事实证据。

1. 切断自动拉起机制：如果服务器是容器或虚拟机，并且设置了自动重启或高可用（HA，High Availability）策略（如 Kubernetes、vSphere），在查明原因前，先暂停自动恢复，防止服务器“反复去世”导致日志被覆盖或引发二次故障。

2. 收集最后一次启动前的现场信息（最关键的证据）：

   • 操作系统日志：这是最重要的证据，在 Linux 中，查看核心日志：

     # 查看上次关机或重启前几分钟的日志（建议使用 journalctl）
     journalctl -xe | grep -i -E "error|crash|kernel|oom|shutdown|reboot|panic" 
     # 或者查看 last 命令记录的重启时间点
     last reboot
     # 如果是硬件/内核问题，看 dmesg 输出
     dmesg | grep -i -E "error|panic|critical"
     # 老系统可能是 /var/log/messages
     tail -100 /var/log/messages

   • 硬件健康日志：如果服务器未完全死机，立即查看硬件状态：

     # 查看硬件故障 (IPMI/BMC 工具)
     ipmitool sel list
     # 查看硬盘 SMART 信息
     smartctl -a /dev/sda
     # 查看内存错误 (mcelog)
     cat /var/log/mcelog  # 如果启用

   • 应用日志：在日志被覆盖前，备份最近的 Web 服务器（Nginx/Apache）、数据库（MySQL/PostgreSQL）、Java 应用日志等。

第二阶段：分类排查（按可能性从高到低）

根据经验,服务器重启的根因通常集中在以下几类：

硬件故障（最常见原因之一）

• 电源问题：电源模块（PSU，Power Supply Unit）故障、功率不足、线缆松动，表现为瞬间掉电重启。
• 内存故障：不可纠正的内存错误（Uncorrectable Memory Error）。dmesg 或 mcelog 中会看到大量 corrected/uncorrected error，这是导致随机、无规律重启的头号元凶。
• CPU过热：散热器堵塞、风扇停转、硅脂干透。dmesg 中会有 thermal 相关警告，或 sensors 命令显示温度过高。
• 主板/芯片组：电容爆浆、供电模块损坏，通常需要查看 BMC/IPMI（基板管理控制器，智能平台管理接口）日志。

操作系统/内核问题

• 内核恐慌：Kernel Panic，日志中会有 panic 字样，通常由驱动程序冲突、文件系统损坏或根因在硬件。
• 系统配置错误：如 /etc/fstab 配置错误导致挂载失败，系统无法启动（循环重启），通常可以通过单用户模式修复。
• 关键服务冲突：systemd 配置死循环，或者某个服务疯狂申请资源导致系统僵死。

资源耗尽（OOM，Out-Of-Memory，内存溢出）

• Out of Memory Killer：物理内存和 Swap 都耗尽时，系统会杀掉进程，但如果杀不掉关键进程（如 systemd），或者杀进程的速度赶不上内存泄露的速度，系统会直接重启。

  # 检查是否有 OOM Killer
  journalctl -xe | grep -i "oom" 
  journalctl -xe | grep -i "out of memory"

• 磁盘空间满：特别是 /var、/tmp、 目录，系统某些核心服务（如 cron、 syslog）无法写入日志可能导致异常。

应用/人为因素

• 定时任务（Cron）或脚本：检查 /etc/cron* 和 crontab -l，是否有运维脚本、监控脚本或调皮同事写的 shutdown -r 或 reboot 命令？
• 系统更新：近期是否安装了新的内核或驱动？有些补丁可能需要重启，但如果是自动安装的，可能触发了重启。
• SSH/远程指令：检查 /var/log/auth.log 或 secure 日志，看是否有可疑的 su、ssh 登录后执行了关机/重启命令。
• Web控制台误操作：云厂商（AWS、阿里云、腾讯云）或机房 IPMI 控制台上，是否有误点击了重启？

第三阶段：针对不同重启情况的专项排查

情况 A：无规律、间隔不定的随机重启

• 核心嫌疑：硬件（内存、CPU 过热、电源）、内核 Bug。
• 动作：
  1. 运行 memtest86+（内存诊断工具） 24 小时以上，检测内存错误。
  2. 查看 BMC/IPMI 事件日志（SEL，System Event Log，系统事件日志），看是否有 Power Supply Failure、Hardware Monitor、FAN failure 等记录。
  3. 检查 /var/log/ 中是否有 mcelog 记录。

情况 B：固定时间点重启（如每天凌晨 2：00、每周三 3：00）

• 核心嫌疑：定时任务、系统备份脚本、杀毒软件扫描。
• 动作：
  1. crontab -l 查看所有用户的定时任务。
  2. 检查 /etc/cron.d/、/etc/cron.daily/、/etc/cron.hourly/。
  3. 查看该时间点的系统日志,看是否有备份服务（如 rsync）、重启脚本或 yum-cron 等自动更新工具在运行。

情况 C：负载飙升后重启（如流量高峰时）

• 核心嫌疑：内存溢出（OOM，Out-Of-Memory）、CPU 过载导致温度升高。
• 动作：
  1. 检查 dmesg 日志看是否有 oom-killer 记录。
  2. 检查系统指标监控（如 Prometheus + Grafana）在重启前的 CPU、内存、磁盘 IO、网络连接数曲线，是否是程序出现死循环或内存泄露。

第四阶段：无法启动到系统（系统盘损坏）的处理

如果服务器直接启动不了,会进入 GRUB Rescue 或者挂载失败：

1. 进入救援模式：
   • 物理机/虚拟机：使用系统安装盘 Live CD 启动。
   • 云服务器：控制台通常有“救援模式”或“VNC 登录”。
2. 挂载根分区：挂载系统盘到 /mnt。
3. 查看日志：在 /mnt/var/log/ 或 /mnt/var/log/messages 查看最后的日志。

排查 Checklist（按顺序）

1. 立即备份日志：/var/log/messages、/var/log/syslog、/var/log/kern.log、dmesg。
2. 查询硬件事件：ipmitool sel list（有 BMC 的话）。
3. 定位重启命令来源：last reboot | last -x（查看 runlevel 变化）。
4. 排除内存问题：检查 mcelog 或 dmesg。
5. 排除 OOM：检查 dmesg 或 journalctl 中是否有 oom-killer。
6. 排除定时任务：crontab -l 各用户及 /etc/crontab。
7. 检查应用日志：查看重启前 5-10 分钟的应用错误记录（通常是 Java OOM、数据库死锁、Nginx worker 崩溃等）。
8. 检查硬件温度（如果还能启动）：sensors 命令。

最终建议：如果多次出现不明原因重启，且日志中只有模糊的 Kernel panic - not syncing 而没有明确驱动报错，优先考虑更换内存条（内存错误症状最像“随机重启”）。