为什么我的 EC2 Linux 实例无法访问，并且一项或多项状态检查失败？

3 分钟阅读

我的 Amazon Elastic Compute Cloud（Amazon EC2）Linux 实例无法访问，且有一项或多项状态检查失败。

简短描述

Amazon EC2 使用两种状态检查监控每个 EC2 实例的运行状况：

系统状态检查

系统状态检查用于检测运行您的实例的底层主机是否存在问题。如果底层主机因网络、硬件或软件问题而没有响应或无法访问，则此状态检查将失败。

实例状态检查

实例状态检查失败表明无法访问实例。导致此问题的原因是出现操作系统级别的错误，如下所示：

未能启动操作系统
未能正确挂载卷
CPU 和内存耗尽
内核崩溃
网络启动失败

警告：某些解决方案要求先停止，然后再启动实例。在停止和启动实例之前，请注意以下情况：

当您停止并启动实例时，实例存储数据会丢失。如果您的实例受实例存储支持或具有包含数据的实例存储卷，则在实例停止时数据将丢失。有关更多信息，请参阅确定实例的根设备类型。
如果您的实例是 Amazon EC2 Auto Scaling 组的一部分，则停止实例可能会终止实例。如果您使用 Amazon EMR、AWS CloudFormation 或 AWS Elastic Beanstalk 启动实例，则您的实例可能是 AWS Auto Scaling 组的一部分。在这种情况下，是否会发生实例终止取决于您的自动扩缩组的实例缩减保护设置。如果您的实例是 Auto Scaling 组的一部分，则在开始执行解决步骤之前，请暂时从 Auto Scaling 组中删除该实例。
停止和启动实例会将公有 IP 地址释放回 AWS 动态 IP 池中。将外部流量路由到您的实例时，最佳做法是使用 Elastic IP 地址，而不是公有 IP 地址。如果您使用 Amazon Route 53，可能需要在公有 IP 更改时更新 Route 53 DNS 记录。

有关更多信息，请参阅停止并启动实例。

解决方案

1. 通过查看实例状态检查指标，确定实例状态检查或系统状态检查是否失败。

2. 如果系统状态检查失败，请参阅我的 EC2 Linux 实例的系统状态检查失败。如何排查此问题？

如果实例状态检查失败，请查看实例的系统日志以确定失败的原因。根据在系统日志中找到的数据，使用以下解决方案之一：

未能启动操作系统

如果系统日志中包含启动错误，请参阅因操作系统问题，我的 EC2 Linux 实例的实例状态检查失败。如何排查此问题？

未能正确挂载卷

由于挂载点无法正确挂载，实例状态检查可能会失败，如此示例所示：

[FAILED] Failed to mount /
See 'systemctl status mnt-nvme0n1p1.mount' for details.
[DEPEND] Dependency failed for Local File Systems.

CPU 和内存耗尽

CPU 利用率高

如果 CPUUtilization 指标等于或接近 100%，则实例可能不具有足够的计算容量供内核运行。

对于 T2 或 T3 实例，请检查 Amazon CloudWatch 指标表中的 CPU 积分指标以确定 CPU 积分是否等于或接近零。如果 CPU 积分为零，则 CPU 利用率指标在实例的基线性能处显示饱和稳定状态。基准性能可能是 20%、40% 等等，具体取决于实例类型。

指示 CPU 利用率等于或接近 100%，或者对于 T2 或 T3 实例指示其处于饱和平稳状态的 CloudWatch 指标表示状态检查因实例资源的过度利用而失败。有关如何排查此问题的说明，请参阅由于资源的过度利用，我的 EC2 Linux 实例的实例状态检查失败。如何排查此问题？

块储存设备错误、软件错误或内核崩溃可能会导致不寻常的 CPU 使用突增。如果 CPU 利用率指标为 100%，且系统日志中包含与块储存设备相关的错误、内存问题或其他不寻常的系统错误，请重启实例或停止并启动实例。

内存不足

高内存压力可能会导致实例状态检查失败。在此示例中，操作系统内存不足并停止消耗内存最多的进程。

[115879.769795] Out of memory: kill process 20273 (httpd) score 1285879 or a child
[115879.769795] Killed process 1917 (php-cgi) vsz:467184kB, anon-rss:101196kB, file-rss:204kB

默认情况下，不会将 EC2 内存和磁盘指标发送到 CloudWatch。但是，您可以使用 CloudWatch 代理将其他指标发送到 CloudWatch 以进行监控。

要排查并解决内存不足问题，请考虑将实例升级到更大的实例类型。或者，向实例添加交换存储空间以减轻内存压力。有关更多信息，请参阅这些主题：

磁盘已满错误

如果系统日志中包含磁盘已满错误，说明实例可能已经因为根设备已满而进入紧急模式。

$: service apache2 restart
Error: No space left on device

$: /etc/init.d/mysql restart
[....] Restarting mysql (via systemctl): mysql.serviceError: No space left on device
        
        
root@example:~# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.7G  7.7G     0 100% /

有关如何排查和解决磁盘已满错误的详细说明，请参阅以下内容：

内核崩溃

如果在操作过程中内核检测到致命的内部错误，会发生内核崩溃错误。如果在操作系统启动期间发生错误，那么内核可能无法正确加载。这可能会导致操作系统启动失败。以下是内核崩溃错误消息的示例：

Linux version
2.6.16-xenU (builder@xenbat.amazonsa) (gcc version 4.0.1 20050727 (Red Hat4.0.1-5)) #1 SMP Mon May 28 03:41:49 SAST 2007
Kernel command
line:  root=/dev/sda1 ro 4
Registering block device major 8
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)

有关故障排查和解决内核崩溃错误的信息，请参阅这些主题：

网络启动失败

由于以下原因，网络可能启动失败：

缺少 "cloud-init" 程序包

如果实例缺少 cloud-init 程序包，则可能导致网络启动失败。cloud-init 程序包对于在启动时更新网络配置非常有用。

要修复此错误，您可以将 cloud-init 程序包安装到您的实例。

$ sudo yum install cloud-init

MAC 地址硬编码在配置文件中

如果您的 MAC 地址硬编码在配置文件中，则可能会遇到导致网络启动失败的问题。

硬编码的 MAC 地址可以在 Linux 配置文件和 "udev" 配置文件中找到，例如在以下位置：

/etc/udev/rules.d/
/etc/udev/rules.d/70-persistent-net.rules
/etc/udev/rules.d/80-net-name-slot.rules

要在实例中硬编码您的 MAC 地址时解决网络问题，您需要删除条目或配置文件。例如：

mv /etc/udev/rules.d/70-persistent-net.rules/root/

IP 地址硬编码在配置文件中

如果您的 IP 地址硬编码在配置文件中，则可能会遇到导致网络启动失败的问题。从具有静态配置 IP 地址的实例中获取 Amazon Machine Image (AMI) 时，会发生这种情况。

要修复此错误，请将网络接口设置为使用 DHCP。

注意：您无法更新现有 AMI。在新建 AMI 之前，必须在实例上设置网络接口以使用 DHCP。

缺少 ENA 或 Intel 增强型网络驱动程序

如果实例缺少 Elastic Network Adapter (ENA) 或 Intel 增强型网络驱动程序，则可能导致网络启动失败。

有关更多信息，请参阅 Linux 上的增强联网。

网络接口在启动时重命名

如果在实例启动时重命名网络接口，可能会导致网络问题。要修复此错误，请通过在内核命令行中添加 net.ifnames=0 来停用可预测的网络接口名称。为此，必须使用 ENA 激活增强联网。

有关网络问题的更多信息，请参阅配置网络接口的最佳实践。