Flah 專案 - 使用 Azure 資源健康狀態監視 Azure 虛擬機器可用性
Azure 資源健康狀態是由 Flash 提供的解決方案。 Flash 是專案的內部名稱，專門用來打造健全、可靠且快速的機制，協助客戶監視虛擬機器 (VM) 的健康情況。
本文涵蓋了使用 Azure 資源健康狀態監視 Azure 虛擬機器可用性的內容。 如需 Flash 解決方案的一般概觀，請參閱 Flash 概觀。
如需其他 Flash 解決方案的專屬文件，請從下列文章中選擇：
Azure 資源健康狀態
此解決方案可使用入口網站，為個別資源進行即時、易操作的健康情況檢查。 透過這項工具，客戶可以在入口網站上快速存取資源健康情況刀鋒視窗，並檢閱 30 天的健康情況檢查歷程記錄，迅速且輕鬆地進行疑難排解。 現有的 Azure 資源健康狀態功能可協助診斷會對 Azure 資源造成影響的服務問題，並取得支援。 此外，也會報告資源目前和過去的健康情況，顯示各個資源無法使用的時間範圍。
然而，我們理解客戶與合作夥伴都希望了解造成潛在技術問題的原因，並改善接收各種問題的通訊方式，包括向監視流程提供資訊、向其他專案關係人解釋問題，以及最終如何通知商務決策。
Azure 資源健康狀態中 VM 問題的根本原因
我們最近提升了資源健康情況體驗，改善與客戶共用的 VM 失敗相關資訊，並進一步提供有關問題根本原因的內容。 現在，客戶不僅能在 VM 可用性受到影響時迅速收到通知，更能在自動化根本原因分析 (RCA) 系統中識別導致 VM 失敗的失敗 Azure 平台元件後，新增根本原因。 下列範例解釋了此工作流程的實際執行情況：
在時間 T1，伺服器機架因為網路問題而離線，導致機架上的 VM 失去連線能力。 有關網路架構的最新可靠性改善措施，將會分享於未來的改善可靠性部落格文章，歡迎關注！
在時間 T2，Azure 的內部監視系統發現無法連線至機架上的 VM，於是開始將受影響的 VM 重新部署至新機架，藉此解決問題。 在此期間，系統會向資源健康情況傳送註釋，通知客戶由於其 VM 目前受到影響，因此無法使用。
在時間 T3，機架頂端交換器、主機和內部監視系統的平台遙測資料會在 RCA 引擎中相互關聯，以得出失敗的根本原因。 計算完成後，RCA 和相關的架構復原建議會一同發佈回資源健康狀態，而客戶可透過實施這些建議，將未來發生影響的可能性降到最低。
雖然初始的停機通知功能已推出數年，根本原因說明則是新增加的功能。 現在，就讓我們詳細了解根本原因是如何得出的。
根本原因分析引擎
以下將詳細說明先前的範例，協助您了解 RCA 引擎的運作方式，以及其背後的技術細節。 適用於 VM 的 RCA 引擎以 Azure 資料總管 (ADX) 為核心，可利用此巨量資料服務分析大量記錄遙測資料。 透過 Azure 資料總管，您可輕鬆分析、結合來自具有 Azure 平台之裝置和服務的大量記錄遙測資料，解譯相互關聯的資訊流，藉此得出各種失敗狀況的根本原因。 最終，便會形成多步驟的資料工程流程：
階段 1：偵測停機時間
根本原因分析的第一個階段，便是定義要執行分析的觸發程序。 由於每次虛擬機器意外重新啟動時，都須判斷根本原因，因此對於虛擬機器而言，觸發程序是 VM 從執行狀態轉換到關閉狀態。 在大多數情況下，要從平台遙測資料識別這些轉換相當簡單，但在某些類型的基礎結構失敗中，平台遙測資料可能會因為裝置故障或斷電而遺失，導致操作起來較為複雜。 若要處理這些失敗類別，則必須使用其他技術，例如追蹤資料遺失，以做為 VM 可用性轉換的可能指示。 在時間序列分析方面，Azure 資料總管表現優異，而有關此流程的相關技術詳情，請在 Microsoft Tech 社群中參閱在 Azure 資料總管使用視窗與時間序列函式計算停機時間。
階段 2：相互關聯分析
定義觸發程序事件之後 (在此案例中，即 VM 轉換為狀況不良的狀態)，下一階段是相互關聯分析。 此步驟會使用觸發程序事件，將來自 Azure 平台各點的遙測資料相互關聯，例如：
- Azure 主機：裝載 VM 的實體刀鋒伺服器。
- TOR：機架頂端 (Top of Rack) 交換器。
- Azure 儲存體：裝載 Azure 虛擬機器虛擬磁碟的服務。
每個系統都有各自的遙測資料摘要，必須對其進行剖析，並將其與 VM 停機觸發程序事件相互關聯。 在此流程中，首先必須了解 VM 的相依性關係圖，以及可能導致 VM 失敗的基礎系統，然後聯結所有相依系統的健康情況遙測資料，並根據 VM 狀態轉換的時間，篩選出發生時間點相近的事件。 Azure 資料總管的查詢語言簡單易用、功能強大，提供具有記載可供查閱的模式 (例如 時間範圍聯結)，以將暫存遙測資料流相互關聯。 相互關聯流程結束時，所有相依系統相互關聯的平台遙測資料會組成資料集，表示 VM 停機轉換的狀況。這些相依系統可能會導致 VM 失敗，或具有可用於確定導致 VM 失敗的資訊。
階段 3：根本原因歸因
此流程的下一個步驟是歸因。 既然所有相關資料都已收集到單一資料集，便可套用歸因規則來解譯資訊，並將其轉換為面向客戶的根本原因說明。 如果回到原始的 TOR 失敗範例，經過相互關聯分析後，可能會有許多有趣的資訊可供解譯。 例如，監視 Azure 主機的系統可能會存有記錄，指出這段期間內失去了與主機的連線。 此外，也可能有與虛擬磁碟連線問題相關的訊號，或 TOR 裝置失敗的明確訊號。 此時，這類資訊都已經過掃描，而 TOR 失敗的明確訊號會優先其他訊號，視為根本原因。 此優先順序流程及其背後的規則是由領域專家所建構，並隨著 Azure 平台的發展而修改。 機器學習和異常偵測機制以這些以歸因的根本原因為基礎，可協助找出改善分類規則的機會，並偵測失敗率模式的變化情況，以反饋至安全部署管線。
階段 4：RCA 發佈
最後一個步驟是將根本原因發佈至 Azure 資源健康狀態，以供客戶檢視。 發佈作業可透過簡單的 Azure Functions 應用程式來完成，此應用程式會定期查詢 Azure 資料總管中已處理的根本原因資料，並將結果傳送至資源健康情況後端。 由於資訊流可能會出現各種資料延遲，因此 RCA 偶爾會在此流程中進行更新，以取得更理想的資訊來源，產生比最初發佈內容更具體的根本原因。
未來
識別所有問題的根本原因，並傳達給客戶和合作夥伴知悉，不過是個開始。 客戶可能會需要取得 RCA，並與其客戶和同事共用。 我們希望這項工作能更輕鬆地識別和追蹤資源 RCA，且更易於共用。為了實現這項目標，我們正努力針對後端進行變更，以產生按資源、按停機時間的可公開唯一追蹤 ID，協助客戶輕鬆對照停機時間與 RCA。 我們也致力於開發新功能，協助客戶更輕鬆地透過電子郵件傳送 RCA，並最終為 VM 訂閱 RCA。 這項功能可在事件無法使用後，直接在收件匣中註冊 RCA，無需採取進一步操作。
下一步
若要深入了解提供的解決方案，請參閱相應的解決方案文章：
如需如何監視 Azure 虛擬機器的一般概觀，請參閱監視 Azure 虛擬機器和監視 Azure 虛擬機器的參考資料。