🩺 我在真实环境中如何排查 EC2 实例（使用实例诊断）

Source: Dev.to

Source:

当 EC2 实例开始异常时，我的第一反应不是 SSH 登录或重启它。

相反，我会打开 EC2 控制台，直接进入 实例诊断。

随着时间的推移，我发现大多数 EC2 问题都可以通过仔细阅读 AWS 已经在此页面上展示的信息来理解 — 并且经常能够解决 — 。

在这篇博客中，我将解释如何在实际、真实的场景中使用 实例诊断的每个部分 来排查 EC2 问题。

我首先要回答的问题

在动手之前，我会问自己一个简单的问题：

这是 AWS 基础设施的问题，还是实例内部的问题？

实例诊断可以在几秒钟内帮助回答这个问题。

Status Overview – Always the Starting Point

我总是从 Status Overview 开始查看。

Instance State

显示实例是 running（运行中）、stopped（已停止）还是 terminated（已终止）。
如果实例未运行，通常没有需要排查的问题。

System Status Check

反映底层 AWS 基础设施（物理主机、网络等）的健康状况。
如果此检查失败，问题出在 AWS 端。 在大多数情况下，停止实例后再启动即可通过迁移到健康主机来解决。

Instance Status Check

表示操作系统和内部网络的健康状况。
如果此检查失败，问题出在实例内部——通常是 OS 启动问题、内核故障、防火墙规则或资源耗尽。

EBS Status Check

确认已挂载 EBS 卷的健康状况。
如果此检查失败，可能是磁盘或存储层面的故障，此时数据保护应成为首要任务。

CloudTrail Events – Tracking Configuration Changes

如果问题突然出现，我会首先查看 CloudTrail Events 选项卡。我使用它来确认：

• 实例是否被 stopped、started 或 rebooted
• security groups 或 network settings 是否被修改
• IAM roles 或 instance profiles 是否被更改
• volumes 是否被挂载或分离

这可以快速识别是人为还是自动化驱动的更改。

SSM Command History – Understanding What Ran on the Instance

The SSM Command History 选项卡显示在实例上执行的所有 Systems Manager 运行命令。它特别适用于快速发现：

• 补丁作业
• 维护脚本
• 自动修复
• 配置更改

如果没有最近的命令，这一信息仍然有价值，因为它确认没有 SSM‑驱动的操作导致了该问题。

可达性分析器 – 当问题与网络相关时

如果实例正在运行但无法访问，我会直接从实例诊断中打开 可达性分析器。这是我诊断的首选工具，用于排查：

• 安全组问题
• 网络 ACL 配置错误
• 路由表问题
• Internet‑gateway 或 NAT‑gateway 连接问题
• VPC‑到‑VPC 或本地（on‑prem）连接问题

与其盲目猜测，可达性分析器 会直观地显示网络路径被阻断的具体位置。

Instance Events – 检查 AWS 发起的操作

Instance Events 选项卡告诉我 AWS 是否已在实例上安排或执行任何操作，例如：

• 计划维护
• 主机退役
• 实例重启通知

如果问题与这些事件之一相符，根本原因会立即变得清晰。

实例截图 – 当操作系统卡住时

如果我根本无法连接到实例，我会查看 实例截图。这在以下情况下尤其有帮助：

• 识别启动失败
• 检测内核恐慌信息
• 查看操作系统在启动过程中是否卡住

即使是一张截图，也能解释数小时的故障排查过程。

系统日志 – 理解启动和内核问题

系统日志 提供低层次的操作系统和内核消息。我在以下情况下依赖它：

• 实例无法正常启动
• 服务在启动期间失败
• 怀疑内核或文件系统错误

它是诊断操作系统级别故障而无需登录的最佳工具之一。

