Linux服务器重启记录排查：从last、uptime到journalctl的完整诊断指南

1. 从一次线上故障说起：为什么我们需要查看重启记录

那天下午，我正在处理一个线上服务的性能优化，突然接到告警，提示某台核心服务器的CPU使用率在几分钟内从平稳的20%飙升至90%以上，随后又迅速回落。登录服务器一看，uptime显示的系统运行时间只有不到10分钟。我心里咯噔一下：服务器重启了。是硬件故障？内核崩溃？还是运维同学误操作？在分布式系统里，一次非计划内的重启，背后可能隐藏着硬件老化、内核Bug、内存泄漏、甚至是安全入侵的痕迹。如果不能快速定位重启的原因和时间，排查工作就像在黑暗中摸索。

这就是掌握查看Linux重启历史记录这项“基本功”的价值所在。它不仅仅是执行一两条命令，而是系统管理员进行故障诊断、安全审计、性能分析和合规检查的起点。无论是排查半夜的莫名宕机，还是验证变更操作后的重启是否生效，亦或是追溯安全事件的时间线，清晰的重启日志都是最可靠的“时间证人”。对于运维、开发乃至任何需要与Linux服务器打交道的工程师来说，这都是必须烂熟于心的技能。

本文将带你深入Linux系统，不只看“怎么查”，更要弄明白“为什么能查到”、“记录存在哪里”以及“如何从这些记录里读出故事”。我们会从最常用的命令入手，逐步拆解其原理，并探讨在不同发行版和场景下的最佳实践，让你下次面对“服务器是不是重启过”这个问题时，能够自信、准确、全面地给出答案。

2. 核心命令深度解析：last与uptime的里里外外

提到查看重启记录，绝大部分资料和第一反应都是last命令。这个命令确实强大，但它显示的信息远不止重启。理解它的输出，是精准解读历史的第一步。

2.1last命令：不只是看重启

直接运行last，你会看到一长串列表，包含了所有用户的登录、注销记录。重启记录混杂其中，其典型特征是以reboot作为“用户名”，并且始终从系统启动（system boot）开始。

reboot system boot 5.4.0-42-generic Tue Aug 15 14:23 - 15:10 (00:47) reboot system boot 5.4.0-42-generic Mon Aug 14 03:15 - 14:23 (1+11:08) reboot system boot 5.4.0-40-generic Fri Aug 11 09:00 - 03:15 (2+18:15)

关键字段拆解：

• 第一列 (reboot): 表示这是一个系统重启事件。
• 第二列 (system boot): 表示事件类型为系统引导。
• 第三列 (内核版本):这是极其重要的信息，它告诉你这次重启后，系统是以哪个内核版本启动的。例如，从第三行到第二行，内核从5.4.0-40-generic升级到了5.4.0-42-generic，这很可能是一次计划内的系统更新重启。
• 时间范围:Tue Aug 15 14:23 - 15:10 (00:47)表示系统在8月15日14:23启动，并在15:10结束了该会话（即发生了下一次重启或关机），本次持续了47分钟。这个“结束时间”就是下一次重启发生的时间。因此，要查看最近一次重启是什么时候发生的，你需要看第一条reboot记录的开始时间（14:23）。

last命令的“数据仓库”：/var/log/wtmplast命令并非魔法，它读取的是一个特殊的二进制日志文件：/var/log/wtmp。这个文件由系统内核和登录服务（如login,sshd）共同维护，持续记录所有成功的登录、注销、重启和关机事件。它的二进制格式保证了高效存储和查询，但也意味着你不能直接用cat或vim查看其内容，必须通过last这类工具来解析。

注意：/var/log/wtmp文件会滚动。当它增长到一定大小时，会被重命名为wtmp.1，然后创建新的wtmp。更旧的日志会被依次重命名为wtmp.2,wtmp.3等，直到被删除。last命令默认只读取当前的wtmp，如果你想查看更早的历史，需要指定文件，如last -f /var/log/wtmp.1。

