linux服务器异常重启排查步骤

摘自chatgpt plus

这种“机器异常重启”的排查，本质上就是回答三个问题：
是谁触发的重启？（人为 / 系统 / 内核 / 硬件） → 为什么触发？ → 是否可复现？

我给你一套从快到慢、从表到里的排查方案，适合你这种运维场景（你有K8s、监控、服务器经验，这套可以直接实战用）。

🧭 一、第一步：确认“重启类型”（非常关键）

先搞清楚是不是“正常重启”还是“崩溃重启”。

1️⃣ 查看重启历史

1	last -x \| grep reboot

看几点：

是否有 shutdown → 正常关机
直接 reboot → 可能异常
时间是否规律（比如每天凌晨）→ 定时任务

2️⃣ 看 uptime 是否异常

1 2	uptime who -b

👉 判断逻辑

现象	初步判断
有 shutdown 记录	人为/系统操作
没有 shutdown	异常崩溃
时间固定	定时任务
无规律	硬件 / 内核

📜 二、核心日志排查（最重要）

1️⃣ 系统日志（首查）

CentOS

1	/var/log/messages

Ubuntu

1	/var/log/syslog

👉 查重启前几分钟：

1	grep -i "error\\|fail\\|panic\\|reboot" /var/log/messages

或：

1	journalctl -xe --since "10 minutes ago"

2️⃣ journalctl（强烈建议）

1	journalctl -b -1

👉 看“上一次启动前的日志”

重点关键词：

kernel panic
oom-killer
segfault
hardware error
watchdog

3️⃣ 内核日志（关键）

dmesg -T

或者：

1	journalctl -k -b -1

重点看：

kernel panic
soft lockup
watchdog timeout
CPU hang

💥 三、重点排查几个“高频原因”

🔥 1️⃣ OOM（内存溢出）

非常常见（尤其你跑K8s）

1 2	grep -i "oom" /var/log/messages journalctl -k \| grep -i oom

典型日志：

1	Out of memory: Kill process xxxx

👉 说明：

进程被杀 → 系统可能不稳定 → 重启

🧠 2️⃣ Kernel Panic（内核崩溃）

1	grep -i "panic" /var/log/messages

或者：

1	journalctl -k -b -1 \| grep -i panic

👉 常见原因：

驱动问题
内核bug
硬件异常

⚡ 3️⃣ 硬件问题（非常关键）

如果你发现日志啥都没有直接重启，优先怀疑这个。

查看：

1	dmesg \| grep -i error

1	journalctl \| grep -i mce

👉 关键词：

Machine Check Exception (MCE)
ECC error
CPU error
memory error

🔌 4️⃣ 电源问题（云/机房常见）

特征：

日志断层
没有任何错误
直接 reboot

👉 判断：

last -x

如果：

没有 crash / panic / shutdown
👉 基本是断电 / 宿主机问题

⏰ 5️⃣ 定时任务 / 人为操作

1
2
3

crontab -l
cat /etc/crontab
ls /etc/cron.*

以及：

1	history \| grep reboot

🐳 6️⃣ K8s / 容器导致

你这个环境要特别注意：

1	kubectl get events --sort-by=.lastTimestamp

1	docker ps -a

👉 看：

是否节点 NotReady
kubelet 是否重启

🐶 7️⃣ Watchdog（自动重启机制）

1	grep -i watchdog /var/log/messages

👉 有些系统：

卡死 → watchdog 自动重启

🧪 四、进阶排查（你这种水平建议做）

1️⃣ 检查是否启用 crash dump

1	systemctl status kdump

如果有：

1	ls /var/crash/

👉 可以分析 vmcore（高级玩法）

2️⃣ 查看登录和操作记录

1 2	last lastlog

3️⃣ 查看服务异常

1	systemctl --failed

🧰 五、我给你一套“标准排查流程”（实战用）

直接照这个走👇

✅ Step 1：确认时间

1	last -x \| head

✅ Step 2：看上一次启动日志

1	journalctl -b -1

✅ Step 3：快速筛关键错误

1	journalctl -b -1 \| egrep -i "panic\|oom\|error\|fail\|watchdog"

✅ Step 4：看内核

1	journalctl -k -b -1

✅ Step 5：查OOM

1	grep -i oom /var/log/messages

✅ Step 6：查硬件

1	dmesg -T \| grep -i error

✅ Step 7：查人为

1 2	history \| grep reboot crontab -l

🧠 六、经验总结（很关键）

我直接给你“快速判断口诀”：

👉 有日志 = 软件问题
👉 没日志 = 硬件/电源问题

🚀 七、如果你要更专业（推荐）

你可以加这些监控：

Prometheus + Alertmanager（你已经在用 👍）
node_exporter 监控：
- 内存
- load
- CPU
开启：

1 2	kernel.panic = 10 kernel.panic_on_oops = 1

👉 如果你愿意

你可以把：

journalctl -b -1 输出
或 /var/log/messages 关键段

贴给我，我可以帮你直接定位到具体原因（比如是OOM还是内核bug） 👍