Ubuntu 服务器重启时间查询指南：运维排查必备的5种方法

做运维久了，你一定遇到过类似的场景。某天一大早，或者更糟，是半夜，监控突然报警。服务掉了，负载没了，容器全没影了。排查的第一步，往往就是确认一个问题：服务器最近重启过吗？

如果你连服务器上一次是什么时候重启的都说不清楚，后续的故障排查基本就只能靠猜，甚至陷入无谓的争论。因此，准确、快速地获取服务器重启时间，是每一位系统管理员都应掌握的基础技能。

本文将系统性地梳理在Ubuntu系统中查询重启时间的多种方法，从快速判断到深度分析，并阐述它们各自的适用场景和底层原理。

为什么查询重启时间至关重要

看似基础的操作，在实际运维工作中却价值千金：

1. 故障排查的起点：服务异常时，首先要区分是应用问题还是系统层面问题。如果服务器刚刚重启过，排查重心应立即转向内核、OOM（内存溢出）、宿主机或云平台事件，而非业务代码。
2. 厘清变更与责任：确认重启是否发生在计划变更窗口内，是否有未经记录的手动操作。一句“系统于凌晨03:14重启”往往能终结许多争论，明确时间线。
3. 识别风险信号：非预期的、频繁的重启通常是系统存在稳定性或安全隐患的强烈信号，需要立即深入调查。

方法一：快速状态感知 - uptime 命令

如果只想快速确认服务器是否近期重启过，uptime 命令是最直接的选择。

uptime

输出示例：
10:15:30 up 28 days,  7:42,  1 user,  load average: 0.08, 0.03, 0.01

关键信息在 up 28 days, 7:42，表示系统已持续运行28天7小时42分钟。你可以据此反推上次重启的大概时间。

适用场景：初次登录陌生服务器时快速感知其运行状态，或在排查初期进行粗略判断。缺点是无法提供精确的时间点。

方法二：精确时间查询 - who -b 命令（推荐）

在日常 Linux 运维 工作中，若需一个精确到分钟且输出简洁的命令，who -b 是首选。

who -b

输出示例：
system boot  2025-11-24 10:50

它直接给出系统上一次启动的精确时间（年-月-日 时:分），格式干净，非常适合截图用于报告或沟通。该命令读取系统的登录记录文件，在正常的生产环境中非常可靠。

方法三：查看重启历史 - last reboot 命令

当需要了解服务器是否频繁重启，或查看历次重启记录时，last reboot 命令不可或缺。

last reboot

输出示例会列出每次重启的时间点、当时使用的内核版本以及该次启动的持续时间。这对于事故复盘、关联特定内核版本的问题或分析系统稳定性趋势极具价值。

方法四：关联日志与原因 - journalctl 命令（Systemd 系统）

对于使用systemd的现代Ubuntu系统（16.04及以后），journalctl 命令的强大之处在于能将重启时间与重启原因关联分析。

首先，列出所有的启动记录：

journalctl --list-boots

输出会为每次启动分配一个索引（如 -1 代表上一次启动，0 代表当前启动），并显示起止时间。

接着，可以查看特定启动周期内的全部日志，例如查看上一次启动的日志：

journalctl -b -1

通过分析这些日志，你有可能找到导致重启的根本原因，如硬件错误、内核崩溃或OOM Killer介入等，这是深度 系统日志分析 的关键步骤。

方法五：脚本与底层查询 - /proc/stat 文件

在某些特殊环境（如最小化安装）或编写自动化脚本时，你可能需要一种不依赖外部命令、直接从内核获取信息的方式。

cat /proc/stat | grep btime

输出示例：btime 1763952631

这里的 btime 值是一个Unix时间戳，表示内核启动的时间。你可以使用 date 命令将其转换为可读格式：

date -d @1763952631

这种方法极为底层和直接，非常适合集成到监控脚本或诊断工具中。

实践总结与建议

• 快速确认：使用 who -b，获取精确时间。
• 查看历史：使用 last reboot，分析重启频率。
• 深究原因：使用 journalctl，关联日志事件。
• 脚本自动化：使用 /proc/stat，稳定可靠。

一个重要的运维习惯是：在启动任何复杂的应用日志排查之前，先确认服务器是否发生过重启。 这能帮助你快速修正排查方向，避免在错误路径上浪费时间。

运维工作的核心之一，是理解系统在运行过程中留下的各种“痕迹”。服务器不会主动开口解释，但它所记录的时间戳、日志条目和状态信息，正是我们洞察其行为的关键。熟练掌握这些查询方法，能让你在团队中更高效、更专业地应对各种系统事件。