常用参数点睛：

• last reboot: 这是最直接的用法，只筛选出重启记录，让输出更清晰。
• last -x: 这个参数非常有用，它会额外显示runlevel changes（运行级别变更）和system shutdown（系统关机）事件。有时候服务器并非“重启”，而是先“关机”，再手动开机。last -x能帮你还原完整的过程。

  shutdown system down 5.4.0-42-generic Tue Aug 15 15:10 reboot system boot 5.4.0-42-generic Tue Aug 15 14:23 - 15:10 (00:47)

  上面这条记录结合-x参数就看到，在14:23重启后，系统在15:10被正常关闭了。
• last -n 5: 只显示最近5条记录，在日志很多时便于查看。
• last -F: 显示完整的日期和时间（年-月-日 时:分:秒），对于精确的时间线分析至关重要。

2.2uptime命令：系统稳定性的“体温计”

如果说last是查看历史病历，那么uptime就是测量当前体温。它的输出简洁明了：

15:20:30 up 1 day, 2:30, 3 users, load average: 0.08, 0.03, 0.01

• up 1 day, 2:30: 这直接告诉你系统自最后一次启动以来，已经连续运行了1天2小时30分钟。这是判断系统近期是否重启过的最快方法。如果这个时间很短（比如几分钟、几小时），那近期肯定有重启。
• load average: 三个负载均值（1分钟、5分钟、15分钟）。结合重启时间看负载，可以判断重启后服务的恢复情况。例如，重启后负载立刻飙升，可能意味着有开机自启动的服务异常；重启后负载一直很低，可能有些关键服务没起来。

uptime的数据来源：/proc/uptimeuptime命令的信息来源于/proc/uptime这个虚拟文件。这个文件里有两个数字：

123456.78 987654.32

• 第一个数字（123456.78）：系统自启动以来的总运行时间（秒）。
• 第二个数字（987654.32）：所有CPU核心的总空闲时间（秒）。这个值通常用于更深入的系统性能计算，uptime命令主要用第一个值。

/proc是内存文件系统，这里的值断电即失，这也印证了uptime只能反映本次启动后的时间。

实操心得：不要孤立地看uptime。我习惯将uptime与last reboot | head -1结合使用。先用uptime快速感知“系统跑了多久”，如果时间短，再用last reboot查看具体的重启时间点，并核对是否与预期的维护窗口一致。这是一种高效的“筛查-确认”工作流。

3. 进阶溯源：挖掘重启背后的“元凶”

知道了何时重启，接下来就是最关键的：为什么重启？这需要我们把目光投向Linux系统的“黑匣子”——系统日志。重启的原因通常就记录在这里面。

3.1 系统日志 (journalctl与/var/log/messages)

现代Linux发行版主要使用systemd作为初始化系统，其日志由journald管理，通过journalctl命令查看。

使用journalctl定位重启相关日志：

• 查看本次启动以来的所有日志：journalctl -b
• 查看上一次启动的日志：journalctl -b -1（-2代表上上次，以此类推）
• 查看特定时间段的日志：journalctl --since "2023-08-15 14:20" --until "2023-08-15 14:25"这对于锁定重启瞬间的日志非常有效。
• 查看内核日志（经常包含崩溃信息）：journalctl -k或journalctl -p kern。内核恐慌（Kernel Panic）、硬件错误（如CPU、内存）通常最先在这里体现。

在重启时间点附近搜索“罪证”：假设我们通过last reboot得知最近一次重启发生在2023-08-15 14:23。

1. 搜索关机/重启命令：journalctl --since “2023-08-15 14:00” --until “2023-08-15 14:30” | grep -E “(reboot|shutdown|poweroff|halt)”这可能会找到由root用户执行的shutdown -r now或reboot命令的记录。
2. 搜索系统服务异常：journalctl --since “2023-08-15 14:00” --until “2023-08-15 14:30” -p err查看该时间段内的所有错误级别日志。可能是某个关键服务（如数据库、存储服务）崩溃，触发了系统的异常行为。
3. 搜索硬件和内核信息：journalctl --since “2023-08-15 14:00” --until “2023-08-15 14:30” | grep -E “(panic|Oops|BUG|CPU|Memory|Hardware Error)”。这是诊断硬件故障或内核Bug的关键。

