凌晨两点收到告警机器人狂轰乱炸的短信打开手机一看云服务器上的服务全挂了。登录控制台实例状态倒是运行中可 SSH 一进去uptime 显示系统刚启动三分钟nginx 进程一个都没有数据库也只剩半条命。你第一反应肯定是昨晚是不是异常断电了对于物理机这种问题看一眼机房配电柜就完了。但这是云服务器你连电源插头都摸不着更别说去看排插。好在 Linux 系统自己会把异常断电这件事记在好几个地方而且证据比物理机还清晰——内核日志、系统重启履历、文件系统状态甚至是云平台的事件记录都可能在替你留存现场。这篇文章就把我排查这类问题用的完整思路写下来。不管你手上是阿里云、腾讯云、华为云还是自建的 OpenStack 虚拟机这套方法基本通用。内容面向运维、后端开发以及所有手头有台服务器又怕它半夜出事的人。1. 内核日志的时间断崖异常断电留下的第一现场为什么会把看日志放在第一位因为正常关机和异常断电在系统日志里留下的形态是完全不同的。普通操作者不需要理解 systemd 的细节只要学会辨认正常收尾和突然断片的差别就已经能锁定 80% 的情况。1.1 正常关机时内核会留下什么日志一台 Linux 在收到正常的关机指令后会走一条非常标准的流程systemd 通知所有进程结束同步文件系统卸载各个挂载点关闭网络设备最后才真正切断电源。这个过程里的每一步都会往内核日志里写东西。正常关机时日志最后几行通常长这样Jan 14 03:47:01 myhost systemd-shutdown[1]: Sending SIGTERM to remaining processes... Jan 14 03:47:02 myhost systemd[1]: Unmounting /data. Jan 14 03:47:03 myhost systemd[1]: Unmounting /boot. Jan 14 03:47:05 myhost systemd[1]: All filesystems unmounted. Jan 14 03:47:05 myhost systemd[1]: Powering off.看到这类日志说明内核是被有礼貌地关掉的——先告诉所有人要下班了然后收拾东西、锁门、关灯。日志是收束的状态最后一句会明确落到 shutdown、poweroff 或 reboot 上。也就是说正常关机会给出一条完整的告别记录。而有异常断电时这条告别记录根本没有机会被执行内核日志会像一篇文章被撕掉了后半段。1.2 断电后的日志断崖长什么样异常断电的瞬间CPU 直接失去电源内核连一个字节的机会都没有。此时内核环形缓冲区里最后几条日志可能还没来得及写进磁盘所以你能看到的是已持久化的最后一条日志与重启后第一条日志之间出现一段明显的空白。举个例子断电前系统还在正常运行网络驱动可能是最后印出来的线索Jan 12 22:14:36 myhost kernel: 8021q: adding VLAN 0 to HW filter on device eth0然后戛然而止。下一次再有日志已经是 22:20:11 系统重新上电、内核开始引导时的输出。中间那 6 分钟左右的空白基本就是断电时段加上少量启动时间。这就是我常说的时间断崖——日志不是慢慢变少、一步一步降级而是直接硬切。只要你在/var/log/journal或/var/log/messages里找到这种硬切痕迹异常断电的概率就非常高了。这里要提醒一点dmesg本身读的是内核内存里的环形缓冲区断电重启后早期日志其实看不全真正可靠的是已经落盘的持久化日志。1.3 journalctl 怎么看上一次启动的结局systemd 环境的判断非常直接先用journalctl --list-boots列出历次启动记录journalctl --list-boots输出通常是这样的结构-1 31e2d9b... Jan 12 21:08:42 2024 Jan 12 22:14:36 2024 0 8ac7f34a... Jan 12 22:20:11 2024 now最后一行是当前启动倒数第一条-1是上一次启动。如果上一次启动的结束时间明显晚于它自己的启动时间并且和本次启动时间之间隔了一段距离那就是一个值得注意的信号。再看上一次启动的结尾journalctl -b -1 -e --no-pager | tail -30如果日志结尾停在某个普通内核消息上后面什么都没有也没有 Powering off、没有 reboot: Powering down、Reached target Unmount All File Systems 这类收尾行说明这个系统根本不是正常关机的。我习惯把这条命令放在整个排查流程的第一位因为它最快也最直观。哪怕只执行这一条都能给后续判断提供明确方向。2. last 命令里的关机履历从 wtmp 读出非正常关机日志有断崖算是一条线索但日志可能被轮转、被清空或者 journald 因为存储配置问题根本没留下上一次的记录。这时候就得看另一份记录/var/log/wtmp。2.1 reboot 和 shutdown 记录为什么重要Linux 有个专门记录用户登录、退出、系统重启和关机的二进制文件就是 wtmp。它不在文本日志里而是结构化的二进制数据普通cat读不了需要用last命令解析。正常关机时系统会在 wtmp 里写一条 shutdown 类型的记录正常重启时也会写一条 reboot 记录。关键就在这里这两条记录应该是成对出现的。一次完整、正常的重启会先写一条 shutdown 记录再写一条 reboot 记录。而异常断电时系统根本来不及写 shutdown 记录。等你重新开机wtmp 里只有一条 reboot 记录对应的 shutdown 记录缺失。这个特征非常清晰基本可以用是不是成对出现来快速判断。2.2 三条命令读出关停时间线我这几年排查最常用的就是下面三条last -x | head -40 last -x | grep -E shutdown|reboot who -blast -x会把系统事件翻出来重点看 shutdown 和 reboot。一次正常重启的输出大概是这样reboot system boot 6.1.0-18-amd64 Mon Jan 13 03:48 still running shutdown system down 6.1.0-18-amd64 Mon Jan 13 03:47 - Mon Jan 13你看到了吗先有 shutdown紧接着就有 reboot时间相差不过一分钟。而异常断电的情况通常只有孤零零一条reboot system boot 6.1.0-18-amd64 Sat Jan 12 22:20 still running没有对应的 shutdown 记录。这条 reboot 记录的时间就是断电后系统重新起来的时刻。who -b可以显示本次系统启动时间。uptime或者/proc/uptime则告诉你系统已经连续运行多久。如果 uptime 显示只有十几分钟而你上次登录是在几天前说明中间发生过一次重启接下来就该判断重启性质了。还有个细节容易被忽略wtmp 会被 logrotate 轮转。如果当前 wtmp 里看不到足够多的历史可以加上-f参数读历史文件last -f /var/log/wtmp.1 -x | head -402.3 最容易误判的情况人为重启与内核 panic不是说没有 shutdown 记录就一定是断电。系统也可能是因为内核 panic、硬件错误、云平台强制重启等原因而非正常重启。人为执行shutdown -r now或reboot是正常流程会留下 shutdown。真正容易混淆的是两类第一类是内核崩溃后自动重启。内核在 panic 后如果配置了panicN会自动重启此时的系统没有机会收尾日志也没有 shutdown 记录。但这种情况往往能在日志里找到 panic 关键字比如Kernel panic - not syncing、Oops、硬件报错等。第二类是云平台控制台里的强制重启。从操作系统视角看强制重启就是突然断电再上电几乎不可能在系统内部把它和物理断电区分开。遇到这种情况得去控制台事件里找操作记录。所以判断逻辑应该是日志断崖 无 shutdown 记录 没有 panic 痕迹这条线索才更接近异常断电。3. 文件系统的账本状态clean 标志如何指认异常关机如果说日志和 wtmp 都是文档型证据那文件系统这块就是实物证据。因为它不在软件层面而是直接写在磁盘的元数据里断电之后依然存在。3.1 ext4 superblock 里的 filesystem stateext4 文件系统在格式化时会有一块存储元数据的区域叫超级块superblock。里面有一个字段叫 filesystem state表示文件系统当前是干净状态还是脏状态。正常关机时内核会先同步文件系统数据然后把这个状态标记为clean相当于合上账本并写上已结清。这样下次挂载时内核就知道这个文件系统是干净的可以直接用。异常断电则完全来不及合账。磁盘上的标记就停留在not clean状态等系统再次开机挂载文件系统时内核会发现这个账本没结清从而执行日志重放把数据恢复到一致状态。这种机制很像你家楼下的便利店营业员每天关门前都会把账本合上锁进抽屉月底结账时一目了然。而停电时账本摊在桌上第二天开店第一件事就是先算清楚昨天的账。3.2 tune2fs 实操与取证时机查看 superblock 状态用tune2fs比如tune2fs -l /dev/vda1 | grep -iE Filesystem state|Mount count|Last mount|Last checked正常输出会是这样Filesystem state: clean Mount count: 23 Last checked: ...如果断电后系统还没有做过一次正常关机你看到的状态很可能是Filesystem state: not clean这就直接证明了上一次文件系统没有正常卸载。配合日志和 wtmp证据链基本就闭合了。但这里有一个关键时机会讲清楚如果系统断电后开机又经历了一次正常的 reboot文件系统会被再次标记为 clean之前不干净的证据就被覆盖了。所以这个命令的检测窗口其实是断电后的第一次启动这个阶段。那过了窗口怎么办看下一节。另外要确认磁盘设备名不要想当然写 /dev/vda1。先跑lsblk -f看看你的根分区和各个数据盘分别是什么设备、什么文件系统。有些实例的根分区位于 LVM 上路径可能类似/dev/mapper/centos-root设备名写错了什么也查不到。3.3 断电后首次挂载的 EXT4-fs recovery 信号相比 clean 标志日志重放的证据在时间上更持久。ext4 默认带 journal断电后文件系统处于 not clean 状态内核在挂载时其实会做一次日志回放recovery把未完成的事务恢复掉。而这个过程会写进本次启动的内核日志。排查命令dmesg -T | grep -i ext4 journalctl -b | grep -i ext4如果看到类似这样的输出EXT4-fs (vda2): recovery complete EXT4-fs (vda2): mounted filesystem with ordered data mode. Quota mode: none.第一行recovery complete就是证据上一次挂载是被突然打断的。这个信号通常只出现在断电或强制重启后的首次启动日志里。只要你没把日志清掉即使文件系统后来又正常重启过这条历史记录依然存在。对于非 ext4 的分区比如 XFS检修我先说一下思路不建议在运行中的系统上直接对根分区做检查风险太高。XFS 可以看内核日志里有没有recovery相关输出或者用xfs_repair -n只读检查给数据盘做诊断。但日常场景里云服务器数据盘最常见还是 ext4先把上面的排查方法吃透就已经能覆盖大多数情况了。4. 云监控断点、实例事件与 NTP 跳变三份旁证系统内部的证据再充足也只能证明这台机器不是正常关机的。至于断电到底发生在物理层面还是虚拟化层面就得借助云平台侧的信息了。反过来也一样如果你先在控制台看到异常事件再回到系统里验证效率会高很多。4.1 云服务器断电的物理真相云服务器不是插着电源线的物理机你的 Linux 运行在一个虚拟机里。真正的主机电源在物理宿主机上由虚拟化平台统一管理。云上异常断电通常有两种形态。第一种是宿主机本身出问题物理机器断电、宿主机内核崩溃、底层存储网络异常。此时虚拟机会一下子失去 CPU 和内存和直接拔电源没有任何区别。第二种是虚拟化层面强制干预比如热迁移失败、宿主机维护、资源调度异常导致虚拟机直接被强制停止。对你而言其实并不需要准确区分这两种因为它们在系统内留下的痕迹几乎一致日志断崖、没有 shutdown 记录、文件系统 not clean。你需要关注的是控制台记录里是否有一条非你发起的停止或重启事件。4.2 控制台事件与监控曲线的断崖归零几乎所有主流云平台都有事件或操作记录模块。打开控制台找到实例的操作记录事件中心或生命周期页签看断电时间点前后有没有以下类型的事件异常重启宿主机维护/迁移电源操作不同平台的叫法不同但基本都会记录谁在什么时间对实例做了什么操作。如果事件里显示这段时间有宿主机异常或自动重启那基本就是答案了。如果事件记录空空如也也别急看监控曲线。云平台的监控页面里CPU 使用率、内存使用率、网络出入带宽都会有历史曲线。正常关机会有一个负载逐步下降的过程曲线先下降后归零像一段缓坡。异常断电则是某个时间点数据直接消失曲线呈现断崖式归零没有任何过渡。如果你发现实例的 CPU、内存、网络三项指标在同一时间点同时归零并且之后又重新开始那基本可以确定这段时间实例处于断电状态。这里再留个心眼如果平台开启了自动恢复断电后实例可能被自动拉起但你并不知情这正是监控断点帮你识别出来的关键场景。4.3 时钟跳变与网络闪断的旁证作用断电期间虚拟机的时钟是停走的。恢复供电后系统刚起来的那几十秒里时间往往是不准的之后才通过 NTP 或 systemd-timesyncd 校准。这个大幅校时的过程会留下痕迹。journalctl -b | grep -iE chronyd|ntpd|systemd-timesyncd如果看到类似 System clock was off by 165345 seconds 或者 Step time 165345 的输出说明开机时系统时间与实际时间偏差很大而这种偏差往往就是因为机器停过一段不短的时间。注意这只能算旁证因为有些人手动改时间也会留下类似记录必须结合前面几条证据综合判断。网络闪断也可以顺带看一眼。如果业务日志里出现大量 TCP 连接超时、WebSocket 掉线、重连记录且时间集中在同一个时间点说明有大量进程在同一瞬间失去网络能力这与断电后统一恢复是吻合的。当然这条证据的效力更弱主要是帮你确定出事时间点而不是确定出事原因。5. 六条命令拼出完整证据链从筛查到定案线索都齐了现在把这些零散证据串起来。实际操作中我建议按固定顺序来30 秒先出初步结论再决定要不要深入查。5.1 30 秒快速筛查先跑这六条命令# 1. 系统已运行多久谁启动的 uptime who -b cat /proc/uptime # 2. 历次启动履历 journalctl --list-boots # 3. 上一次启动的最后日志 journalctl -b -1 -e --no-pager | tail -30 # 4. 历史关停记录 last -x | head -30 # 5. 文件系统是否干净卸载 lsblk -f tune2fs -l /dev/vda1 | grep -iE Filesystem state|Mount count # 6. 文件系统是否做过日志重放 dmesg -T | grep -iE ext4.*recovery|EXT4-fs.*clean这套命令跑完你大概已经能判断事件性质了。如果第 2 条的 boot 列表里上一次结束时间与本次开始时间有间隔第 3 条结尾没有收尾日志第 4 条只有 reboot 没有 shutdown第 5 条显示 not clean基本可以直接告诉客户或同事没有正常关机记录大概率断电或强制重启。5.2 证据权重表与交叉验证逻辑证据也有轻重之分不能单凭一条下结论。我平时用大概这样一张权重表证据来源检查方式权重说明内核日志断崖journalctl -b -1 -e高上一次启动无正常收尾日志关停记录缺失last -x高reboot 与 shutdown 不成对文件系统 not cleantune2fs -l高断电后首次启动时观察最佳recovery 日志dmesg / journalctl高文件系统执行过日志重放控制台异常事件云平台事件中心高宿主机异常或强制重启记录监控断崖归零云监控平台中CPU/内存/带宽同时归零NTP 大幅校时journalctl低仅辅助定位断点时间我的判断原则三条以上高权重证据命中基本可以定案两条高权重再加上监控断点或控制台事件也可以定案如果只有低权重证据我不会急着下结论会先去做故障复盘和继续观察。还有一种情况要特别提醒你在控制台看到有人执行了强制重启那从系统内排查出来的特征和断电完全一样。别因为在系统里看到了非正常迹象就一口咬定是异常断电有时候不过是有人手滑点了强制重启或者云平台自动恢复了故障实例。5.3 定案后的加固清单确认服务器确实发生过异常断电后不能只停留在查明白了这一步。断电最怕的不是系统重启而是数据不一致和业务中断时间过长。以下加固项是我每次操作完都会顺手做的把 journald 设为持久化存储。检查/etc/systemd/journald.conf里的Storagepersistent同时给SystemMaxUse设个几百兆的上限防止日志把磁盘撑爆。很多云镜像默认是 volatile重启后上一份 boot 日志直接蒸发。系统日志异地集中。配 rsyslog 或 syslog-ng 把关键日志发到远程日志服务器这样宿主机断电日志也不会丢。云平台自带日志服务的话直接用也行。数据库类的服务必须有高可用。异常断电之后单机数据库即使靠日志恢复也可能丢最近几秒的事务这是最容易被业务方追问的地方。提前做主从至少能保证一个可切换的副本。关键进程设置自动拉起。systemd 服务设置Restarton-failure容器服务设置restart: unless-stopped这样断电重启后服务能自愈一部分。定期检查文件系统健康。云服务器根分区一般不强制要求定期 fsck但数据盘还是建议在维护窗口跑一下避免磁盘因多次异常断电累积坏块。最后给云平台开好健康检查。很多公有云支持实例自动恢复把健康检查打开实例异常后平台能自动帮你把机器重新拉起来比我半夜爬起来手动开机靠谱得多。很多人查到这里就结束了但我还有一个习惯不管确认与否都会把这次排查的结论、支撑日志的截图、时间线整理成一页文档放到当时的故障记录里。下次如果再出现类似事件直接翻旧文档对照能省下至少一半时间。遇到拿不准的情况也别硬扛。云平台一般都有宿主机侧的证据用户自己在系统内看不到。直接工单把时间点发给客服让他们查一下宿主机电源事件和维护记录往往比你自己在系统里猜一整天还准。