服务器查看关机记录
查看服务器关机记录的核心方法取决于操作系统:

- Windows服务器: 使用 事件查看器 (
eventvwr.msc),筛选系统日志,查找 事件ID 1074 (计划关机) 或 6006 (非计划关机/事件日志服务停止,通常伴随关机) 和 事件ID 6005 (事件日志服务启动,通常伴随开机)。 - Linux服务器: 使用终端命令
last -x | grep shutdown或last -x | grep reboot查看关机/重启记录;对于使用systemd的系统,使用journalctl --list-boots查看启动会话列表,journalctl -b -1(查看上一次启动会话日志,通常包含关机信息) 或journalctl -u systemd-shutdownd。
为什么必须关注服务器关机记录?
服务器并非无故休眠,每一次非预期的关机都可能是潜在问题的信号:
- 安全事件? 恶意入侵者可能试图销毁痕迹或实施破坏。
- 硬件故障? 如电源、内存、CPU过热等隐患的预警。
- 软件崩溃? 关键服务或内核级错误导致系统不稳定。
- 人为失误? 误操作或未经授权的重启。
- 合规要求? 审计追踪必须包含系统状态变更记录。
定期检查关机记录是主动运维和安全防护的重要防线,能帮助快速定位问题源头,防止小故障演变成大事故。
Windows 服务器关机记录查看详解
Windows 将关键的系统事件,包括开关机,详细记录在事件日志中。
-
图形界面操作 (事件查看器):
- 按下
Win + R,输入eventvwr.msc,回车打开 事件查看器。 - 在左侧导航树中,展开 Windows 日志,选择 系统。
- 在右侧 操作 面板中,点击 筛选当前日志…。
- 在 “筛选器” 选项卡的 “事件ID” 框中输入:
1074, 6005, 6006(查找计划关机、启动、非计划关机事件)。- 或
6008(查找异常关机,通常指系统未正常关闭如断电)。
- (可选)可以设置时间范围缩小查找范围。
- 点击 确定,筛选结果将显示符合条件的系统事件。
- 关键事件解析:
- 事件ID 1074: 记录计划内的关机或重启,详细信息会显示谁(用户/进程)发起的操作、原因代码、注释,这是追踪主动关机行为的最重要事件。
- 事件ID 6005: 事件日志服务已启动,这通常发生在系统启动时,记录系统启动时间。
- 事件ID 6006: 事件日志服务已停止,这通常发生在系统计划关机前,记录系统正常关机时间。
- 事件ID 6008: 系统上一次是在 未正常关机的情况下关闭的,这通常意味着意外断电、系统崩溃死锁后的强制关机,记录异常关机发生的时间(即上一次正常关机时间)。
- 按下
-
命令行/PowerShell 高效查询:
- 打开 命令提示符 (cmd) 或 PowerShell。
- 使用
wevtutil工具进行快速查询:# 查询最近的10个系统日志中的事件ID 1074 (计划关机/重启) wevtutil qe System /q:"[System[(EventID=1074)]]" /c:10 /rd:true /f:text # 查询事件ID 6006 (正常关机) 和 6008 (异常关机) wevtutil qe System /q:"[System[(EventID=6006 or EventID=6008)]]" /c:10 /rd:true /f:text
- 使用 PowerShell Get-WinEvent 更强大灵活:
# 获取最近24小时内所有的关机事件 (1074, 6006) Get-WinEvent -LogName System -MaxEvents 100 | Where-Object {($_.Id -eq 1074 -or $_.Id -eq 6006) -and ($_.TimeCreated -ge (Get-Date).AddHours(-24))} | Format-List TimeCreated, Id, Message # 获取所有异常关机事件 (6008) Get-WinEvent -FilterHashtable @{LogName='System'; ID=6008} | Format-List TimeCreated, Message-MaxEvents: 限制返回事件数量。-FilterHashtable: 强大的过滤条件,可指定时间范围、事件ID等。Format-List: 以列表形式展示详细信息,便于阅读Message。
Linux 服务器关机记录查看权威方法
Linux 主要通过特定的日志文件和命令来追踪系统启动关闭事件。

