AWS-EC2主機異常，檢測內核崩潰問題?執行個體狀態檢查未通過的故障診斷

AWS-EC2檢測內核崩潰問題 

有一台機器原本連線正常，但是之後發現線路全部不通，沒有做什麼操作，要怎麼排除是什麼問題造成?

 

在實例發生異常時，可以先檢查以下兩個指標，確認是由哪一種狀況所引起的，此兩種異常是不同的場景造成，關於實例狀態檢查可以透過

1.      StatusCheckFailed_System。系統狀態檢查經控實例上某個運行的AWS系統。這些檢查會檢測出需要AWS參與修復的深層實例問題。如果系統狀態檢查失敗，可以選擇等待AWS修復問題，也可以自行解決問題，對於由Amazon EBS支持的實例，也可以選擇自行停止或者啟動。在大多數的情況下，這會導致實例被遷移至新主機。對於由實例儲存的Linux系統，可以終止並替換實例。對於Windows系統，根捲必須是Amazon EBS捲；根捲不支持實例儲存。實例儲存捲是臨時的，實例停止後所有數據都會丟失。

 

2.      StatusCheckFailed_Instance- 實例狀態檢查用於監控各個實例的軟件和網路配置。Amazon EC2 通過向網路街口(NIC) 發送地址解析協議(ARP) 請求，檢查實例的運行情況。這些檢查檢測需要親自參予修復的問題。如果實例狀態檢查失敗，通常必須親自手動解決問題(例如: 重啟實例或更改實例配置)透過內部工具確認，此實例發生不預期的故障，可以從CloudWatch指標”StatusCheckFailed_System”查看

經初步判斷Instance reachability check failed 這個錯誤通常是APP層的問題，透過內部工具Cloud Watch此實例硬件在稍早有發生不預期性的故障，這邊可以透過Cloud Watch查看指標'StatusCheckFailed_System'

 

(StatusCheckFailed_System圖)

 

由於底層監控有偵測到底層主機異常，主動遷移了此實例，此實例被重啟，發生了內核崩潰的異常，這個可以透過實例的控制台輸出查看

 

[2.860227] rtc_cmos 00:00: setting system clock to 2021-11-24 10:08:01 UTC (1637749999) [3.919154] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

 

解決方法: /boot/grub/grub.conf 或 /boot 目录中缺少 initramfs 或 initrd 映像

方法 1：使用 EC2 串行控制台

方法 2：使用救援实例

 

最後重新設定AMI解決此問題。

 

AMI (Amazon Machine Images)

AMI，其實就是映像檔(Image)，它可以將目前的EC2做快速的複製；Auto Scaling（自動擴展）就是搭配這個功能來完成的；另外，我們一開始在建立的EC2時，選擇系統的部份也是用到了AMI功能。

 

參考資料:

內和崩潰AWS文件:

https://aws.amazon.com/cn/premiumsupport/knowledge-center/ec2-linux-kernel-panic-unable-mount/?nc1=h_ls

 

AMI介紹:

https://akuma1.pixnet.net/blog/post/294451990-%EF%BC%88%E4%B8%83%EF%BC%89ami%EF%BC%88amazon-machine-images%EF%BC%89%EF%BC%8D%EF%BC%8Daws%E7%B6%93%E9%A9%97%E6%95%99%E5%AD%B8

 

CloudWatch介紹:

https://aws.amazon.com/tw/cloudwatch/

執行個體狀態檢查未通過的故障診斷

https://docs.aws.amazon.com/zh_tw/AWSEC2/latest/UserGuide/TroubleshootingInstances.html