共用方式為

工作負載的健康情況模型

  • 發行項

雲端應用程式會產生大量的作業數據，這讓快速找出並解決問題相當困難。 這項挑戰的常見原因是缺少針對工作負載功能自定義的健康情況基準，以及無法偵測該基準的漂移。

健康情況模型化是可觀察性練習，結合了商務內容與原始監視數據，以量化工作負載的整體健康情況。 它有助於設定您可以監視工作負載的基準。 您應該考慮基礎結構和應用程式元件的遙測等數據。 健康情況模型也可能納入達成工作負載質量目標所需的其他資訊。

效能問題或作業降低可能會導致從預期的作業狀態漂移。 藉由將工作負載的健康情況模型化，您可以識別漂移，並做出明智的作業決策，以考慮業務影響。

健康情況模型化可橋接部落作業知識與可採取動作的深入解析之間的差距。 它可協助您有效地管理重大問題。 概念是將可靠性和作業效率最大化的必要概念。

本指南提供健康情況模型化的實際指引，包括如何建置模型，以評估工作負載及其所有子系統的運行時間健康情況。

詞彙 定義
健康情況模型化 使用商務內容的可觀察性練習，將監視數據解譯為健康情況狀態。
健康狀態模型 邏輯實體及其特定範圍的關聯性的圖形表示法。 每個節點都有健全狀況狀態定義，可合理化整個模型的監視數據。
健康情況實體 邏輯元件，代表系統的個別單位、多個相關實體的邏輯組合，或整體系統。
健全狀態 定義且可測量的狀態，可提供實體健康情況的有意義操作見解。
健康情況訊號 提供實體作業行為的見解的個別數據流。
模型的模型 匯總模型範圍，其中實體代表元件系統的不同健康情況模型。

建議您 watch 這段影片，以深入瞭解健康情況模型。

什麼是健康情況、健康情況模型和健康情況模型？

健康 狀態 一詞是指實體及其相依性的作業狀態。 該實體可以是系統的個別單位、多個相關實體的邏輯組合，或整體系統。

建議您以三種狀態的其中一種來表示健康情況：

  • 狀況良好：以最佳方式運作，並符合品質期望

  • 降級：顯示小於狀況良好的行為，這表示潛在的問題

  • 狀況不良：處於重大狀態且需要立即注意

注意

您可以使用分數來代表健康情況，而不是狀態，以提供更多數據粒度。

健康狀態是藉由結合監視數據與網域資訊來衍生。 每個狀態都必須定義，而且必須可測量。 健康情況狀態是使用健康情況 訊號來計算，這是提供實體作業行為的見解的個別數據流。 訊號可以包含計量、記錄、追蹤或其他品質特性。 例如，虛擬機 (VM) 實體的健康情況訊號可能會追蹤 CPU 使用率計量。 此實體的其他訊號可能包括記憶體使用量、網路等待時間或錯誤率。

當您定義健康情況訊號時，請考慮工作負載的非功能需求。 在 CPU 使用率的範例中，包含每個健全狀況狀態的預期閾值。 如果使用率超過根據工作負載需求容許的臨界值，系統就會從狀況良好轉換為降級或狀況不良。 這些狀態變更會觸發適當的警示或動作。

健康情況模型化需要實體具有定義完善的狀態，這些狀態衍生自多個健康情況訊號，並且會針對工作負載進行內容化。 例如，VM 的健康情況定義可能是：

  • 狀況良好：完全滿足關鍵非功能需求和目標，例如響應時間、資源使用率和整體系統效能。 例如，95% 的要求會在 500 毫秒內處理。 工作負載會以最佳方式使用 VM 資源，例如 CPU、記憶體和記憶體，並維持工作負載需求與可用容量之間的平衡。 用戶體驗在預期的層級。

  • 降級：資源不會以最佳方式執行，但仍可運作。 例如，記憶體磁碟發生節流問題。 使用者可能會遇到回應緩慢的問題。

  • 狀況不良：降低超出容許的限制。 資源不再回應或可用，而且系統不再符合可接受的效能等級。 用戶體驗受到嚴重影響。

健康情況模型化的結果是邏輯實體的 模型 或圖形表示法，以及工作負載架構的關聯性。 每個節點都有健康狀態定義。

重要

健康情況模型 化是一個抽象概念，您可以在不同範圍實作並套用，如果您對商務案例有良好的瞭解。

顯示健康情況模型定義的圖表。

在映射中：

  • 實體 是代表系統層面之工作負載的邏輯元件。 它們可以是基礎結構元件，例如伺服器、資料庫和網路。 它們也可以是特定的應用程式模組、Pod、服務或微服務。 或者，實體可以擷取工作負載內的用戶互動和系統流程。

    注意

    使用者和系統流程摘要說明涉及應用程式和基礎結構元件之商務案例的非功能需求。 此摘要反映應用程式的商務價值。

  • 實體之間的關聯性會鏡像系統中的相依性鏈結。 例如，應用程式模組可能會呼叫構成 關聯性的特定基礎結構元件。