对于仍使用 SysVinit 或查看传统日志的系统：可以查看/var/log/messages、/var/log/syslog或/var/log/kern.log。使用grep配合时间戳进行过滤，思路与journalctl类似。

grep “Aug 15 14:2[0-5]” /var/log/messages | tail -50

3.2 谁动了我的服务器？lastb与安全审计

非计划重启有时与安全事件相关。攻击者获取权限后，可能会重启服务器以加载恶意的内核模块或清除痕迹。除了last，我们还需要关注失败的登录尝试。

• lastb命令：查看所有失败的登录尝试。它读取/var/log/btmp文件。在重启前后一段时间内，如果出现大量针对root或其他用户的失败登录记录，这可能是一次暴力破解尝试，需要提高警惕。
• last -x命令：再次强调，它可以帮你区分是reboot还是shutdown。一个攻击者更可能使用poweroff或halt命令，而不是reboot。

安全审计小技巧：我会将重启审计纳入日常安全检查清单。脚本大致逻辑如下：

1. 获取最近一次重启时间LAST_REBOOT_TIME。
2. 检查LAST_REBOOT_TIME前后各10分钟内的lastb记录和journalctl认证日志(journalctl _COMM=sshd)，统计失败次数和来源IP。
3. 检查是否有非root用户执行了sudo reboot或sudo shutdown（通过journalctl _COMM=sudo或/var/log/auth.log查看）。
4. 将异常结果（如非维护时段重启、伴随大量失败登录）标记为告警。

3.3 电源与硬件日志：被忽视的角落

如果系统日志里没有任何软件层面的异常记录，那就要怀疑硬件或电源问题了。

• 查看内核环缓冲区历史：dmesg -T可以显示带时间戳的内核消息。但dmesg缓冲区容量有限，重启后会丢失。更可靠的方法是查看journalctl -k。
• 检查硬件日志（如有）：对于服务器，尤其是品牌服务器（如Dell iDRAC, HP iLO, IBM IMM），它们有独立的硬件管理控制器，会记录更详细的硬件事件，如电源状态变化、温度超标、内存ECC错误等。这些日志需要通过特定的管理工具或Web界面查看，是诊断硬件引起无故重启的黄金标准。
• 查看ACPI事件：journalctl | grep -i acpi。系统因电源按钮按下、过热保护等引起的重启，可能会产生ACPI事件日志。

4. 实战场景与自动化运维脚本

理论说再多，不如实际操练一遍。下面我们通过几个真实场景，串联起上述命令，并分享如何用脚本实现自动化监控。

4.1 场景一：诊断一次莫名其妙的深夜重启

背景：监控显示一台数据库服务器在凌晨3点自动重启，导致业务中断。没有安排维护。

排查步骤：

1. 确认重启事实与时间：

   uptime # 查看运行时间，确认近期重启过 last reboot | head -5 # 确认具体的重启时间点，发现最近一次是 Aug 16 03:01

2. 聚焦重启瞬间的系统日志：

   journalctl --since “2023-08-16 02:55” --until “2023-08-16 03:05”

   在输出中，你可能会发现类似这样的关键行：

   Aug 16 03:00:45 db-server kernel: Out of memory: Kill process 12345 (mysqld) score xxx ... Aug 16 03:00:50 db-server kernel: systemd[1]: Started User Manager for UID 1000. Aug 16 03:01:02 db-server systemd[1]: systemd-update-utmp-runlevel.service: Succeeded.

   “Out of memory” (OOM) 赫然在目。系统因为内存耗尽，内核的OOM Killer被触发，杀死了最重要的mysqld进程。在某些系统配置下，关键服务崩溃可能导致系统进入不稳定状态，甚至触发自动重启（如果配置了kernel.panic_on_oops或kernel.panic参数）。