[[0;32m  OK  [0m] Reached target [0;1;39mTimer Units[0m.
[[0;32m  OK  [0m] Started [0;1;39mUser Login Management[0m.
[[0;32m  OK  [0m] Started [0;1;39mUnattended Upgrades Shutdown[0m.
[[0;32m  OK  [0m] Started [0;1;39mHostname Service[0m.
         Starting [0;1;39mAuthorization Manager[0m...

[[0;32m  OK  [0m] Started [0;1;39mAuthorization Manager[0m.
[[0;32m  OK  [0m] Started [0;1;39mThe PHP 8.2 FastCGI Process Manager[0m.
[[0;32m  OK  [0m] Finished [0;1;39mEC2 Instance Connect Host Key Harvesting[0m.
         Starting [0;1;39mOpenBSD Secure Shell server[0m...
[[0;32m  OK  [0m] Started [0;1;39mOpenBSD Secure Shell server[0m.
[[0;32m  OK  [0m] Started [0;1;39mDispatcher daemon for systemd‑networkd[0m.
[[0;1;31mFAILED[0m] Failed to start [0;1;39mPostfix Ma… Transport Agent (instance -)[0m.
See `systemctl status postfix@-.service` for details.
[[0;32m  OK  [0m] Started [0;1;39mLSB: AWS CodeDeploy Host Agent[0m.
[[0;32m  OK  [0m] Started [0;1;39mVarnish HTTP accelerator log daemon[0m.
[[0;32m  OK  [0m] Started [0;1;39mSnap Daemon[0m.
         Starting [0;1;39mTime & Date Service[0m...
[   13.865473] cloud‑init[1136]: Cloud‑init v. 25.1.4‑0ubuntu0~22.04.1 running 'modules:config' at Fri, 05 Dec 2025 01:25:29 +0000. Up 13.71 seconds.

Ubuntu 22.04.3 LTS ip‑***** ttyS0

ip‑****** login: [   15.070290] cloud‑init[1152]: Cloud‑init v. 25.1.4‑0ubuntu0~22.04.1 running 'modules:final' at Fri, 05 Dec 2025 01:25:30 +0000. Up 14.98 seconds.  
2025/12/05 01:25:30Z: Amazon SSM Agent v3.3.2299.0 is running  
2025/12/05 01:25:30Z: OsProductName: Ubuntu  
2025/12/05 01:25:30Z: OsVersion: 22.04  
[   15.189197] cloud‑init[1152]: Cloud‑init v. 25.1.4‑0ubuntu0~22.04.1 finished at Fri, 05 Dec 2025 01:25:30 +0000. Datasource DataSourceEc2Local.  Up 15.16 seconds  
2025/12/15 21:35:50Z: Amazon SSM Agent v3.3.3050.0 is running  
2025/12/15 21:35:50Z: OsProductName: Ubuntu  
2025/12/15 21:35:50Z: OsVersion: 22.04  
[1091674.876805] Out of memory: Killed process 465 (java) total‑vm:11360104 kB, anon‑rss:1200164 kB, file‑rss:3072 kB, shmem‑rss:0 kB, UID:1004 pgtables:2760 kB oom_score_adj:0  
[1091770.835233] Out of memory: Killed process 349683 (php) total‑vm:563380 kB, anon‑rss:430132 kB, file‑rss:4096 kB, shmem‑rss:0 kB, UID:0 pgtables:1068 kB oom_score_adj:0  
[1092018.639252] Out of memory: Killed process 347300 (php‑fpm8.2) total‑vm:531624 kB, anon‑rss:193648 kB, file‑rss:3456 kB, shmem‑rss:106240 kB, UID:33 pgtables:888 kB oom_score_adj:0

会话管理器：无需 SSH 的安全访问

如果已启用 Systems Manager，我更倾向于使用 Session Manager 来访问实例。

这使我能够：

• 检查 CPU、内存和磁盘使用情况
• 安全地重启服务
• 避免打开 SSH 端口或管理密钥对

从安全性和运营角度来看，这是一种我更偏好的访问方式。

经验教会我的事

排查 EC2 实例的问题并不是要快速反应——而是要仔细观察。

Instance Diagnostics 已经提供了：

• 健康信号
• 更改历史
• 网络分析
• 操作系统层面的可视性

正确使用这些工具可以消除猜测，降低停机时间。

最后思考

我的 EC2 故障排除方法很简单：

1. 从实例诊断开始。
2. 了解信号。
3. 只有在根本原因明确后才采取行动。

在大多数情况下，答案已经显而易见——我们只需放慢速度并仔细阅读即可。