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

簡短描述

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

系統狀態檢查

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

執行個體狀態檢查

當您無法連線執行個體時，執行個體狀態檢查會失敗。執行個體狀態檢查可能會因為以下原因而失敗：

• 作業系統 (OS) 啟動失敗
• Amazon Elastic Block Store (Amazon EBS) 磁碟區無法正確掛載
• CPU 和記憶體已耗盡
• 核心程序危急
• 網路故障
• 根 EBS 磁碟區參數限流

附加 EBS 狀態檢查

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

解決方法

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

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

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

**重要：**以下某些解決方案需要您先停止執行個體，然後再啟動。當您停止執行個體時，執行個體儲存體磁碟區中的資料將會遺失。如果您的執行個體沒有 EBS 支援的磁碟區，請在停止執行個體之前備份您的資料。此外，在您停止並重新啟動執行個體後，執行個體的公有 IPv4 位址可能會變更。若要保留相同的公有 IPv4 位址，請使用彈性 IP 位址。如需詳細資訊，請參閱停止並啟動 Amazon EC2 執行個體。

作業系統啟動失敗

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

EBS 磁碟區無法正確掛載

掛載點故障可能會導致執行個體狀態檢查失敗。

掛載點失敗輸出範例：

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

如需這些錯誤的更多資訊，請參閱為什麼當我嘗試啟動 EC2 Linux 執行個體時，它會進入緊急模式？另請參閱如何對由於作業系統出現問題，而未能通過執行個體狀態檢查的 EC2 Linux 執行個體進行疑難排解？

當您將執行個體類型從 Xen 變更為 Nitro 型的執行個體時，磁碟區掛載可能會失敗。發生掛載失敗的原因是，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 執行個體記憶體和磁碟指標不會傳送至 CloudWatch。如需詳細資訊，請參閱使用 CloudWatch 代理程式收集指標、日誌和追蹤。

若要疑難排解並解決記憶體不足的問題，請將執行個體升級為較大的執行個體類型。或者，將交換儲存裝置新增至執行個體，以減輕記憶體壓力。如需詳細資訊，請參閱如何配置記憶體，以用作 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 執行個體中的 "Kernel panic - not syncing" (核心程序危急 - 未同步) 錯誤？另請參閱在更新阻止 EC2 執行個體重新啟動後，如何還原至已知的穩定核心？

網路故障

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

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

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

Amazon、Amazon Linux 2、Amazon Linux 2023 或 RedHat OS：

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 組態檔案。

根 EBS 磁碟區參數限流

當根 EBS 磁碟區參數受到限流時，執行個體可能會因無法連線且無回應，而無法通過狀態檢查。

當 EBS 磁碟區的每秒讀寫次數 (IOPS) 或輸送量超過已佈建的限制時，可能會發生限流。由於 EBS 磁碟區限流導致效能下降，執行個體可能會變得無回應或無法連線。

若要解決 EBS 磁碟區限流問題，請完成以下步驟：

1. 監控和分析 CloudWatch 指標，例如磁碟區佇列長度、磁碟區讀取/寫入作業、磁碟區讀取/寫入位元組數。如需詳細資訊，請參閱如何使用 CloudWatch 指標計算 Amazon Elastic Block Store (Amazon EBS) 磁碟區提供的平均輸送量和平均 IOPS 數量？
2. 停止並啟動執行個體，或重新啟動執行個體，以暫時解決該問題。
3. 佈建更多 EBS 磁碟區的 IOPS 或輸送量。或者，升級到更適合您工作負載的 EBS 磁碟區類型和大小。如需詳細資訊，請參閱請求 Amazon EBS 磁碟區修改。

相關資訊

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

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

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

狀態檢查的類型