当服务器突然“躺平”

各位程序员老铁们，有没有经历过这样的绝望瞬间——正喝着肥宅快乐水敲代码，突然服务器给你表演一个“当场去世”，监控群瞬间炸锅，老板的夺命连环Call比外卖小哥还准时？别慌！今天咱就用“法医式”排查法，带你把死机服务器的底裤（划掉）日志扒个干干净净！

第一招：SSH连不上？先来个体温检测（Ping & 端口探测）

症状描述：远程连接直接“无响应”，像极了女朋友冷战时的微信界面。

专业操作+举例：

1. Ping一下试试（网络层心跳检测）：

```bash

ping 192.168.1.100

```

*如果丢包率100%，可能是网络抽风或服务器真·休克。*

举个栗子🌰：某次我Ping不通，结果发现是机房大妈打扫时一脚踢掉了网线……

2. Telnet/NC探测端口（应用层敲门）：

telnet 192.168.1.100 22

测SSH端口

nc -zv 192.168.1.100 80

测Web服务

*连22端口都不理你？大概率是系统卡死或内核panic了。*

第二招：物理机还是云主机？区别对待！

- 物理服务器：直接冲机房！检查电源灯是否在跳“老年迪斯科”（闪烁），硬盘灯是否常亮（可能I/O卡死）。

- 云服务器：控制台走起！用VNC/Serial Console功能强行“破门而入”。

真实案例：某云厂商控制台显示实例状态“运行中”，但VNC看到的是黑屏——原来是内核崩溃后卡在Grub菜单…

第三招：日志大法好，凶手就在/var/log里！

服务器死机前的“遗言”全藏在日志里，重点查这些文件：

1. /var/log/messages（系统级吐槽大会）：

grep -i "error\|panic\|oom" /var/log/messages

2. dmesg（内核的临终呐喊）：

dmesg -T | tail -n 50

看最近50条内核日志

*常见死因举例*：

- `Kernel panic - not syncing` → 内核级车祸现场

- `Out of memory` → 内存被MySQL吃干抹净

第四招：资源谋杀案？TOP命令当柯南

如果还能挣扎着连上SSH，立马敲`top`：

1. CPU列：某个进程占满100%？可能是写了个死循环的Python脚本…（别问我怎么知道的）

2. MEM列：`free -h`看一眼剩余内存，要是Swap都用光了，OOM Killer可能已经挥刀了。

第五招：高级法医——Crash Dump解剖术

对于反复猝死的服务器，需要上硬核工具：

1. 配置kdump（提前准备）：

在/etc/kdump.conf里设置崩溃转储路径，下次死机自动保存内存快照。

2. 分析vmcore文件：用`crash`工具像读X光片一样看崩溃瞬间的内存状态。

防死机彩蛋：运维老司机的保命习惯

1. 监控报警三件套：Prometheus+Grafana+企业微信，比女朋友更早发现异常。

2. **定时重启玄学*

TAG:服务器死机怎么查看,服务器死机原因,服务器 死机,服务器死机叫什么,服务器电脑死机,服务器死机名词