為什麼我的 EC2 Linux 執行個體無法連線且無法進行狀態檢查？

簡短說明

Amazon EC2 使用三種狀態檢查來監控 EC2 執行個體的運作狀態：

系統狀態檢查

系統狀態檢查會偵測執行個體的基礎硬體問題。如果基礎硬體因網路、硬體或軟體問題而無法回應或無法連線，則系統狀態檢查會失敗。

執行個體狀態檢查

執行個體狀態檢查失敗表示執行個體無法連線。下列問題可能會導致執行個體狀態檢查失敗：

• 無法啟動作業系統 (OS)。
• 無法正確掛載磁碟區。
• CPU 和記憶體耗盡。
• 核心程序危急。
• 網路失敗。

**警告：**下列某些解決方案需要停止和啟動執行個體。停止並啟動執行個體之前，請注意以下條件：

• 在執行個體停止時，儲存在執行個體儲存體磁碟區中的資料會遺失。在停止執行個體之前，確保已備份資料。與 Amazon Elastic Block Store (Amazon EBS) 支援的磁碟區不同，執行個體儲存體磁碟區不支援資料持續性。
• Amazon EC2 在啟動或開始時自動指派給執行個體的靜態公用 IPv4 地址，在停止和啟動後變更。若要保留在執行個體停止時不會變更的公用 IPv4 地址，請使用彈性 IP 地址。

如需詳細資訊，請參閱停止並啟動 Amazon EC2 執行個體。

附加 EBS 狀態檢查

附加 EBS 狀態檢查會監控附加到執行個體的 Amazon EBS 磁碟區是否可存取，且能夠完成 I/O 作業。如需詳細資訊，請參閱附加 EBS 狀態檢查。

解決方法

若要查看執行個體狀態檢查或系統狀態檢查是否失敗，請檢視執行個體的狀態檢查指標。

如果系統狀態檢查失敗，請參閱為什麼 EC2 Linux 執行個體的系統狀態檢查失敗？

如果執行個體狀態檢查失敗，請檢查執行個體的系統日誌以了解失敗的原因。然後，使用下列其中一個可能的解決方案來解決問題。

無法啟動作業系統

如果系統日誌包含啟動錯誤，請參閱如何對由於作業系統出現問題而未能通過執行個體狀態檢查的 EC2 Linux 執行個體進行疑難排解？

無法正確掛載磁碟區

掛載點失敗可能會導致執行個體狀態檢查失敗。掛載點失敗命令範例：

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

如需詳細資訊，請參閱下列 AWS 知識中心文章：

• 「Dependency failed」錯誤：在我嘗試啟動 EC2 Linux 執行個體時，為什麼它會進入緊急模式？
• 「Failed to mount」或「Dependency failed」錯誤：如何對由於作業系統出現問題而未能通過執行個體狀態檢查的 EC2 Linux 執行個體進行疑難排解？

當您將執行個體類型從 Xen 變更為 Nitro 型執行個體時，磁碟區掛載可能會失敗。發生掛載失敗的原因是，Amazon EBS 磁碟區在 Nitro 型執行個體上公開為 NVMe 區塊型儲存設備。例如，設備名稱是 /dev/nvme0n1 和 /dev/nvme1n1。您在區塊型儲存設備映射中指定的設備名稱會重新命名為 NVMe 設備名稱 (/dev/nvme[0-26]n1)。

**注意：**區塊型儲存設備驅動程式指派 NVMe 設備名稱的順序，可能與您在區塊型儲存設備映射中指定的原始順序不同。為避免在 Nitro 型執行個體上掛載失敗，最佳做法是使用標籤或 UUID 作為設備名稱。如需相關資訊，請參閱讓 Amazon EBS 磁碟區可使用。

CPU 和記憶體耗盡

高 CPU 使用率

如果 CPUUtilization 指標等於或接近 100%，則執行個體沒有足夠的運算容量來執行核心程序。

若為 T2 或 T3 執行個體，請檢查 Amazon CloudWatch CPU 積分指標，以查看 CPU 點數是否等於或接近零。如果 CPU 積分為零，則 CPUUtilization 指標顯示執行個體的基準效能的飽和平穩狀態。例如，基準效能可能是 20% 或 40%。CPU 使用率達到或接近 100%，表示狀態檢查因資源使用率過高而失敗。已達到飽和狀態的 T2 或 T3 執行個體會顯示狀態檢查因使用率過高而失敗。

若要對該問題進行疑難排解，請參閱如何疑難排解因資源過度使用而無法進行狀態檢查的 EC2 Linux 執行個體？

