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文件:
AMI介紹:
CloudWatch介紹:
https://aws.amazon.com/tw/cloudwatch/
執行個體狀態檢查未通過的故障診斷
https://docs.aws.amazon.com/zh_tw/AWSEC2/latest/UserGuide/TroubleshootingInstances.html