假設電子商務工作負載在 Azure 服務匯流排 佇列上遇到失敗訊息尖峰，這會導致付款失敗。 此問題對於組織而言非常重要，因為隱含的營收遺失。 雖然應用程式開發人員可能會瞭解此計量尖峰對付款的影響，但此部落知識通常不會在整個作業小組中共用。

健康情況模型可讓操作員立即看到問題及其效果。 付款流程取決於服務總線，這是其中一個工作負載元件。 視覺表示法會顯示服務總線實例的降級狀態，以及其對付款流程的影響。 操作員可以了解問題的重要性，並專注於該特定元件的補救工作。

在上述案例中，健康情況模型化很重要，方式如下：

  • 它改善偵測 (TTD) 的時間，以及藉由啟用更快速的問題隔離來減輕 TTM) (的時間，進而加快偵測問題和潛在修正程式的速度。

  • 操作員會根據健康狀態收到警示，這可減少不必要的雜訊。 操作員收到通知，該通知提供有關對付款之業務影響的特定內容。

  • 相依性鏈結可協助操作員完全瞭解作業問題的範圍。 這項知識可加速影響評量，並導致優先回應。 運算子也可以輕鬆地識別級聯或相互關聯的問題。

  • 操作員會以精確度進行事件後活動，因為健康情況模型提供異常的根本原因和涉及的特定健康情況訊號的深入解析。

  • 它讓監視數據對所有小組成員都有意義。 它已橋接部落知識與共享見解之間的差距。

  • 組織使用健康情況模型作為未來 AI 驅動作業投資的基準，以衍生智慧型手機深入解析。

健全狀況模型架構

健康情況模型提供針對可觀察性使用案例優化的相異數據架構。 此架構會將健康情況模型化，從抽象概念到可測量的解決方案。 藉由將特定需求、目標和架構內容模型化，您可以針對獨特的案例量身打造健康情況數據。

顯示健全狀況狀態定義的圖表。

健康情況是相對數據概念。 每個模型都代表其內容範圍唯一且優先的健全狀況數據，即使它使用相同的實體集也一樣。 在特定案例中構成 狀況良好的 狀況可能會在其他內容中明顯不同。

例如，請考慮工作負載中相同類型的 Azure 資源。

  • VM A 會執行 CPU 敏感性應用程式。
  • VM B 會處理耗用大量記憶體的服務。

這些機器的健康情況定義不同。 CPU 使用率計量可能會影響 VM A 的健康情況狀態，而 VM B 可能會設定記憶體相關計量的優先順序。

重要

健康情況模型不應該將所有失敗視為相同。 它應該清楚區分預期或暫時性但可復原的失敗和真正的災害狀態。

建置健康情況模型

建置健康情況模型的第一個步驟是邏輯設計練習，這通常牽涉到下列各節中所述的活動。

顯示健康情況模型活動的圖表。

評估工作負載設計

藉由評估工作負載設計的下列元件來開始此邏輯設計練習。

  • 計算叢集和資料庫等基礎結構元件

  • 在計算上執行的應用程式元件及其相關元件

  • 元件之間的邏輯或實體相依性

  • 用戶和系統流程

例如，電子商務應用程式的健全狀況模型應該代表使用者登入、結帳和付款等重要程式目前的狀態。

使用商務需求進行內容化

評估每個流程對貴組織的 相對重要性和整體影響 。 請考慮用戶體驗、安全性和作業效率等因素。 例如，在大部分情況下，付款程式的失敗可能比報告程序的失敗還要重要。

識別處理每個流程相關問題的呈報路徑。 如需詳細資訊，請參閱 使用流程優化工作負載設計。

注意

只有在納入商務案例和內容時，您才瞭解健康情況模型的價值。 然後，您可以從作業問題合理化業務影響。

對應至可靠性計量

在應用程式設計中尋找相關的 可靠性計量 。

請考慮定義服務等級指標， (SLA) 和服務等級目標， (SLO) 整個應用程式和其個別商務程式。 這些 SLA 和 SLO 應該符合針對健康情況模型考慮的特定健康情況訊號。 如此一來，您可以建立完整的健康情況定義，以精確地反映應用程式可接受的服務等級成就。

重要

SLA 和 SLA 是重要的健康情況訊號。 他們會建立有意義的健康情況定義，以反映您想要的服務等級以及其他質量屬性。 您也可以定義服務健康情況目標 (SHO) ，以擷取您想要在匯總時間範圍內取得的健康情況。

識別健康情況訊號

若要建置完整的健康情況模型，請相互關聯各種類型的監視數據，包括計量、記錄和追蹤。 如此一來，您可確保健康情況的概念能精確地反映特定實體或整個工作負載的運行時間狀態。

使用平台計量和記錄

在健康情況模型化的內容中，從基礎 Azure 資源收集平臺層級計量和記錄是不可或缺的。 這些計量包括 CPU 百分比、網路輸入和網路輸出，以及每秒的磁碟作業。 您可以在健康情況模型中使用此數據來偵測及預測潛在問題，同時維護可靠的環境。

此外，此方法可協助您區分暫時性錯誤或暫時性中斷，以及非轉移的錯誤或持續性問題。

注意

最佳做法是，您應該將所有應用程式資源設定為將診斷記錄和計量導向所選記錄匯總技術。 使用 Azure 原則 來建置防護措施，以確保整個應用程式的診斷設定一致，並針對每個 Azure 服務強制執行所選的組態。

新增應用程式記錄

應用程式記錄是您健康情況模型診斷數據的重要來源。 以下是應用程式記錄的一些最佳做法：

  • 使用語意或結構化記錄。 結構化記錄可協助大規模自動取用和分析記錄數據。

    請考慮在 Azure 監視器記錄工作區中儲存 Azure 資源計量和診斷數據，而不是記憶體帳戶。 藉由使用此方法，您可以使用 Kusto 查詢 來建立健康情況訊號，以有效率地評估。

  • 在生產環境中記錄數據。 在應用程式在生產環境中運作時，擷取完整的數據。 足夠的信息對於健康情況評估很重要，並診斷任何偵測到的生產問題。

  • 記錄服務界限的事件。 包含周遊服務界限的相互關聯標識碼。 如果交易牽涉到多個服務，其中一個服務失敗，相互關聯標識符可協助您追蹤整個應用程式的要求，並找出失敗的原因。

  • 使用異步記錄。 避免可能會封鎖應用程式程式代碼的同步記錄作業。 異步記錄可避免在記錄寫入期間要求待辦專案，以確保可用性。

  • 將應用程式記錄與稽核分開。 與診斷記錄分開維護稽核記錄。 雖然稽核記錄提供合規性或法規需求，但保留它們會避免卸除的交易。

實作分散式追蹤

藉由 將遙測相互關聯 到重要系統流程，以實作分散式追蹤。 相互關聯的遙測可提供端對端交易的深入解析，對於發生失敗時，RCA 的有效根本原因分析 (RCA) 至關重要。

使用健全狀態探查

在應用程式外部實作並執行健康情況探查，以明確檢查應用程式的健康情況和回應性。 使用探查回應作為健康情況模型中的訊號。

您可以藉由測量整個應用程式的回應時間，或其個別元件來實作健康情況探查。 探查可以執行進程來測量延遲和檢查可用性，或從應用程式擷取資訊。 如需詳細資訊，請參閱健康情況端點監視模式 \(部分機器翻譯\)。

大部分的負載平衡器都支援執行健康情況探查，以在設定的間隔偵測應用程式端點。 或者，您可以使用外部監視程序服務。 監視程式服務會從工作負載中的多個元件匯總健康情況檢查。 監看程式也可以裝載可立即補救已知健康情況的程序代碼。

採用結構化和功能監視技術

結構化監視牽涉到將應用程式配備語意記錄和計量。 應用程式會直接收集這些計量，包括目前的記憶體耗用量、要求延遲和其他相關的應用層級數據。

使用功能監視來強化監視程式。 此方法著重於測量平台服務，以及其對整體用戶體驗的影響。 不同於結構化監視，功能監視不需要系統的詳細知識。 它會測試應用程式的外部可見行為。 此方法對於評估 SLA 和 SLA 很有用。

建立設計模型

將識別的應用程式設計表示為實體和關聯性。 將健康情況訊號對應至特定元件，以量化實體層級的健康情況狀態。 請考慮元件的關鍵性，以判斷健康狀態應該如何傳播至模型。 例如，報告元件可能與其他元件一樣重要，這會導致整體工作負載健康情況產生不同的影響。

設定可採取動作的警示

使用評估的健康狀態來觸發警示和自動化動作。 健康情況應該整合在現有的作業 Runbook 中，作為核心可觀察性數據原則。

一般而言，監視數據和警示規則之間會有一對一的對應，這可能會導致不想要的結果，例如警示雨和環境警示雜訊。 例如，在計算叢集中，根據CPU使用率和錯誤計數的大量VM層級警示，可能會讓操作員在失敗期間造成負荷，並導致解決延遲。 同樣地，當有大量已設定的警示時，環境警示雜訊通常會導致被忽略或忽略的警示。

健康情況模型會介紹監視數據和警示規則之間的區隔。 健康情況定義會將許多訊號匯總成單一健康狀態，以減少警示數目，讓操作員只能專注於對組織而言非常重要的高價值警示。 請考慮電子商務案例。 您可以設定警示，以傳送處理付款流程健康情況變更的相關通知，而不是服務總線佇列等基礎資源的變更。

注意

在健康情況模型的所有層級上警示的能力，可為不同的工作負載角色提供彈性。 應用程式擁有者和產品經理可以在主要商務案例或整個工作負載中收到健康情況狀態變更的警示。 操作員可以根據基礎結構或應用程式元件的健康情況發出警示。

將模型視覺化

建立可視化表示法，例如數據表或圖形，以有效地傳達健康情況模型的目前狀態和歷程記錄。 請確定視覺效果與商務內容一致，並提供可採取動作的深入解析。

當您以可視化方式呈現健康情況模型時，請考慮採用 交通燈 方法，讓健康狀態在相依性鏈結上立即深入解析。

針對狀況良好、已降級的Amber指派綠色，並針對狀況不良指派紅色。 藉由快速識別色彩編碼狀態，您可以有效率地找出任何應用程式降低的根本原因。

此圖顯示使用交通燈方法的健康情況模型。

注意

建議您在建立健康情況模型的儀錶板時，考慮具有視覺障礙人士的輔助功能需求。 如需圖表最佳做法，請參閱 架構設計圖表。

採用健康情況模型

建置健康情況模型之後，請考慮下列使用案例，以推動偵測和解譯失敗或操作問題。

各種角色的適用性

健康情況模型化可以提供工作功能的特定資訊，或工作負載相同內容中的角色。 例如，DevOps 角色可能需要操作健康情況資訊。 安全性人員可能更擔心入侵訊號和安全性暴露。 資料庫管理員可能只對透過資料庫資源的應用程式模型子集感興趣。

針對不同的項目關係人量身打造健康情況見解。 請考慮建立與重疊數據集不同的模型。

持續驗證

使用健康情況模型來優化測試和驗證程式，例如負載測試和混亂測試。 您可以在測試期間驗證運行時間作業狀態，並藉由將健康情況模型併入您的工程生命週期，以評估模型在規模和失敗案例中的效能。

組織健康情況

雖然健康情況模型通常與量化個別應用程式的健全狀況狀態相關聯，但其適用性會延伸到該範圍之外。

在個別工作負載層級，健康情況模型提供應用程式可觀察性和操作見解的基礎。 每個應用程式都可以有自己的健康情況模型，以擷取每個健康狀態在其內容中的意義。

您可以藉由建置 模型模型，將多個健康情況模型結合成高階建構。 例如，您可以使用健康情況模型作為較大模型中的元件，來建置業務單位或整個雲端資產的可觀察性使用量。 健康情況模型代表資產內的工作負載，做為最上層圖形內的節點。 使用此模型中的關聯性來擷取應用程式間相依性，包括數據流、服務互動和共用基礎結構。

請考慮具有各種電子商務、付款和訂單處理的零售公司。 您可以將每個應用程式定義為獨立的健康情況模型，以量化該工作負載的健康情況意義。 然後，您可以使用父模型，將所有這些元件健康情況模型對應為實體，並透過相依性鏈結擷取應用程式間作業影響。 例如，如果電子商務應用程式變成狀況不良，它就會對付款應用程式產生串聯效果。

健全狀況模型提供可調整為特定商務內容的數量化作業基準。 AI for IT 作業 (AIOps) 是增強作業效率的熱門方式。 健康情況數據是機器學習模型用來分析健康情況趨勢的基礎輸入。 例如，機器學習模型可以：

  • 從狀態變更擷取更多深入解析，並建議動作。

  • 分析一段時間的健康情況趨勢，以推動問題預測和模型精簡。

維護健康情況模型

維護熱度模型是一個持續工程活動，可配合應用程式的開發和作業。 隨著應用程式演進，請確定健康情況模型會以平行方式演進。

此外，將健康情況模型視為工作負載成品，這些成品應該整合到您的開發生命週期中。 採用基礎結構即程式代碼 (IaC) ，以取得健康情況模型一致的版本控制管理。 使用自動化，讓模型在您新增或移除工作負載中的基礎結構和應用程式元件時保持最新狀態。

健康情況數據會隨著時間逐漸降低值。 若要將作業效率優化並降低成本，請避免保留超過 30 天的健康情況數據。 如有必要，您可以封存數據以滿足稽核需求，或在 AI 中涉及 IT 作業長期模式分析的案例中。

注意

當您封存健康情況數據時，請務必將它與模型的組態狀態結合。 若沒有此內容，解譯狀態變更可能很困難。

後續步驟

設計可靠監視和警示策略的建議