AWS EC2实例异常重启排查技术问询

嗨，针对你遇到的EC2实例莫名重启问题，我给你整理几个实用的排查方向，尤其是你提到的CloudWatch和CloudTrail的使用技巧，希望能帮你定位原因：

一、先从AWS云服务层面排查（重点看CloudTrail和CloudWatch） #

1. CloudTrail事件追踪 #

• 登录CloudTrail控制台，进入「事件历史」页面，通过以下方式筛选关键事件：
  • 按事件名称筛选：搜索RebootInstances、StopInstances、StartInstances——重启操作通常对应这几个事件，不管是手动触发还是AWS服务自动执行的。
  • 按资源ID筛选：输入你的EC2实例ID，精准定位和该实例相关的所有操作。
  • 重点看事件发起者：如果是IAM用户/角色触发的，会显示对应的身份信息；如果是AWS系统（比如自动缩放、维护窗口）发起的，事件详情里会标注服务来源。
• 额外提醒：如果是AWS系统维护导致的重启，除了CloudTrail，你也可以直接在EC2控制台的实例详情页「事件历史」里查看官方的维护通知。

2. CloudWatch日志与指标分析 #

• 状态检查指标：在CloudWatch控制台找到你的EC2实例，查看StatusCheckFailed_System和StatusCheckFailed_Instance这两个指标：
  • 若StatusCheckFailed_System有触发，说明是AWS底层硬件/网络故障导致的重启，直接去EC2事件历史找对应记录即可。
  • 若StatusCheckFailed_Instance触发，大概率是实例内部的问题，需要结合系统日志进一步排查。
• 日志内容检索：如果之前配置了CloudWatch Logs Agent同步实例日志（比如/var/log/messages、system.journal），可以在CloudWatch日志组里搜索重启前后的时间段——有时候本地日志会因为突然重启丢失部分内容，但CloudWatch里可能保留了更完整的记录，包括那10分钟间隙前后的关键信息。
• CloudWatch Events：检查有没有自定义的事件规则触发了实例重启，比如定时任务、告警联动的操作。

二、实例内部的补充排查 #

虽然你已经查看了/var/log目录，但可以针对性地再查几个核心文件：

• 重点检查/var/log/messages（RHEL/CentOS系）或/var/log/syslog（Debian/Ubuntu系）：这里会记录系统级的关键操作，比如内核异常、进程崩溃、重启命令的执行记录。
• 查看/var/log/secure：排查是否有异常SSH登录、sudo权限操作——如果是有人登录后执行了重启命令，这里会留下痕迹。
• 用systemd日志工具深挖：
  • 执行journalctl --list-boots可以看到所有启动会话的序号，其中-1代表上一次启动（也就是重启前的最后一次会话）。
  • 再执行journalctl -b -1就能查看上一次会话的完整日志，可能会找到系统崩溃、内核panic或者触发重启的进程异常信息。
• 检查内核日志：执行dmesg命令，查看有没有硬件错误、驱动崩溃等内核级问题，这类问题往往会直接导致系统突然重启，且不会写入常规应用日志。

三、其他可能的排查点 #

• 检查自动缩放组：如果实例属于Auto Scaling组，查看组的「活动历史」，看是否因为健康检查失败、缩放策略触发了实例替换或重启。
• 负载均衡健康检查：如果实例挂载了ELB/NLB，检查负载均衡的健康检查状态和日志，若健康检查持续失败，可能会触发实例的重启或终止（取决于配置）。
• AWS健康仪表盘：访问AWS Health Dashboard，查看你的账户或所在区域是否有EC2相关的服务事件，比如硬件故障、网络 outage 等官方通知。

备注：内容来源于stack exchange，提问作者Philippe