3. 深入挖掘：

   • 检查内存使用历史：如果配置了监控（如Prometheus），查看该时间段内存使用图表。
   • 检查数据库日志：/var/log/mysql/error.log，可能在OOM前就有慢查询或内存泄漏的迹象。
   • 检查系统配置：sysctl -a | grep panic，看是否配置了kernel.panic = 5（5秒后重启）之类的参数。

结论：根本原因是数据库内存泄漏或异常查询导致内存耗尽，触发OOM Killer，进而可能因系统配置导致重启。解决方案是优化数据库配置、增加内存或排查内存泄漏的代码。

4.2 场景二：验证计划内重启是否成功

背景：你通过自动化工具（如Ansible）对一批服务器执行了内核升级和重启指令。需要快速验证所有服务器是否都成功重启并进入了新内核。

验证脚本思路：

#!/bin/bash # check_reboot_status.sh TARGET_KERNEL="5.4.0-100-generic" # 期望升级到的内核版本 # 获取当前运行的内核版本 CURRENT_KERNEL=$(uname -r) # 获取最后一次重启的时间 LAST_REBOOT_TIME=$(last reboot | head -1 | awk ‘{print $5, $6, $7, $8}’) # 获取系统运行时间 UPTIME=$(uptime -p | cut -d ‘ ‘ -f2-) echo “服务器: $(hostname)” echo “当前内核: $CURRENT_KERNEL” echo “期望内核: $TARGET_KERNEL” echo “最近重启时间: $LAST_REBOOT_TIME” echo “本次运行时长: $UPTIME” if [[ “$CURRENT_KERNEL” == “$TARGET_KERNEL” ]]; then echo “状态: ✅ 内核升级成功” else echo “状态: ❌ 内核未升级成功，仍运行旧内核” fi # 如果运行时间小于10分钟，则认为是近期重启 if [[ $(echo “$UPTIME” | grep -oE ‘[0-9]+’ | head -1) -lt 10 ]] && [[ $(echo “$UPTIME” | grep -c ‘day’) -eq 0 ]] && [[ $(echo “$UPTIME” | grep -c ‘hour’) -eq 0 ]]; then echo “提示: 系统近期已重启（运行时间<$UPTIME）” else echo “提示: 系统运行时间较长，可能未按计划重启” fi

通过Ansible等工具在多台服务器上运行此脚本，可以快速生成一份清晰的验证报告。

4.3 自动化监控：非计划重启告警

对于生产环境，我们需要主动发现非计划重启。可以编写一个简单的监控脚本，定期检查并告警。

Zabbix Agent自定义监控项示例：

1. 创建监控项：监控系统运行时间。

   UserParameter=system.uptime.seconds,cat /proc/uptime | awk ‘{print $1}’

2. 在Zabbix Server端配置触发器：如果system.uptime.seconds在短时间内（如2个监控周期）急剧下降（例如从几万秒变成几百秒），则触发告警。

   表达式：{your_host:system.uptime.seconds.delta(5m)} < -300 含义：5分钟内运行时间减少超过300秒（5分钟），极有可能发生了重启。

简易Shell脚本监控示例：

#!/bin/bash # monitor_reboot.sh LOG_FILE=“/var/log/reboot_monitor.log” UPTIME_FILE=“/tmp/last_uptime.txt” current_uptime=$(cat /proc/uptime | awk ‘{print $1}’) last_uptime=$(cat $UPTIME_FILE 2>/dev/null || echo “0”) # 将当前运行时间写入文件，供下次比较 echo $current_uptime > $UPTIME_FILE if [[ $(echo “$last_uptime > $current_uptime” | bc) -eq 1 ]]; then # 如果上次记录的运行时间比当前大，说明发生了重启 reboot_time=$(date “+%Y-%m-%d %H:%M:%S”) echo “[$reboot_time] 检测到系统重启！当前运行时间: $current_uptime 秒” >> $LOG_FILE # 这里可以添加发送告警邮件的命令，例如： # echo “主机 $(hostname) 于 $reboot_time 发生重启！” | mail -s “非计划重启告警” admin@example.com # 或者调用Webhook fi

