凌晨三点手机连续震了十几下监控大屏上飘红实例发生重启。登录这台 Linux 云服务器一看系统正常运行dmesg 没刷出明显报错服务也能起来——可越是这样越让人心里发毛。它为什么重启是有人动了 hand是内核崩了还是最让人头疼的异常断电在云服务器场景里判断系统是否发生过异常断电不只是为了写故障报告它直接决定你后续排查方向。如果是底层宿主机物理宕机那是云平台的责任边界如果是系统自身问题就得顺着内核日志和文件系统查下去。这篇文章我把实际排查里会用到的判断思路、具体命令和容易踩的坑完整梳理一遍。1. 先搞明白场景云服务器上的异常断电到底是什么1.1 云服务器断电和物理机断电不能完全画等号很多人想当然地把云服务器的异常断电等同于物理机拔电源二者表象相似但本质并不一样。云服务器是跑在宿主机上的虚拟机所谓异常断电在云环境里通常有几种形态宿主机物理宕机、宿主机被强制重启、虚拟化层崩溃导致虚拟机瞬间失去响应以及云盘 IO 链路中断导致系统像断电一样卡死。比物理机少了一层电源管理却多了一层虚拟化控制。物理机断电时主板和 BIOS 会留下电源状态记录服务器运维可以进 IPMI/BMC 查询但云服务器没有这类底层入口你能依赖的只有操作系统内部留下的日志和文件系统状态。更关键的是断电瞬间内存里的数据会全部丢失未写入磁盘的页缓存、正在写的文件、正在提交的事务都可能被硬生生截断。对于数据库这种依赖 WAL 日志的还好说对于普通应用可能表现为文件内容写了一半、Redis 快照损坏、Nginx 缓存目录出现残留临时文件。1.2 为什么必须把“异常断电”从各种重启里摘出来生产环境遇到重启运维的第一反应绝不能是“重启完就完事”。不同重启原因对应的责任边界和处理方式差别很大正常计划内重启有维护通知日志完整有据可查基本不用深挖。内核 panic 导致的自恢复属于系统自身问题需要分析 kdump 和内核日志。云厂商主动迁移或宿主机维护控制台会留有工单记录事实清楚。异常断电既无计划通知也缺少正常关机流程往往伴随数据损坏风险需要系统检查。如果判断为异常断电下一步自然会去检查文件系统、去云平台提工单查宿主机状态、评估是否需要搭建高可用架构。如果判断错了你可能在一个根本不存在的“底层故障”上做无用功甚至把人为重启的锅甩给云厂商。可以说这个判断是整个故障排查的分岔口方向错了后面全白费。2. 系统日志里的“时间断层”异常断电的第一现场2.1 journalctl --list-boots从启动记录里找空窗systemd 系统会把每次启动的日志以 boot session 为单位存档journalctl --list-boots直接列出当前机器所有启动周期。异常断电时上一次启动的日志没有正常关机收尾boot 条目会表现出两个特征一是这个 session 的日志时间段很短二是相邻两个 boot 的间隔明显大于任何已知维护窗口。我举个例子。某次接到客户反馈实例异常执行journalctl --list-boots输出类似-7 8d77655c1f5d4c11b9c81b1f4d8e7e01 Thu 2024-11-07 09:12:33 CST—Thu 2024-11-07 09:14:02 CST -6 6d9cbe3757f04c2c8d2c991e3d0d9d13 Thu 2024-11-07 09:20:42 CST—Fri 2024-11-08 14:22:31 CST第 -6 个 boot 在 11 月 7 日 09:20 开始正常情况下应该持续运行但日志到 11 月 8 日 14:22 戛然而止下一个 boot 在 15:40 才开始。从 14:22 到 15:40 这一个多小时的日志空白就是断电或者崩溃的时间窗。注意正常关机时 systemd 会刷出大量 Stopping、Unmounting、Powering off 日志异常断电时这些收尾日志是缺失的日志往往在一句话写到一半就断了这种“断在半路”的观感比任何字段都直观。2.2 uptime、who -b、last reboot 三方交叉验证只看 journalctl 还不够我会用另外三个命令做交叉验证。uptime -s显示本次系统启动时间who -b同样是系统启动时间last reboot则从 /var/log/wtmp 里列出历史重启记录。三个来源彼此独立如果输出基本一致时间戳就可信。实际操作时先执行uptime -s得到“2024-11-08 15:40:12”马上对比journalctl --list-boots里最新 boot 的开始时间能对得上说明这个 boot 就是当前这次。然后执行last reboot能看到类似reboot system boot 5.10.0-60.18.0 Fri Nov 8 15:40 still running reboot system boot 5.10.0-60.18.0 Thu Nov 7 09:20 - 14:22关键就在第二行系统 11 月 7 日 09:20 启动后直到 11 月 8 日 14:22 重启中间没有任何 shutdown 记录。再配合tail -n 100 /var/log/messages或journalctl -e看到最后一行还是业务日志、没有“sysinit shutdown”之类的记录结论倾向于异常断电或非法重启。2.3 别漏了内核 panic 和硬件错误信号异常断电之外还有一种常见恶疾是内核 panic 后自行重启。遇到这种情况第一反应不能直接扣在“断电”头上。先在journalctl -k里搜索 panic、Oops、BUG、watchdogjournalctl -k | grep -iEB2 panic|oops|BUG|watchdog | tail -n 100如果搜出明确的 panic 栈信息或者 /var/crash 目录下存在 kdump 生成的 vmcore 文件那是内核崩溃而非断电。排查重点要转向驱动、内核参数、最近更新补丁而不是找云厂商扯宿主机断电。还要留意一种情况dmesg 里出现大量blk_update_request、virtio-blkIO error这种往往是底层存储链路抖动或热迁移时的短暂 IO 隔离表现上像断电但本质是存储链路问题。这种痕迹要单独记录提工单时是重要佐证。3. 文件系统断电留下的“伤疤”最诚实3.1 重启后 fsck 痕迹这不是偶然是证据ext4 文件系统如果在上次挂载时没有被正常卸载超级块里的 state 会标记为“unclean”。下次挂载时内核要么自动做只读挂载要么在启动早期强制跑 fsck。磁盘越大、文件越多这个检查越耗时表现为“启动卡在 fsck 几分钟”。通过dmesg | grep -i fsck\|ext4能看到[ 2.473156] EXT4-fs (vda1): recovery complete [ 2.583116] EXT4-fs (vda1): mounted filesystem with ordered data mode. Quota mode: disabled.recovery complete这个关键词说明文件系统在挂载时执行了日志恢复动作也就是上次没有干净卸载。XFS 文件系统也会有类似机制异常断电后挂载阶段会出现 log replay对应的 dmesg 内容可能包含xfs_log_mount信息。注意很多云服务器的数据盘是云硬盘本质是分布式存储断电时可能表现为“文件系统没有明显异常”或“只读挂载”因为底层集群有冗余副本。这时候不能因为 fsck 痕迹不明显就排除断电要结合系统日志看。3.2 用 tune2fs 和 dumpe2fs 核实文件系统状态要拿到更硬核的证明可以直接读文件系统超级块。对 ext4 文件系统执行tune2fs -l /dev/vda1输出里重点看几个字段Mount count已挂载的次数。Maximum mount count达到这个上限后会强制 fsck默认可能设为 -1不限制但很多发行版会设成一个数值。Last checked上次完整 fsck 时间。State文件系统状态clean 表示干净卸载not clean 表示有错误或未干净卸载。如果说State: clean而系统日志又有明显断档那就说明文件系统层侥幸没留伤疤不能排除断电。反过来如果State为 not clean、Last checked是系统启动之后的时间说明 fsck 跑过那就要高度怀疑异常断电或强制重启。xfs 系统用xfs_info和xfs_repair -n做类似检查。需要提醒的是这两类工具都应该在文件系统卸载状态下做只读检查生产环境直接挂在线上跑fsck有风险一般交给系统启动流程或维护窗口处理。3.3 数据库和应用层的“断电后遗症”是旁证如果实例上跑着数据库断电留下的痕迹更多。MySQL 异常断电后再次启动日志中会大量出现“recovering”和“InnoDB: Starting crash recovery”的字样PostgreSQL 会执行 WAL 回放日志里出现redo相关输出Redis 开启 AOF 持久化时断电可能导致 AOF 截断启动时 Redis 会自动处理截断的 AOF 文件并在日志中提示。这些恢复流程都是“上次非正常结束”的旁证。我自己排查时通常先看系统日志再看数据库日志——两者互相佐证基本能把结论钉死。4. 云服务器特有的判断视角和实操组合4.1 云平台控制台、监控事件和串口日志云服务器有个天然优势云厂商控制台会记录几乎所有操作和底层事件。排查时先把控制台打开重点看三块实例监控如果 CPU、内存、IO 突然全部跌零随后实例重启时间点与本地日志断档吻合基本就是底层异常。事件记录/操作日志阿里云、腾讯云、华为云这类主流平台都会有实例生命周期事件和操作审计。异常断电往往对应“实例重启动”或“宿主机故障”事件如果有“维护”“迁移”通知那大概率不是断电。VNC 控制台或串口日志很多平台提供远程终端日志可以看到实例重启过程中的完整输出。断电场景下串口日志通常在某个系统输出处直接断掉然后是一段空白直到下次引导开始中间这段空白就是断电持续时间。我在工单里见过最典型的串口日志内核输出停在某个驱动加载处没有 panic 栈没有任何 shutdown 字样紧接着过了几分钟开始重新加载引导程序这一切配合控制台的“宿主机故障”事件结论一目了然。4.2 一条龙排查命令组合实践中我把判断命令整理成一组按顺序执行基本能形成完整结论echo 1. 当前实例启动时间 uptime -s who -b echo 2. 历史重启/关机记录 last -x reboot shutdown echo 3. 系统历次启动 session journalctl --list-boots echo 4. 最近一次日志落盘时间 journalctl -e | tail -n 30 echo 5. 内核错误与 panic 排查 journalctl -k | grep -iEB2 panic|oops|BUG|watchdog | tail -n 100 echo 6. 文件系统检查痕迹 dmesg | grep -i fsck\|ext4\|xfs echo 7. 文件系统超级块状态 tune2fs -l /dev/vda1 2/dev/null | head -n 20这套命令跑完把输出对照前面说过的特征归纳有没有日志断档、有没有 panic 栈、有没有 fsck 痕迹、控制台事件是什么。不一定每个字段都有但只要有两三个维度同时指向“非正常结束”就可以给异常断电定性。4.3 怎么排除云厂商主动维护和人为重启云厂商做底层升级或宿主机热迁移通常要么不重启要么提前有站内信/短信通知。如果日志里出现了ACPI Power Button、systemd-shutdown[1]: Powering off、Reached target Shutdown这类内容说明是受控关机流程属于正常重启。异常断电时这些收尾流程一条都不会有。人为重启同样可能在日志里留下痕迹。last -x能看到用户来源journalctl | grep -i reboot\|shutdown能找到对应的 systemd 操作记录云平台控制台的“操作记录”里更可能直接显示是阿里云账号 A 还是哪个子用户在控制台点了重启。排查前先问一圈同事再看操作审计能避免把自己绕进去。5. 常见误判和排查技巧实录5.1 最常见的三个误判场景误判一把内核 panic 当断电。有一次排查日志断档前出现了一长串 NULL pointer dereference/var/crash 里躺着 vmcore。虽然表象像断电但本质是内核崩溃。如果按断电方向排查找云厂商要宿主机日志完全没用最后发现是某次内核更新引入的 bug。误判二把人为 shutdown 当断电。开发同学在服务器上执行过 reboot却没人报备。日志里有完整的 systemd 关机流程控制台操作记录也有登录痕迹。一开始当断电查浪费了一下午最后翻到操作审计才破案。误判三把云厂商维护重启当断电。某云平台凌晨做宿主机升级发了通知但邮件进了垃圾箱。重启时间点和本地日志断档都对得上如果不核对通知很容易误判成断电白白提交一个无效工单。5.2 判断速查表现象倾向判断核实方法日志在业务信息中戛然而止无任何关机收尾异常断电或非正常重启journalctl --list-boots last reboot存在 panic/Oops/var/crash 有转储文件内核崩溃kdump 分析、journalctl -k出现 ACPI Power Button、Powering off 等收尾日志正常关机重启查看操作记录、维护通知控制台存在维护事件或迁移通知云厂商主动运维站内信、工单记录重启后 dmesg 出现 fsck recovery 或日志回放强制重启后遗症tune2fs -l / xfs_info日志盘是内存 tmpfs断电后无痕迹无法在本地判断配合云监控和远端日志5.3 几个可以提前布防的预防措施判断异常断电的前提是“有日志可看”。很多云服务器默认的 journald 存储配额有限甚至有的系统把日志放在内存 tmpfs 里一旦断电重启上一段日志直接灰飞烟灭断案直接断到死胡同。提前做三件事第一修改/etc/systemd/journald.conf把Storagepersistent打开确保日志落盘第二把系统日志和应用日志实时转发到云平台日志服务或自建日志服务器第三在云监控里配置“实例重启事件”告警这样重启触发的第一时间就能留痕不用等事后分析。对于核心业务系统建议启用 kdump预留 /var/crash 空间这样内核崩溃时会自动留下转储文件后续分析事半功倍。最后说点掏心窝的经验。判断异常断电没有单项铁证靠的是“时间断层 文件系统痕迹 云平台事件”三个维度交叉验证。我踩过最深的坑是只看 journalctl 就下结论结果忽略了人为重启的操作记录。另一个小技巧平时就把 journald 的持久化打开日志别只存在内存里否则真到了断电那天你连证明“它断过电”的证据都拿不出来。先把系统退路留好再谈判断和复盘。
