查看服务器重启记录是运维工作中排查故障、审计安全和追溯系统异常的核心环节，无论是Linux还是Windows系统，核心上文归纳在于：通过系统自带的日志分析工具或命令行接口，提取系统启动时间戳、内核日志及事件查看器中的关键事件ID，从而精准定位重启原因与时间点，掌握这些方法，不仅能确认服务器是否发生过非计划性重启，还能为后续的稳定性优化提供数据支撑。
Linux系统查看重启记录的方法
在Linux服务器环境中,查看重启记录主要依赖于分析系统启动日志和用户登录历史，Linux系统将启动信息存储在特定的日志文件中，通过命令行工具可以高效地提取这些信息。
使用last命令查看重启历史
last命令是Linux下查看用户登录历史和系统重启记录最常用的工具，它读取/var/log/wtmp文件，要专门查看重启记录，可以使用last reboot命令，执行后，系统会列出按时间倒序排列的重启记录，包含重启时间、终端信息、持续时间等，输出中的“reboot”标识即代表一次系统启动，时间戳精确到秒。last -x命令可以显示系统关机和运行级别的变化，这对于分析系统是正常关机还是异常崩溃非常有帮助。
通过uptime与who命令确认运行时间
如果只需要确认服务器本次运行了多久，可以使用uptime命令，该命令会显示当前时间、系统运行时间、登录用户数以及过去1分钟、5分钟和15分钟内的平均负载，系统运行时间即是上一次重启到当前的时间差，另一个命令who -b则直接输出系统上次启动的时间，简单直观，适合快速检查。
分析系统日志文件messages或syslog
对于更详细的排查，需要深入分析系统主日志文件，在CentOS/RHEL系统中，通常位于/var/log/messages，而在Ubuntu/Debian系统中则是/var/log/syslog，使用grep命令配合关键词可以快速定位重启事件，执行grep "reboot" /var/log/messages或grep "systemd" /var/log/syslog | grep "Started"，在日志中，寻找包含“kernel”、“rebooting”或“systemd[1]: Starting System”等关键词的行，这些行记录了内核启动和系统服务初始化的详细信息，能够帮助判断重启是由内核触发的还是由系统管理器触发的。
利用dmesg查看硬件级重启信息
dmesg命令用于显示内核环缓冲区的信息，如果服务器是因为硬件故障（如温度过高、电源故障）导致的重启，相关信息通常会被记录在内核日志中，执行dmesg | grep -i "hardware error"或dmesg | grep -i "reset"，可以查找是否有硬件层面的错误报告，这对于物理服务器的故障排查尤为重要，能够区分是软件层面的崩溃还是硬件层面的强制重启。
Windows系统查看重启记录的方法
Windows服务器提供了图形化的“事件查看器”以及强大的PowerShell命令行工具来追踪重启记录，Windows系统将系统启动和关机事件详细记录在“系统”日志中，具有极高的可追溯性。
使用事件查看器（Event Viewer）
事件查看器是Windows系统运维的必备工具，可以通过运行eventvwr.msc打开，在左侧菜单中展开“Windows日志”->“系统”，在右侧的操作面板中，点击“筛选当前日志”，在“事件级别”中勾选“关键”、“警告”和“信息”，并在“事件来源”中筛选“EventLog”。
关键的事件ID包括：
- 事件ID 6008：记录“系统在前一次正常启动后意外关闭”，这通常意味着系统发生了崩溃或断电。
- 事件ID 41：Kernel-Power，记录系统在未先正常关机的情况下重新启动，通常与硬件或电源问题有关。
- 事件ID 1074：记录由用户或进程触发的关机或重启，如果是计划内的重启，通常会有这个记录。
通过筛选这些ID,运维人员可以快速判断重启是人为操作、系统更新还是意外崩溃。
利用PowerShell命令行查询
对于需要批量处理或自动化脚本的场景，PowerShell提供了更高效的查询方式，使用Get-EventLog或Get-WinEvent cmdlet可以精确提取重启信息，执行以下命令可以查询最近的重启事件：
Get-WinEvent -FilterHashtable @{LogName='System'; ID=6008, 41, 1074} | Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-Table -AutoSize
这种方法不仅输出格式整洁，而且可以轻松集成到监控脚本中，实现对服务器重启状态的实时告警。
使用systeminfo命令
类似于Linux的uptime，Windows下的systeminfo命令也能提供系统启动时间，在CMD或PowerShell中输入systeminfo，在输出的信息中找到“系统启动时间”一项，这是判断服务器本次连续运行时长的最快捷方式，适合快速确认服务器是否在最近发生过重启。
云服务器与自动化监控的视角
随着云计算的普及,越来越多的业务部署在云平台上，对于云服务器（如阿里云ECS、AWS EC2），除了操作系统内部的日志，还应关注云厂商控制台提供的“操作审计”或“实例状态变更”记录。
云控制台日志
云厂商的控制台会记录实例的重启、停止、启动等API调用记录，如果操作系统内部日志缺失（例如系统彻底崩溃无法写入日志），云控制台的记录将成为唯一的真相来源，运维人员应检查是否有通过控制台触发的“重启实例”操作，或者是否因底层宿主机故障导致的云实例自动迁移重启。
自动化监控工具
专业的运维团队通常会部署Zabbix、Prometheus等监控系统，这些工具可以通过Agent采集系统运行时间（uptime）指标，并绘制成曲线图，一旦运行时间归零，即代表发生重启，通过配置告警规则，可以在服务器重启的第一时间发送通知，变被动查询为主动监控，大大缩短故障响应时间。
深度分析与故障排查思路
查看重启记录只是第一步,更重要的是根据记录分析重启的根本原因。
区分正常重启与异常重启
如果日志中存在EventLog 1074（Windows）或shutdown命令（Linux）的记录，通常说明是人为操作或计划任务（如补丁更新）导致的正常重启，如果只看到6008、41（Windows）或日志突然中断后紧接着内核启动信息（Linux），则极有可能是系统崩溃、死机或硬件故障。
关联时间点分析
确定重启时间后，应向前追溯几分钟甚至几小时的日志，查看是否有应用程序报错、内存溢出（OOM Killer）、磁盘IO满载或温度过高的警告，Linux中grep "Out of memory" /var/log/messages能发现是否因内存不足导致系统强制杀进程进而引发重启，在Windows中，查看重启前的蓝屏转储文件（Dump文件）是分析崩溃原因的关键。
独立见解：建立重启日志审计机制
为了提升系统的可维护性，建议建立标准化的重启日志审计机制，不要等到出问题才去查日志，而应定期（如每周）导出并分析重启记录，对于频繁重启的服务器，必须建立专项排查文档，记录重启频率、时间分布和操作人员，对于关键业务服务器，建议配置日志转发，将重启日志发送到远程日志服务器，防止因本地磁盘损坏或系统重装导致日志丢失。
相关问答
问题1：Linux服务器重启后，之前的日志会丢失吗？
解答：这取决于日志轮转配置和重启的性质，正常情况下，Linux系统使用日志轮转机制（如logrotate），旧的日志会被压缩归档，不会因为重启而丢失，但如果重启是由于磁盘写满、文件系统损坏或日志文件本身被锁死导致的，且在重启过程中系统执行了磁盘修复或清理操作，那么未及时写入磁盘或损坏的日志部分可能会丢失，建议配置远程日志服务器来保障核心日志的完整性。
问题2：如何判断Windows服务器是自动更新导致的重启？
解答：可以通过事件查看器中的“事件ID 1074”来判断，在消息详情中，如果看到“process wininit.exe”或“services.exe”发起的关机，并且原因注释中包含“Update”字样，通常可以确认为Windows自动更新安装补丁后的自动重启，检查“Windows日志”下的“Setup”日志，也能找到关于系统更新安装成功的记录，与重启时间进行对比即可确认。
能帮助您全面掌握服务器重启记录的查看与分析技巧，如果您在实际操作中遇到更复杂的日志分析难题，欢迎在评论区留言，我们一起探讨解决方案。
