服务器死机重启后怎么排查？从日志到硬件的实操流程

服务器毫无征兆地死机并自动重启，通常不是单一原因造成的。
多数情况下，问题出在电源不稳、内存故障、CPU 过热、磁盘掉线或内核 panic。
排查的核心思路是：先确认重启时间点，再按时间点去查系统日志和硬件状态，最后做针对性验证。

先确认重启时间，拿到排查起点

登录服务器后，第一步不是直接翻日志，而是搞清楚它到底重启过几次、最近一次是什么时候。

last reboot | head

last reboot 会列出历史重启记录，head 只看最近的几条。
输出里有重启时间和持续时长，如果发现同一天多次重启，说明问题可能是持续性的，而不是偶发。

接着确认当前开机时长：

uptime -p

如果显示“up 3 minutes”，说明刚重启不久，适合立刻抓现场。
如果已经运行很久，就要靠日志回溯。

用 journalctl 定位上一次开机的异常结尾

systemd 系统上，journalctl 是最直接的入口。
默认它只显示本次开机日志，要看上一次死机前的记录，必须加 -b -1：

journalctl -b -1 -p err

-b -1 表示上一次启动，-p err 只显示 error 及以上级别。
重点看最后几行，常见可疑信号包括：

• Out of memory: Killed process：内存耗尽，OOM 杀进程，严重时可能拖死系统。
• kernel panic 或 BUG: unable to handle：内核崩溃，通常和驱动、内存或硬件有关。
• I/O error 或 ata bus error：磁盘或 SATA 链路异常。
• mce: Hardware Error：机器检查异常，偏向 CPU 或内存硬件问题。

如果 -b -1 提示没有记录，说明日志没有持久化保存。
可以检查 /var/log/journal 是否存在，没有的话日志只存在内存里，重启就丢了。
后续建议开启持久化，避免下次又抓不到现场。

检查 dmesg 和温度，区分软件与硬件

journalctl 看的是系统级事件，dmesg 更适合看内核在启动和运行期间的硬件信息。
重启后执行：

dmesg -T | tail -50

-T 把时间戳转成可读格式。
重点找 error、fail、reset、timeout 这类词。

温度也是死机常见原因。
用 sensors 查看 CPU 和主板温度：

sensors

如果没装，Debian/Ubuntu 用 apt install lm-sensors，CentOS 用 yum install lm_sensors。
温度长期高于 85°C 就要检查风扇和散热硅脂。

内存方面，先看 free -h 确认当前内存是否吃紧。
怀疑内存条故障时，可以在维护窗口用 memtester 做一轮测试：

memtester 1G 1

这会测试 1GB 内存一轮，适合快速验证。
完整测试需要停机用 memtest86+，时间更长但更准确。

磁盘和电源的检查不能跳过

磁盘故障经常表现为“系统卡死然后重启”。
先用 smartctl 看健康状态：

smartctl -H /dev/sda

如果输出 PASSED 只代表当前没触发阈值，还要看具体属性：

smartctl -A /dev/sda | grep -Ei 'reallocated|pending|uncorrect'

Reallocated_Sector_Ct、Current_Pending_Sector、Offline_Uncorrectable 这三个值不为 0 就要警惕，磁盘可能在退化。

电源问题在软件层很难直接看到，但有几个间接信号：同一机柜其他机器也重启、重启时间集中在用电高峰、dmesg 里出现电压相关警告。
遇到这类情况，先换电源线或插排，再考虑更换电源模块。

避坑：这些做法会让排查更难

• 不要一重启就急着恢复业务。先把 journalctl -b -1 和 dmesg 的输出保存下来，否则日志被覆盖后很难回溯。
• 不要只看应用日志。应用报错往往是结果不是原因，内核层的信息才是根因线索。
• 不要忽略时间同步。如果服务器时间不准，日志时间线会错乱，排查时容易误判。用 timedatectl 确认 NTP 正常。
• 不要在没备份的情况下直接跑内存测试或磁盘修复。fsck 和 memtester 都有一定风险，尽量在维护窗口做。

验证是否真正解决

排查完成后，需要观察一段时间确认不再复发。
建议：

1. 开启日志持久化，确保下次死机有记录可查。
2. 用 uptime 和 last reboot 定期检查是否还有异常重启。
3. 如果是硬件问题，更换部件后至少观察 24 到 48 小时。
4. 如果是 OOM 导致，调整应用内存限制或增加 swap，并持续监控 free -h。

如果做完以上步骤仍然反复重启，且日志里没有明确软件错误，优先怀疑电源、内存或主板。
这类问题在软件层往往查不到根因，需要联系机房或硬件服务商做替换测试。