-
last命令 – 追踪登录与会话历史:- 打开终端。
- 输入命令:
last -x -x选项是关键:它显示系统 关机 (shutdown)、运行级别更改 (runlevel) 和 重启 (reboot) 事件以及用户登录历史。- 筛选关键事件:
last -x | grep shutdown # 专门查看关机记录 last -x | grep reboot # 专门查看重启记录 last -x | head -n 20 # 查看最近的20条记录(包含开关机)
- 输出解读:
- 第一列:事件类型 (
reboot,shutdown, 用户名root等) 或终端 (pts/0,tty1等)。 - 第二列:终端标识(对于关机重启事件,通常是 或
system boot)。 - 第三列:登录IP或来源(关机重启事件通常没有)。
- 第四列:关键! 显示事件的 开始日期和时间 (即关机/重启发生的时刻)。
- 第五列:事件的 结束日期和时间 (对于关机事件,这是系统停止的时刻;对于重启事件,这是新会话开始的时间;对于登录会话,这是登出时间)。
still logged in表示会话未结束。down表示系统在此时间点关闭。 - 最后列:持续时间(对于关机重启事件,通常是
down时间)。
- 第一列:事件类型 (
-
journalctl(Systemd 系统) – 强大的集中日志查询:- 现代主流 Linux 发行版 (CentOS 7+, RHEL 7+, Ubuntu 15.04+, Debian 8+, openSUSE, Arch 等) 默认使用
systemd及其日志系统journald。 - 查看启动会话列表:
journalctl --list-boots # 列出所有记录的启动会话(Boot ID, 起止时间)
- 查看特定启动会话的完整日志 (包含关机信息):
journalctl -b -0 # 查看当前启动会话的日志 (从本次开机到现在) journalctl -b -1 # 查看上一次启动会话的日志 (包含上次运行期间的日志,以及关机前的信息) journalctl -b # 同 -b -0
- 直接筛选关机相关消息:
journalctl -u systemd-shutdownd.service # 查看关机服务单元的日志 journalctl | grep -i "shutting down|system halt" # 在全部日志中搜索关机关键词 (不够精确但有时有用)
-u: 指定查看特定 systemd 单元的日志。
- 现代主流 Linux 发行版 (CentOS 7+, RHEL 7+, Ubuntu 15.04+, Debian 8+, openSUSE, Arch 等) 默认使用
-
传统日志文件
/var/log/(辅助参考):/var/log/messages(RHEL/CentOS 等): 通用系统消息日志,可能包含关机启动信息。/var/log/syslog(Debian/Ubuntu 等): 通用系统日志,作用类似messages。/var/log/boot.log: 专门记录系统启动过程 的日志,它记录了本次开机时系统服务和进程的初始化信息。注意:它通常不记录关机过程,关机信息主要看last和journalctl。
专业运维与安全审计解决方案
仅仅会查看基础记录是运维的起点,专业视角要求更深入的洞察和自动化保障:
-
集中化日志管理 (SIEM/Syslog):
- 痛点: 服务器分散,手动登录每台机器检查效率低下,历史日志易被覆盖或删除。
- 方案: 部署 ELK Stack (Elasticsearch, Logstash, Kibana)、Splunk、Graylog 或 rsyslog/syslog-ng 转发,将所有服务器的系统日志(特别是
Security,System日志和 syslog/authlog)实时收集到中心平台。 - 价值:
- 统一视图: 在一个界面搜索、分析所有服务器的开关机事件。
- 长期存储与审计: 满足合规要求,避免本地日志轮转丢失。
- 关联分析: 将关机事件与登录事件、进程启动、网络连接等关联,快速识别可疑活动(如管理员登录后立即关机)。
- 趋势分析: 发现特定时间段或服务器上关机事件的异常模式。
-
自动化告警:

- 痛点: 非计划关机发生后无法及时知晓,被动响应延迟故障恢复。
- 方案:
- 监控工具集成: 在 Zabbix, Nagios, Prometheus+Grafana 等监控系统中配置规则,当检测到服务器状态由
Up变为Down(通过 ICMP ping 或 Agent 检测) 时,立即触发告警(邮件、短信、钉钉、企业微信)。 - 日志告警: 在集中日志平台 (如 ELK Watcher, Splunk Alert) 设置规则,当检测到
事件ID 1074(非计划原因代码)、6008(异常关机)、Linuxshutdown事件(非特定用户/计划任务触发)时,实时告警。 - Agent 脚本: 在服务器本地部署脚本,在关机前(利用 systemd 服务单元
ExecStop=)或启动后立即发送事件通知到监控中心或消息队列。
- 监控工具集成: 在 Zabbix, Nagios, Prometheus+Grafana 等监控系统中配置规则,当检测到服务器状态由
-
关机原因深度分析 (Windows):
- 关键: Windows
事件ID 1074中的 原因代码 和 注释。 - 分析:
- 常见原因代码:
0x80020002(其他计划外原因 – Legacy),0x0(其他计划外原因),0x500ff(停止错误 – 蓝屏),0x4000000000000000(计划维护),0x8000000000000000(计划重启/关机)。 who字段: 明确触发关机的用户账户或进程(如NT AUTHORITYSYSTEM通常是计划任务或系统更新)。- 结合其他日志: 查看同一时间点前后的应用程序日志、安全日志(登录/注销事件)、更新日志,判断是否由更新安装、计划任务、用户操作(
who /logonid查找登录会话关联)、蓝屏崩溃 (事件ID 41,内核电源事件) 引起。
- 常见原因代码:
- 关键: Windows
-
提升关机记录的可信度与完整性:
- 配置日志覆盖策略: 确保日志文件足够大,按需存档而非直接覆盖旧事件(Windows 事件日志属性设置;Linux
logrotate配置)。 - 时钟同步 (NTP): 所有服务器严格同步时间 (
chronyd/ntpd),确保日志时间戳准确无误,便于跨服务器事件关联。 - 文件系统权限: 严格保护日志文件和目录权限(如 Linux
/var/log权限通常为root:root和640),防止恶意篡改或删除。 - 启用详细审计策略 (Windows): 在
本地安全策略 -> 高级审核策略配置 -> 系统审核策略 -> 详细跟踪中启用 “审核进程创建” 和 “审核进程终止”,结合安全日志中的4688(进程创建) 和4689(进程终止) 事件,追踪可能触发关机命令 (shutdown.exe) 的源头进程,极大增强溯源能力,这是专业安全审计的必备步骤。
- 配置日志覆盖策略: 确保日志文件足够大,按需存档而非直接覆盖旧事件(Windows 事件日志属性设置;Linux
关机记录:安全审计的“沉默哨兵”
服务器关机远非一个简单的状态变化,每一次关机记录,尤其是非计划和非授权的,都可能是系统健康状况的“体检报告”或安全事件的“蛛丝马迹”,专业的运维和安全团队不应满足于基础的命令查询,而应将其视为整个监控、审计、响应链条上的关键一环。
通过实施集中化日志管理、自动化告警、深度原因分析,并辅以严格的日志保护和审计策略,关机记录才能从静态的数据转变为主动防御和快速响应的有力武器,忽视这些记录,等同于在系统稳定性和安全性的防线上留下盲点。
你在服务器运维中,是否曾因关机记录发现过隐藏的重大故障或安全风险?对于保障关键业务服务器关机记录的完整性与可追溯性,你有怎样的最佳实践?欢迎分享你的经验与见解!
原创文章,作者:世雄 - 原生数据库架构专家,如若转载,请注明出处:https://idctop.com/article/27559.html