予晚1. 服务器重启记录排查的必要性
服务器突然重启就像家里突然断电一样让人措手不及。作为运维人员，我们经常遇到这样的情况：早上打开监控系统，发现某台服务器在凌晨3点有过一次重启记录，但没人知道发生了什么。这种"神秘重启"不仅影响业务连续性，更可能掩盖着潜在的系统隐患。
我管理过上百台服务器，发现80%的意外重启都源于这三个原因：内核崩溃（OOPs）、硬件故障（特别是内存和电源）以及资源耗尽（OOM killer出手）。上周就遇到个典型案例：某台数据库服务器在业务高峰期突然重启，事后发现是某个异常查询吃光了内存，触发了OOM killer机制。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 四大重启日志源解析
2.1 last命令的妙用
最简单的排查工具往往最有效。在终端输入：
bash复制last -x | grep reboot
你会看到类似这样的输出：
code复制reboot system boot 5.4.0-135-generic Tue Jun 20 03:17 - 10:23 (7:06)
reboot system boot 5.4.0-132-generic Mon Jun 19 08:02 - 10:15 (2:13)
关键字段解析：
- 第三列的内核版本号（5.4.0-135）能帮我们确认是否因内核升级导致重启
- 时间戳中的持续时间（7:06）异常短时，往往意味着非计划重启
- 搭配
last -x shutdown可以查看正常关机记录
经验：遇到疑似异常重启时，立即用
last -x | head -20查看最近记录，防止日志被轮转覆盖
2.2 journalctl的时间魔法
systemd时代的终极武器：
bash复制journalctl --list-boots # 列出所有启动记录
journalctl -b -1 # 查看上一次启动日志
高级技巧：
bash复制# 定位两次启动间的日志
journalctl --since "2023-06-19 08:00" --until "2023-06-20 03:00"
# 筛选内核消息
journalctl -k --since "1 hour ago"
# 结合grep找异常
journalctl -b | grep -i -E "oom|panic|segfault"
2.3 /var/log/syslog的宝藏
老派但可靠的日志源：
bash复制grep -i -E "reboot|shutdown|crash" /var/log/syslog*
重点排查时间点前后5分钟的日志：
bash复制# 假设重启发生在09:30
sed -n '/Jun 20 09:25/,/Jun 20 09:35/p' /var/log/syslog
2.4 内核日志的深度挖掘
bash复制dmesg -T | grep -B10 -A10 "Oops\|Kernel panic"
关键线索：
- "Out of memory" → 内存不足
- "segfault at" → 应用崩溃
- "thermal shutdown" → 过热保护
- "ACPI: Preparing to enter system sleep state" → 可能被误唤醒
3. 自动化监控方案
3.1 使用uptime监控脚本
bash复制#!/bin/bash
CRITICAL_TIME=$((60*60*24*7)) # 7天内的重启报警
last_reboot=$(who -b | awk '{print $3,$4}')
reboot_ts=$(date -d "$last_reboot" +%s)
now_ts=$(date +%s)
if [ $((now_ts - reboot_ts)) -lt $CRITICAL_TIME ]; then
echo "警告: 服务器于 $(date -d @$reboot_ts) 重启"
echo "可能原因:"
journalctl -b | grep -i -m3 -E "error|fail|panic" | head -3
fi
3.2 Prometheus+Alertmanager配置示例
yaml复制# prometheus.yml
scrape_configs:
- job_name: 'node_reboot'
static_configs:
- targets: ['node-exporter:9100']
# alert.rules
groups:
- name: node_reboot
rules:
- alert: NodeReboot
expr: time() - node_boot_time_seconds > 0 and time() - node_boot_time_seconds < 300
for: 1m
labels:
severity: critical
annotations:
summary: "{{ $labels.instance }} 刚刚重启"
description: "启动时间 {{ humanizeTimestamp $value }}"
4. 典型故障排查手册
4.1 内存泄漏导致OOM
特征：
/var/log/kern.log中出现"Out of memory: Kill process"- 重启前监控显示内存使用率持续攀升
取证命令：
bash复制grep -i "oom" /var/log/kern.log*
grep -i "total_vm" /var/log/syslog*
4.2 内核崩溃(Kernel Panic)
特征：
- 控制台出现彩色错误输出
- 日志中有"Kernel panic - not syncing"
取证步骤：
bash复制cp /var/crash/* /tmp/ # 保存崩溃转储
apt install linux-crashdump -y # 启用kdump
4.3 硬件故障
特征：
- 随机性重启，无规律可循
- 伴随SMART错误或EDAC消息
检测命令：
bash复制smartctl -a /dev/sda # 硬盘检查
dmidecode -t memory # 内存信息
sensors # 温度监控
5. 日志保存最佳实践
- 配置logrotate防止覆盖：
conf复制# /etc/logrotate.d/syslog
/var/log/syslog {
rotate 12
monthly
compress
delaycompress
missingok
notifempty
create 644 syslog adm
}
- 关键日志远程备份：
bash复制# 使用rsyslog转发
*.* @192.168.1.100:514
- 重要服务器建议部署ELK栈，使用Filebeat收集：
yaml复制# filebeat.yml
filebeat.inputs:
- type: log
paths:
- /var/log/syslog
- /var/log/kern.log
output.elasticsearch:
hosts: ["es01:9200"]
6. 进阶排查工具
6.1 crash工具分析vmcore
bash复制crash /usr/lib/debug/boot/vmlinux-$(uname -r) /var/crash/202306200317/dump.202306200317
bt -a # 查看调用栈
log # 显示消息缓冲区
6.2 perf性能分析
bash复制perf record -a -g -o perf.data sleep 60 # 采样60秒
perf report -i perf.data # 分析热点
6.3 bpftrace动态追踪
bash复制bpftrace -e 'kprobe:do_sys_reboot { printf("PID %d called reboot\n", pid); }'
7. 云环境特殊考量
AWS实例检查：
bash复制# 查看是否触发了EC2状态检查
aws ec2 describe-instance-status --instance-id i-1234567890
# 检查系统日志
cat /var/log/cloud-init-output.log
Azure实例检查：
powershell复制Get-AzVM -Status | Select-Object Name, PowerState
K8s节点重启排查：
bash复制kubectl get events --sort-by='.lastTimestamp' -A | grep -i reboot
kubectl describe node <node-name> | grep -i -A10 "conditions"