将此脚本加入crontab，每分钟执行一次。它通过比较前后两次记录的/proc/uptime值来判断是否发生了重启。这种方法比解析last命令更直接，延迟更低。

5. 疑难杂症与最佳实践

在实际操作中，你可能会遇到一些棘手的情况。这里分享几个常见问题和处理经验。

5.1 日志被清空或轮转了怎么办？

• /var/log/wtmp为空或很小：这可能是因为日志轮转策略激进（如logrotate配置为每天轮转并只保留1天），或者被人为清空（> /var/log/wtmp）。如果文件存在但last没输出，可以用file命令检查它是否是二进制格式，或者用last -f /var/log/wtmp强制指定文件。检查/var/log/wtmp.1,wtmp.2.gz等归档文件。
• journalctl看不到历史启动日志：默认情况下，journald将日志存储在/run/log/journal（内存中），重启即失。要持久化，需要创建/var/log/journal目录并设置正确的权限。检查/etc/systemd/journald.conf中的Storage=选项，确保其值为persistent或auto（且/var/log/journal存在）。
• 时间不对：所有日志分析的前提是系统时间准确。务必确保服务器已启用并正确同步NTP（使用chronyd或ntpd）。如果日志时间与真实时间有偏差，会给排查带来巨大困扰。

5.2 容器环境下的“重启”查看

在Docker容器或Kubernetes Pod中，情况有所不同。

• 容器内：容器内的进程通常看不到宿主机的重启历史。容器内的uptime显示的是容器进程的启动时间，而非宿主机。last命令在大多数基础镜像中不可用，因为容器内没有/var/log/wtmp文件。
• 正确姿势：要查看宿主机是否重启，以及重启对容器的影响，需要从宿主机层面或容器编排平台层面查看。
  • 宿主机：在宿主机上执行last reboot和journalctl。
  • Docker：docker events命令可以查看Docker守护进程的事件流，其中可能包含因宿主机重启导致的容器停止、启动事件。检查容器的重启策略：docker inspect <container_id> | grep -A 10 RestartPolicy。
  • Kubernetes：使用kubectl describe pod <pod-name>查看 Pod 的Events部分。如果节点重启，Pod会被重新调度，事件中会有NodeLost、Scheduled、Pulling、Started等一系列记录。使用kubectl get nodes查看节点的AGE，如果时间很短，可能重启过。

5.3 最佳实践总结

1. 日志持久化是第一要务：确保journald使用持久化存储，并合理配置logrotate以保留足够时长的wtmp、btmp、syslog等关键日志（建议至少30天）。
2. 时间同步是基石：部署可靠的NTP服务，这是所有日志分析具有可信度的前提。
3. 建立重启审计基线：明确所有服务器的计划维护窗口。任何非窗口期的重启都应视为异常事件，触发告警和排查流程。
4. 关联分析：不要只看重启记录。将重启时间点与监控系统（CPU、内存、磁盘、网络）、应用日志、数据库日志、安全日志进行关联分析，才能拼出完整的真相。
5. 善用自动化：像场景三那样，通过简单的脚本将重启监控纳入你的运维监控体系，变被动为主动。
6. 理解上下文：区分计划内重启（内核升级、硬件维护）和计划外重启（故障、攻击）。对于计划外重启，要形成标准的排查SOP（标准作业程序），按照日志类型逐层深入。

查看Linux重启历史，远不止是输入一个命令。它是一个从现象（系统运行时间短）出发，通过层层日志（last,uptime,journalctl）抽丝剥茧，最终定位到根本原因（OOM、内核Bug、硬件故障、人为操作）的完整侦探过程。掌握这套方法和工具链，你就能在服务器出现异常时，快速稳住阵脚，找到问题的源头。