工作負載的健康情況模型
雲端應用程式會產生大量的作業數據，因此很難快速找出並解決問題。 這項挑戰的常見原因是缺少針對工作負載功能自定義的健康情況基準，以及無法偵測該基準的漂移。
健康情況模型化是一種可觀察性練習，結合了商務內容與原始監視數據，以量化工作負載的整體健康情況。 它有助於設定您可以監視工作負載的基準。 您應該考慮來自基礎結構和應用程式元件的遙測等數據。 健康情況模型可能也會納入達成工作負載質量目標所需的其他資訊。
效能問題或作業降低可能會導致預期作業狀態的漂移。 藉由將工作負載的健康情況模型化，您可以識別漂移，並做出明智的作業決策，以考慮業務影響。
健康模型化可橋接部落操作知識與可採取動作的見解之間的差距。 它可協助您有效地管理重大問題。 概念對於最大化可靠性和操作效率至關重要。
本指南提供健康情況模型化的實際指引，包括如何建置模型，以評估工作負載及其所有子系統的運行時間健康情況。
| 詞彙 | 定義 |
|---|---|
| 健康度建模 | 使用商務內容將監視數據解譯為健康情況狀態的可觀察性練習。 |
| 健全狀況模型 | 邏輯實體的圖形表示法，以及指定範圍的關聯性。 每個節點都有健全狀況狀態定義，可合理化整個模型的監視數據。 |
| 健全狀況實體 | 邏輯元件，表示系統的個別單位、多個相關實體或整體系統的邏輯組合。 |
| 健全狀態 | 已定義且可測量的狀態，可提供實體健康情況的有意義操作見解。 |
| 健康情況訊號 | 提供實體作業行為的見解的個別數據流。 |
| 模型模型 | 匯總的模型範圍，其中實體代表元件系統的不同健康情況模型。 |
建議您觀看這段影片，以深入瞭解健康情況模型化。
什麼是健康情況、健康情況模型和健康情況模型？
健康情況一詞是指實體及其相依性的作業狀態。 該實體可以是系統的個別單位、多個相關實體或整體系統的邏輯組合。
建議您在三種狀態之一中代表健康情況：
狀況良好：以最佳方式運作並符合質量預期
降級：表現出低於健康行為，這表示潛在問題
狀況不良：處於危急狀態，需要立即注意
注意
您可以使用分數來代表健康情況，而不是狀態，以提供更多數據粒度。
健康情況狀態是藉由結合監視數據與網域資訊來衍生。 每個狀態都必須定義，而且必須可測量。 健康情況狀態是使用 健康情況訊號來計算，這是提供實體作業行為的見解的個別數據流。 訊號可以包含計量、記錄、追蹤或其他品質特性。 例如，虛擬機 （VM） 實體的健康情況訊號可能會追蹤 CPU 使用率計量。 此實體的其他訊號可能包括記憶體使用量、網路等待時間或錯誤率。
當您定義健康情況訊號時，請考慮工作負載的非功能需求。 在 CPU 使用率的範例中，包含每個健康情況狀態的預期臨界值。 如果使用率根據工作負載需求超過容許的臨界值，系統就會從 狀況良好 轉換為 降級 或 狀況不良。 這些狀態變更會觸發適當的警示或動作。
健康情況模型化需要實體具有定義完善的狀態，這些狀態衍生自多個健康情況訊號，並針對工作負載進行內容化。 例如，VM 的健康情況定義可能是：
狀況良好：完全滿足關鍵非功能需求和目標，例如響應時間、資源使用率和整體系統效能。 例如，95% 的要求會在 500 毫秒內處理。 工作負載會以最佳方式使用 VM 資源，例如 CPU、記憶體和記憶體，並維持工作負載需求與可用容量之間的平衡。 用戶體驗在預期的層級。
降級：資源未以最佳方式執行，但仍可運作。 例如，記憶體磁碟發生節流問題。 使用者可能會遇到回應緩慢的問題。
狀況不良：降低超出容許的限制。 資源不再回應或可用，而且系統不再符合可接受的效能等級。 用戶體驗受到嚴重影響。
健康情況模型化的結果是 邏輯實體的模型 或圖形表示法，以及工作負載架構的關聯性。 每個節點都有健康情況狀態定義。
重要
健康情況模型 化是一個抽象的概念，如果您對商務案例有很好的瞭解，您可以在不同的範圍實作和套用。
在影像中：
實體 是代表系統層面之工作負載的邏輯元件。 它們可以是基礎結構元件，例如伺服器、資料庫和網路。 它們也可以是特定的應用程式模組、Pod、服務或微服務。 或者，實體可以擷取工作負載內的用戶互動和系統流程。
注意
使用者和系統流程摘要說明涉及應用程式和基礎結構元件之商務案例的非功能性需求。 此摘要會反映應用程式的商務價值。
實體之間的關聯 性會鏡像系統中的相依性鏈結。 例如，應用程式模組可能會呼叫構成 關聯性的特定基礎結構元件。
假設電子商務工作負載在 Azure 服務匯流排 佇列上遇到失敗訊息尖峰的情況，導致付款失敗。 由於隱含的收入損失，這個問題對於組織而言非常重要。 雖然應用程式開發人員可能會瞭解此計量對付款的影響，但此部落知識通常不會在整個營運小組中共用。
健康情況模型可讓操作員立即了解問題及其效果。 付款流程取決於 服務匯流排，這是其中一個工作負載元件。 視覺表示法會顯示 服務匯流排 實例的降級狀態，以及其對付款流程的影響。 操作員可以了解問題的重要性，並專注於該特定元件的補救工作。
健康情況模型化在上述案例中很重要，方法如下：
它藉由啟用更快速的問題隔離來改善偵測時間（TTD）和緩和時間，進而加快問題偵測和潛在修正。
操作員根據健康情況狀態收到警示，這降低了不必要的雜訊。 操作員收到通知，該通知提供有關業務對付款影響的特定內容。
相依性鏈結協助操作員完全了解作業問題的程度。 這項知識加速了影響評估，並導致優先回應。 運算元也可以輕鬆地識別串聯或相互關聯的問題。
操作員以正確性進行事件後活動，因為健康情況模型提供異常的根本原因和涉及的特定健康訊號的深入解析。
它讓監視數據對所有小組成員都有意義。 它彌合了部落知識與分享見解之間的差距。
組織使用健康情況模型作為未來 AI 驅動作業投資的基準，以衍生智慧型手機深入解析。
健全狀況模型架構
健康情況模型提供針對可觀察性使用案例優化的相異數據架構。 此架構會將健康情況模型化從抽象概念到可測量的解決方案。 藉由將特定需求、目標和架構內容模型化，您可以針對唯一案例量身打造健康情況數據。
健康情況是相對數據概念。 每個模型都代表其內容範圍唯一且優先的健全狀況數據，即使它使用相同的實體集也一樣。 在特定案例中構成 狀況良好 的情況在其他內容中可能會有很大的差異。
例如，請考慮工作負載內相同類型的 Azure 資源。
- VM A 會執行 CPU 敏感性應用程式。
- VM B 會處理需要大量記憶體的服務。
這些機器的健康情況定義不同。 CPU 使用率計量可能會影響 VM A 的健康情況狀態，而 VM B 可能會優先處理記憶體相關計量。
重要
健康情況模型不應該將所有失敗都視為相同。 它應該清楚地區分預期或暫時性但可復原的失敗和真正的災害狀態。
建置健康情況模型
建置健康情況模型的第一個步驟是邏輯設計練習，這通常涉及下列各節所述的活動。
評估您的工作負載設計
評估工作負載設計的下列元件，以開始此邏輯設計練習。
計算叢集和資料庫等基礎結構元件
在計算上執行的應用程式元件及其相關元件
元件之間的邏輯或實體相依性
例如，電子商務應用程式的健全狀況模型應該代表使用者登入、結帳和付款等重要程式的目前狀態。
使用商務需求內容化
評估每個流程對貴組織的相對重要性和整體影響。 請考慮用戶體驗、安全性和營運效率等因素。 例如，在大部分情況下，付款程序的失敗可能比報告程序失敗更重要。
識別處理每個流程相關問題的呈報路徑。 如需詳細資訊，請參閱 使用流程優化工作負載設計。
注意
只有在納入商務案例和內容時，您才能實現健康情況模型化的價值。 然後，您可以從作業問題合理化業務影響。
對應至可靠性計量
在整個應用程式設計中尋找相關的 可靠性計量 。
請考慮針對整個應用程式和個別的商務程式定義服務等級指標 （SLA） 和服務等級目標 。 這些 SLI 和 SLO 應符合針對健康情況模型考慮的特定健康情況訊號。 如此一來，您就會建立健全狀況的完整定義，以準確地反映應用程式可接受的服務等級。
重要
SLI 和 SLO 是重要的健康情況訊號。 它們會建立有意義的健康狀態定義，以反映您想要的服務等級以及其他質量屬性。 您也可以定義服務健康情況目標 （SHO），以擷取您想要在匯總時間範圍內取得的健康情況。
識別健康情況訊號
若要建置完整的健康情況模型，請將各種類型的監視數據相互關聯，包括計量、記錄和追蹤。 如此一來，您可確保健康情況的概念能準確地反映特定實體或整個工作負載的運行時間狀態。
使用平台計量和記錄
在健康情況模型化的內容中，從基礎 Azure 資源收集平臺層級計量和記錄至關重要。 這些計量包括 CPU 百分比、網路進出網路，以及每秒的磁碟作業。 您可以在健康情況模型中使用此數據來偵測並預測潛在問題，同時維護可靠的環境。
此外，此方法可協助您區分暫時性錯誤或暫時中斷，以及非轉移錯誤或持續性問題。
注意
最佳做法是，您應該設定所有應用程式資源，將診斷記錄和計量導向所選記錄匯總技術。 使用 Azure 原則 建置防護，以確保整個應用程式的診斷設定一致，並針對每個 Azure 服務強制執行所選組態。
新增應用程式記錄
應用程式記錄是健康情況模型診斷數據的重要來源。 以下是應用程式記錄的一些最佳做法：
使用語意或結構化記錄。 結構化記錄有助於大規模自動取用和分析記錄數據。
請考慮將 Azure 資源計量和診斷數據儲存在 Azure 監視器記錄工作區中，而不是記憶體帳戶。 藉由 使用此方法，您可以使用 Kusto 查詢 來建立健康情況訊號，以有效率地進行評估。
在生產環境中記錄數據。 當應用程式在生產環境中運作時，擷取完整的數據。 足夠的信息對於健康情況評估至關重要，並診斷任何偵測到的生產問題。
記錄服務界限的事件。 包含周遊服務界限的相互關聯標識碼。 如果交易涉及多個服務，其中一個服務失敗，相互關聯標識符可協助您追蹤整個應用程式的要求，並找出失敗的原因。
使用異步記錄。 避免可能會封鎖應用程式程式代碼的同步記錄作業。 異步記錄可確保在記錄寫入期間防止要求待辦專案的可用性。
將應用程式記錄與稽核分開。 與診斷記錄分開維護稽核記錄。 雖然稽核記錄提供合規性或法規需求，但保留它們會避免卸除的交易。
實作分散式追蹤
透過將遙測相互關聯至重要系統流程，以實作分散式追蹤。 相互關聯的遙測提供端對端交易的深入解析，對於發生失敗時的有效根本原因分析 （RCA） 至關重要。
使用健全狀態探查
實作並執行應用程式外部的健康情況探查，以明確檢查應用程式的健康情況和回應性。 使用探查回應作為健康情況模型中的訊號。
您可以藉由測量整個應用程式的回應時間，或從其個別元件來實作健康情況探查。 探查可以執行程式來測量延遲和檢查可用性，或從應用程式擷取資訊。 如需詳細資訊，請參閱 健全狀況端點監視模式。
大部分的負載平衡器都支援執行健康情況探查，以在設定的間隔偵測應用程式端點。 或者，您可以使用外部監視程序服務。 監視程式服務會從工作負載中的多個元件匯總健康情況檢查。 監看程式也可以裝載可立即補救已知健康情況的程序代碼。
採用結構和功能監視技術
結構監視牽涉到為應用程式配備語意記錄和計量。 應用程式會直接收集這些計量，其中包括目前的記憶體耗用量、要求延遲和其他相關的應用層級數據。
使用功能監視來加強監視程式。 此方法著重於測量平台服務，以及其對整體用戶體驗的影響。 不同於結構監視，功能監視不需要系統的詳細知識。 它會測試應用程式的外部可見行為。 此方法適用於評估 SLO 和 SLI。
建立設計模型
將識別的應用程式設計表示為實體和關聯性。 將健康情況訊號對應至特定元件，以量化實體層級的健康情況狀態。 請考慮元件的關鍵性，以判斷健康情況狀態應該如何透過模型傳播。 例如，報告元件可能不像其他元件那麼重要，這會導致整體工作負載健康情況產生不同的影響。
設定可採取動作的警示
使用評估的健康情況狀態來觸發警示和自動化動作。 健康情況應該整合在現有的作業 Runbook 中，作為核心可觀察性數據原則。
一般而言，監視數據和警示規則之間會有一對一的對應，這可能會導致不想要的結果，例如警示風暴和環境警示雜訊。 例如，在計算叢集中，以CPU使用率和錯誤計數為基礎的大量VM層級警示在失敗期間可能會使操作員不知所措，並導致解決延遲。 同樣地，當有大量已設定的警示時，環境警示雜訊通常會導致被忽略或忽略的警示。
健康情況模型引進了監視數據和警示規則之間的分隔。 健康狀態定義會將許多訊號匯總成單一健康狀態，這樣會減少警示數目，讓操作員只能專注於對組織而言至關重要的高價值警示。 請考慮電子商務案例。 您可以設定警示，以傳送流程付款流程健康情況變更的相關通知，而不是 服務匯流排 佇列等基礎資源的變更。
注意
跨健康情況模型的所有層級發出警示的能力，可為不同的工作負載角色提供彈性。 應用程式擁有者和產品經理可以在關鍵商務案例或整個工作負載中收到健康狀態變更的警示。 操作員可以根據基礎結構或應用程式元件的健康情況發出警示。
將模型可視化
建立可視化表示法，例如數據表或圖形，以有效傳達健康情況模型的目前狀態和歷程記錄。 請確定視覺效果與商務內容一致，並提供可採取動作的深入解析。
當您將健康情況模型可視化時，請考慮採用 交通燈 方法，讓健康情況狀態立即跨相依性鏈結深入解析。
將綠色指派給狀況良好、已降級的琥珀色，並針對狀況不良指派紅色。 藉由快速識別色彩編碼狀態，您可以有效率地找出任何應用程式降低的根本原因。
注意
建議您在為健康情況模型建立儀錶板時，針對有視力障礙的人員考慮輔助功能需求。 如需圖表最佳做法，請參閱 架構設計圖表。
採用您的健康情況模型
建置健全狀況模型之後，請考慮下列使用案例來推動偵測和解譯失敗或操作問題。
各種角色的適用性
健康情況模型可以提供工作函式或工作負載相同內容中角色特有的資訊。 例如，DevOps 角色可能需要操作健康情況資訊。 安全人員可能更關心入侵訊號和安全性暴露。 資料庫管理員可能只對透過資料庫資源的應用程式模型子集感興趣。
為不同的項目關係人量身打造健康見解。 請考慮從重疊數據集建立不同的模型。
持續驗證
使用您的健康情況模型來優化測試和驗證程式，例如負載測試和混亂測試。 您可以將健康情況模型併入工程生命週期，在測試期間驗證運行時間作業狀態，並評估模型在規模和失敗案例中的有效性。
組織健康情況
雖然健康情況模型通常與量化個別應用程式的健康情況狀態相關聯，但其適用性會延伸到該範圍之外。
在個別工作負載層級，健康情況模型為應用程式可觀察性和操作見解提供了基礎。 每個應用程式都可以有自己的健康情況模型，以擷取每個健康狀態在其內容中的意義。
您可以藉由建 置模型模型，將多個健康情況模型合併成高階建構。 例如，您可以使用健康情況模型作為較大模型中的元件，來建置業務單位或整個雲端資產的可觀察性使用量。 健康情況模型代表資產內的工作負載，做為最上層圖形內的節點。 使用此模型中的關聯性來擷取應用程式間相依性，包括數據流、服務互動和共用基礎結構。
請考慮擁有各種電子商務、付款和訂單處理應用程式的零售公司。 您可以將每個應用程式定義為獨立的健康情況模型，以量化該工作負載的健康情況代表的意義。 然後，您可以使用父模型將所有這些元件健康情況模型對應為實體，並透過相依性鏈結擷取應用程式間作業影響。 例如，如果電子商務應用程式變成狀況不良，它就會對付款應用程式產生串聯效果。
適用於IT作業的健康情況趨勢和 AI
健康情況模型化提供可調整為特定商務內容的量化作業基準。 AI for IT 作業 （AIOps） 是增強營運效率的熱門方式。 健康情況數據是機器學習模型分析健康情況趨勢的基礎輸入。 例如，機器學習模型可以：
從狀態變更和建議動作擷取更多深入解析。
分析一段時間的健康情況趨勢，以推動問題預測和模型精簡。
維護健康情況模型
維護熱身模型是一種持續工程活動，可配合應用程式的開發和作業。 隨著應用程式的發展，請確定健康情況模型會以平行的方式發展。
此外，將健康情況模型視為應該整合到開發生命週期中的工作負載成品。 採用基礎結構即程序代碼 （IaC），以取得健康情況模型一致的版本控制管理。 使用自動化，讓模型在您新增或移除工作負載中的基礎結構和應用程式元件時保持最新狀態。
健康情況數據會隨著時間逐漸減少價值。 若要將作業效率優化並降低成本，請避免將健康情況數據保留超過 30 天。 如有必要，您可以封存數據以滿足稽核需求，或在 AI 中涉及 IT 作業中長期模式分析的案例中。
注意
當您封存健全狀況數據時，請確定您將它與模型的組態狀態結合在一起。 若沒有此內容，解譯狀態變更可能會很困難。
相關連結
- 如需在 ASP.NET 中實作健康情況探查，請參閱 ASP.NET Core 中的健康情況檢查。
- 如需監視計量的資訊，請參閱 Azure 監視器計量概觀。
- 如需使用Application Insights 的資訊，請參閱 Application Insights。
- 如需與任務關鍵性工作負載相關的設計考慮和建議，請參閱 Azure 上任務關鍵性工作負載的健康情況模型化和可觀察性。
- 如需實際操作體驗，請參閱 為您的任務關鍵性工作負載設計健康情況模型。