某公司在 Amazon EC2 實例上運行多個生產(chǎn)工作負(fù)載。管理員發(fā)現(xiàn)個生產(chǎn) EC2 實例未能通過系統(tǒng)運行狀況檢查。管理員手動恢復(fù)了該實例。管理員希望只要系統(tǒng)運行狀況檢查失敗，就會自動完成 EC2 實例的恢復(fù)任務(wù)并且會收到通知。公司的所有生產(chǎn) EC2 實例都激活了詳細(xì)監(jiān)控。
以下哪項是能夠滿足這些要求的最具運營效率的解決方案？
A. 對于每個生產(chǎn) EC2 實例，針對“狀態(tài)檢查失敗：系統(tǒng)”創(chuàng)建 Amazon CloudWatch 警報。將警報操作設(shè)置為恢復(fù) EC2 實例。配置發(fā)布到 Amazon Simple Notification Service (Amazon SNS) 主題的警報通知。
B. 在每個生產(chǎn) EC2 實例上創(chuàng)建一個腳本，通過每分鐘將心跳通知發(fā)布到中央監(jiān)控服務(wù)器來監(jiān)控系統(tǒng)運行狀況。如果某個 EC2 實例未能發(fā)送心跳信號，則在監(jiān)控服務(wù)器上運行腳本來停止并啟動該 EC2 實例，并將通知發(fā)布到 Amazon Simple Notification Service (Amazon SNS) 主題。
C. 在每個生產(chǎn) EC2 實例上，創(chuàng)建一個腳本，通過 cron 作業(yè)將網(wǎng)絡(luò) ping 發(fā)送到高度可用的終端節(jié)點上。如果該腳本檢測到網(wǎng)絡(luò)響應(yīng)超時，則調(diào)用一個命令來重啟 EC2 實例。
D. 在每個生產(chǎn) EC2 實例上，配置 Amazon CloudWatch 代理來收集日志并將其發(fā)送到 Amazon CloudWatch Logs 中的日志組。創(chuàng)建一個基于跟蹤錯誤的指標(biāo)篩選條件的 CloudWatch 警報。配置警報來調(diào)用 AWS Lambda 函數(shù)，以重啟 EC2 實例并發(fā)送通知電子郵件。
A
技巧：排除明顯錯誤選項，在沒有明顯錯誤的選項中選擇最合理的選項。
在這個問題中，我們需要找到一個解決方案，該方案能夠在 Amazon EC2 實例的系統(tǒng)運行狀況檢查失敗時自動恢復(fù)實例，并向 SysOps 管理員發(fā)送通知。同時，考慮到所有生產(chǎn) EC2 實例都啟用了詳細(xì)監(jiān)控，我們可以利用 AWS 提供的原生服務(wù)和功能來實現(xiàn)這一需求。
A. 正確。該方案直接利用了 AWS 的 CloudWatch 和 SNS 服務(wù)。CloudWatch 可以監(jiān)控 EC2 實例的狀態(tài)檢查，并在檢測到失敗時觸發(fā)警報。警報可以配置為自動執(zhí)行恢復(fù)操作（如重啟實例），并通過 SNS 發(fā)送通知。這是一個高效且直接利用 AWS 原生服務(wù)的方法。Amazon CloudWatch 警報操作來創(chuàng)建自動停止、終止、重啟或恢復(fù) Amazon EC2 實例的警報。假如某個實例由于物理主機上的硬件或軟件問題、網(wǎng)絡(luò)連接丟失或系統(tǒng)停電而受損，CloudWatch 警報 可以自動啟動恢復(fù)操作以將實例遷移到新硬件，同時還可以配置發(fā)布到 Amazon Simple Notification Service (Amazon SNS) 主題的消息，以接收相關(guān)事件的通知。
B. 不正確。不恰當(dāng)?shù)倪x項。該方案需要額外的腳本和中央監(jiān)控服務(wù)器，增加了系統(tǒng)的復(fù)雜性和維護成本。此外，手動停止和啟動實例可能導(dǎo)致數(shù)據(jù)丟失或服務(wù)中斷，不如 CloudWatch 的自動恢復(fù)功能可靠。
C. 不正確。不恰當(dāng)?shù)倪x項。該同樣依賴于自定義腳本和 cron 作業(yè)，缺乏 AWS 原生服務(wù)的可靠性和集成性。此外，僅通過 ping 來判斷實例狀態(tài)可能不夠準(zhǔn)確，因為網(wǎng)絡(luò)問題不一定意味著實例本身有問題。
D. 不正確。不合理的選項。該方案依賴于日志分析來觸發(fā)警報，而不是直接監(jiān)控系統(tǒng)狀態(tài)檢查。這可能導(dǎo)致警報延遲或錯過一些狀態(tài)檢查失敗的情況。而且發(fā)送電子郵件通知不如使用 SNS 服務(wù)準(zhǔn)確可靠。