區塊型儲存設備錯誤、軟體錯誤或核心程序危急可能會造成 CPU 用量峰值異常。如果 CPU 使用率達到 100％，請先檢查系統日誌中是否存在區塊型儲存設備或記憶體問題錯誤或其他異常系統錯誤。然後，重新啟動或停止並啟動執行個體。

記憶體不足

高記憶體壓力可能會導致執行個體狀態檢查失敗。在下列範例日誌擷取中，作業系統記憶體不足，並啟動了 oom-killer。若要解決此錯誤，請停止耗用最多記憶體的處理程序。

[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 執行個體記憶體和磁碟指標不會傳送至 Amazon CloudWatch。如需詳細資訊，請參閱使用 CloudWatch 代理程式收集指標、日誌和追蹤。

若要疑難排解並解決記憶體不足的問題，請將執行個體升級為較大的執行個體類型。或者，將交換儲存裝置新增至執行個體，以減輕記憶體壓力。如需詳細資訊，請參閱下列 AWS 知識中心文章：

• 如何配置記憶體以用作 Amazon EC2 執行個體中的交換空間？
• 如何使用硬碟上的分割區配置記憶體以作為 Amazon EC2 執行個體上的交換空間？

磁碟已滿錯誤

如果系統日誌包含磁碟已滿錯誤，則執行個體會因根裝置已滿而處於緊急模式。

系統日誌範例：

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

$: sudo /etc/init.d/mysql restart
[....] Restarting mysql (via systemctl):
mysql.serviceError: No space left on device

$: df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.7G  7.7G     0 100% /

如需有關如何疑難排解和解決磁碟已滿錯誤的詳細指示，請參閱下列知識中心文章：

• 如何對因資源過度使用而無法進行狀態檢查的 EC2 Linux 執行個體進行疑難排解？
• 如果收到檔案系統上沒有剩餘空間的錯誤，如何增加 EBS 磁碟區的大小？

核心程序危急

當核心程序在操作期間偵測到內部嚴重錯誤時，會發生核心程序危急。如果在作業系統啟動期間發生錯誤，則核心程序無法正確載入。核心程序載入失敗會導致執行個體啟動失敗。

核心程序危急錯誤訊息範例：

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)

如需有關如何疑難排解和解決核心程序危急錯誤的資訊，請參閱下列知識中心文章：

• 如何修復 EC2 執行個體上的「核心程序危急 - 未同步」錯誤？
• 在更新導致 Amazon EC2 執行個體無法成功重新啟動後，如何還原為已知穩定的核心程序？

網路失敗

您的網路可能會因下列原因而失敗：

• 執行個體上未安裝 cloud-init 套件
• cloud-init 套件用於在啟動時更新網路組態。

若要修正此錯誤並在執行個體上安裝 cloud-init 套件，請執行以下命令：

對於 Amazon、Amazon Linux 2、Amazon Linux 2023 或 RedHat 作業系統：

$ sudo yum install cloud-init -y

對於 Ubuntu 或 Debian 作業系統：

$ sudo apt install cloud-init -y

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 地址導致的網路問題，請移除項目或組態檔案，然後執行以下命令：

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

組態檔案移動後，重新啟動網路服務，以確保可接收到新的 MAC 位址。

IP 地址會以硬式編碼方式存在於網路組態檔案中

在您透過具有靜態設定的 IP 地址的執行個體建立 Amazon Machine Image (AMI) 時，組態檔案會包含硬式編碼的 IP 地址。若要更正此錯誤，請將您的網路介面設定為使用 DHCP。

注意： 您無法更新已存在的 AMI。在建立新的 AMI 之前，您必須先將網路介面設定為使用 DHCP。

缺少 ENA 或 Intel 增強型網路驅動程式

如需有關遺失彈性網路介面卡 (ENA) 或 Intel 增強型網路驅動程式的詳細資訊，請參閱 Amazon EC2 執行個體上的增強型網路。

網路介面會在啟動時自動重新命名

若要停用可預測的網路介面重新命名，請將 net.ifnames=0 新增至核心程序命令列。若要使用預留位置，您必須使用 ENA 啟動增強型網路，並重建或更新 grub 組態檔。

相關資訊

對 Amazon EC2 Linux 執行個體的狀態檢查失敗問題進行疑難排解

為什麼我的 EC2 Windows 執行個體因系統狀態檢查失敗或狀態檢查 0/2 而關閉？

為什麼我的 EC2 Windows 執行個體因執行個體狀態檢查失敗而關閉？

狀態檢查的類型