共用方式為

Azure 上任務關鍵性工作負載的健康情況模型化和可觀察性

健康建模和可觀察性是最大化可靠性的基本概念，它側重於強大且情境化的檢測和監控。 這些概念提供了對應用程式運行狀況的重要見解，促進了問題的快速識別和解決。

大多數關鍵任務應用程式在規模和複雜性方面都很重要，因此會產生大量營運數據，這使得評估和確定最佳營運行動變得具有挑戰性。 健康情況建模最終致力於通過增強原始監控日誌和指標和關鍵業務需求來量化應用程序健康情況，推動健康狀態的自動化評估，以實現一致和快速的操作，從而最大限度地提高可觀測性。

此設計領域專注於定義健全健康模型的過程，透過可觀察性和操作結構映射量化的應用健康狀態，以達到操作成熟度。

這很重要

本文是 Azure Well-Architected 任務關鍵性工作負載 系列的一部分。 如果您不熟悉本系列，建議您從 什麼是任務關鍵性工作負載開始？

在努力最大限度地提高可靠性時，操作成熟度主要分為三個級別。

  1. 在問題發生時偵測並回應。
  2. 診斷 正在發生或已經發生的問題。
  3. 在問題發生之前預測並預防問題。

影片：為您的使命關鍵負載定義健康模型

分層應用程式健康情況

若要建置健康情況模型，請先以分層且可測量的格式量化「狀況良好」和「狀況不良」狀態，在關鍵業務需求的內容中定義應用程式健康情況。 然後，針對每一個應用程式元件，在穩定執行狀態的內容中精簡定義，並根據應用程式使用者流程進行彙總。 與效能和可用性的關鍵非功能性業務需求疊加。 最後，彙總每個個別使用者流程的健康情況狀態，以形成整體應用程式健康情況的可接受表示法。 一旦建立，這些分層健康定義就應用於通知所有系統組件的關鍵監控指標並驗證操作子系統組成。

這很重要

在定義「不健康」狀態時，需涵蓋應用程式所有層級。 請務必區分暫時性和非暫時性失敗狀態，以便界定服務降級與無法使用之間的關係。

設計考量

  • 建立健康情況模型的程式是由上而下的設計活動，從架構練習開始，以定義所有使用者流程，並在功能和邏輯元件之間對應相依性，進而隱含地對應 Azure 資源之間的相依性。

  • 健康模型完全取決於它所代表的解決方案的上下文，因此無法「開箱即用」地解決，因為「一刀切並不適合所有人」。

    • 應用程式的組成和相依性會有所不同
    • 資源的度量和度量閾值也必須根據哪些值代表狀況良好和狀況不良的狀態進行微調，這些狀態受到包含的應用程式功能和目標非功能需求的嚴重影響。

  • 分層健康情況模型可讓應用程式健康情況追溯至較低層級的相依性，這有助於快速解決服務降級的根本原因。

  • 若要擷取個別元件的健康情況狀態，必須在反映生產負載的穩定狀態下瞭解該元件的獨特作業特性。 因此，效能測試是定義和持續評估應用程式健康情況的關鍵功能。

  • 雲端解決方案中的故障可能不會孤立地發生。 單一元件中斷可能會導致數個功能或其他元件無法使用。

    • 此類錯誤可能無法立即觀察到。

設計建議

  • 將可測量的健康情況模型定義為優先順序，以確保對整個應用程式的操作有清晰的了解。

    • 健康模式應該分層並反映應用程式結構。
    • 基礎層應該考慮個別應用程式元件，例如 Azure 資源。
    • 基礎元件應與關鍵的非功能性需求一起匯總，以建立系統流程健康情況的業務情境化視角。
    • 系統流程應該根據業務重要性以適當的權重彙總，以建立整體應用程式健康情況的有意義的定義。 應優先考慮具有重大財務價值或面向客戶的使用者流程。
    • 健康模式的每一層都應該擷取「健康」和「不健康」狀態所代表的內容。
    • 請確定健康模型可以區分暫時性和非暫時性不健康狀態，以將服務降級與無法使用的情況隔離。

  • 透過彙總對應相依元件的健康情況分數，將關鍵非功能需求視為係數，使用每個不同應用程式元件和每個使用者流程的細微健康情況分數來代表健康狀態。

    • 使用者流程的健康評分應以所有對應元件中的最低分數來展現，並將使用者流程非功能需求的相對達成狀況納入考量。
    • 用於計算健康分數的模型必須一致地反映運營健康情況，如果沒有，則應調整和重新部署模型以反映新的學習。
    • 定義健康情況分數閾值以反映健康情況狀態。

  • 健康情況分數必須根據基礎指標自動計算，這些指標可以透過可觀察性模式視覺化，並透過自動化操作程序採取行動。

    • 健康情況分數應該成為監視解決方案的核心，讓營運團隊不再需要解譯營運數據並將其對應至應用程式健康情況。

  • 採用健康模型來計算可用性服務等級目標 (SLO) 的達成率，而非依賴原始可用性數據，以確保服務降級與不可用率能夠分別反映為個別的 SLO。

  • 在 CI/CD 管線和測試週期內使用健康情況模型，來驗證在程式碼和設定更新之後維護應用程式健康情況。

    • 健康情況模型應該用來在負載測試和混沌測試期間觀察和驗證健康情況，作為 CI/CD 程式的一部分。

  • 建置和維護健康情況模型是一個反覆的程式，工程投資應該保持一致，以推動持續改善。

    • 定義一個程序來持續評估和微調模型的準確性，並考慮投資機器學習模型以進一步訓練模型。

範例 - 分層健康情況模型

這是分層應用程式健康情況模型的簡化表示法，以供說明之用。 Mission-Critical 參考實作中提供完整且具上下文關聯的健康模型：

實作健康情況模型時，請務必透過匯總和解釋關鍵資源層級計量來定義個別元件的健康情況。 如何使用資源計量的範例如下圖所示：

任務關鍵健康定義範例

此健康情況定義隨後可以由 KQL 查詢表示，如下列範例查詢所示，該查詢會匯總 InsightsMetrics （容器深入解析） 和 AzureMetrics （AKS 叢集的診斷設定），並將 （內部聯結） 與模型化健康情況閾值進行比較。

// ClusterHealthStatus
let Thresholds=datatable(MetricName: string, YellowThreshold: double, RedThreshold: double) [
    // Disk Usage:
    "used_percent", 50, 80,
    // Average node cpu usage %:
    "node_cpu_usage_percentage", 60, 90,
    // Average node disk usage %:
    "node_disk_usage_percentage", 60, 80,
    // Average node memory usage %:
    "node_memory_rss_percentage", 60, 80
    ];
InsightsMetrics
| summarize arg_max(TimeGenerated, *) by Computer, Name
| project TimeGenerated,Computer, Namespace, MetricName = Name, Value=Val
| extend NodeName = extract("([a-z0-9-]*)(-)([a-z0-9]*)$", 3, Computer)
| union (
    AzureMetrics
    | extend ResourceType = extract("(PROVIDERS/MICROSOFT.)([A-Z]*/[A-Z]*)", 2, ResourceId)
    | where ResourceType == "CONTAINERSERVICE/MANAGEDCLUSTERS"
    | summarize arg_max(TimeGenerated, *) by MetricName
    | project TimeGenerated, MetricName, Namespace = "AzureMetrics", Value=Average
    )
| lookup kind=inner Thresholds on MetricName
| extend IsYellow = iff(Value > YellowThreshold and Value < RedThreshold, 1, 0)
| extend IsRed = iff(Value > RedThreshold, 1, 0)
| project NodeName, MetricName, Value, YellowThreshold, IsYellow, RedThreshold, IsRed

產生的資料表輸出隨後可以轉換為健康情況分數，以便在健康情況模型的較高層級上更輕鬆地彙總。

// ClusterHealthScore
ClusterHealthStatus
| summarize YellowScore = max(IsYellow), RedScore = max(IsRed)
| extend HealthScore = 1-(YellowScore*0.25)-(RedScore*0.5)

這些彙總分數隨後可以使用 Grafana 等視覺化工具表示為相依性圖表來說明健康模型。

此影像顯示來自 Azure Mission-Critical 線上參考實作的分層健康情況模型範例，並示範基礎元件健康情況狀態的變更如何對使用者流程和整體應用程式健康情況產生串聯影響 （範例值對應至上圖中的數據表）。

關鍵任務範例 健康模型視覺化

示範影片：監視和健康情況模型示範

統一資料匯集用於相關分析

必須從所有系統元件收集許多作業資料集，才能準確代表已定義的健康情況模型，並考慮來自應用程式元件和基礎 Azure 資源的記錄和計量。 這些大量數據最終需要以允許近乎實時解釋的格式存儲，以促進快速的運營行動。 此外，需要所有包含的資料集之間的相關性，以確保有效分析是無限的，從而允許健康分層表示。

需要統一的資料接收器，以確保所有操作資料都能快速儲存並可用於相關分析，以建立應用程式健康情況的「單一窗格」表示。 Azure 在 Azure 監視器保護傘下提供數種不同的作業技術，而 Log Analytics 工作區可作為核心 Azure 原生資料接收，以儲存和分析作業資料。

關鍵任務健康數據收集

設計考量

Azure 監視器

  • 預設會針對所有 Azure 訂用帳戶啟用 Azure 監視器，但必須部署和設定 Azure 監視器記錄 （Log Analytics 工作區） 和 Application Insights 資源，以納入資料收集和查詢功能。

  • Azure 監視器支援三種類型的可觀測性資料：記錄、計量和分散式追蹤。

    • 記錄會儲存在 Log Analytics 工作區中，以 Azure 資料總管為基礎。 記錄查詢儲存在可跨訂用帳戶共用的查詢套件中，並用來驅動可觀察性元件，例如儀表板、活頁簿或其他報告和視覺化工具。
    • 指標儲存在內部時間序列資料庫中。 對於大部分的 Azure 資源，計量會自動收集並 保留 93 天。 計量資料也可以使用資源的 診斷設定 傳送至 Log Analytics 工作區。

  • 所有 Azure 資源都會公開記錄和度量，但必須適當設定，以便將診斷資料路由至您所需的資料匯集處。

小提示

Azure 提供各種 Built-In 原則 ，可套用來確保已部署的資源設定為將記錄和計量傳送至 Log Analytics 工作區。

  • 法規控制要求作業資料保留在原始地理位置或國家/地區內的情況並不少見。 法規要求可能會規定將關鍵資料類型保留較長時間。 例如，在受監管的銀行業中，審計資料必須保留至少七年。

  • 不同的作業資料類型可能需要不同的保留期間。 例如，安全日誌可能需要保留很長時間，而效能資料不太可能需要在 AIOps 內容之外長期保留。

  • 可以將資料從 Log Analytics 工作區 封存 或 匯出，以便進行長期保存和/或稽核。

  • 專用叢集 提供部署選項，可讓可用性區域免於支援的 Azure 區域中的區域性失敗。 專用叢集需要最低每日資料擷取承諾。

  • Log Analytics 工作區會部署至指定的 Azure 區域。

  • 若要防止 Log Analytics 工作區無法使用而遺失資料，可以使用多個診斷設定來設定資源。 每個診斷設定都可以將計量和記錄傳送至個別的 Log Analytics 工作區。

    • 傳送至每個額外 Log Analytics 工作區的資料會產生額外費用。
    • 備援 Log Analytics 工作區可以部署至相同的 Azure 區域，或部署至個別的 Azure 區域，以取得額外的區域備援。
    • 將記錄和計量從 Azure 資源傳送至不同區域中的 Log Analytics 工作區，會產生區域間資料輸出成本。
    • 某些 Azure 資源需要與資源本身相同的區域內的 Log Analytics 工作區。
    • 如需 Log Analytics 工作區的進一步可用性選項，請參閱 Azure 監視器記錄的最佳做法 。

  • Log Analytics 工作區資料 可以連續、排程或一次性匯出至 Azure 儲存體或 Azure 事件中樞。

    • 資料匯出允許長期資料歸檔，並防止因不可用而可能遺失的營運資料。
    • 可用的匯出目的地是 Azure 儲存體或 Azure 事件中樞。 Azure 儲存體可以針對不同的 備援層級 進行設定，例如區域性或區域備援。 將資料匯出至 Azure 儲存體會將資料儲存在 .json 檔案內。
    • 資料匯出目的地必須與 Log Analytics 工作區位於相同的 Azure 區域內。 事件中樞資料匯出目的地要位於與 Log Analytics 工作區相同的區域內。 Azure 事件中樞異地災害復原不適用於此案例。
    • 有數個 資料匯出限制。 只有 工作區中的特定資料表支援 資料匯出。
    • 封存 可用來將資料儲存在 Log Analytics 工作區中，以較低的成本長期保留，而不需要匯出資料。

  • Azure 監視器日誌具有 使用者查詢節流限制，這可能會導致客戶端的可用性降低，例如可觀測性儀表板。

    • 每個使用者五個並行查詢：如果五個查詢已經在執行中，則會將其他查詢放在每個使用者並行佇列中，直到執行中的查詢結束為止。
    • 並行佇列中的時間：如果查詢在並行佇列中停留超過三分鐘，則會終止並傳回 429 錯誤碼。
    • 並發佇列深度限制：並發佇列限制為200個查詢，額外的查詢將被拒絕，並顯示429錯誤碼。
    • 查詢速率限制：所有工作區的每個使用者限制為每 30 秒 200 個查詢。

  • 查詢套件 是 Azure Resource Manager 資源，可用來在 Log Analytics 工作區無法使用時保護和復原記錄查詢。

    • 查詢套件包含 JSON 格式的查詢，而且可以儲存在 Azure 外部，類似於其他基礎結構即程式碼資產。
      • 可透過 Microsoft.Insights REST API 進行部署。
      • 如果必須重新建立 Log Analytics 工作區，則可以從外部儲存的定義重新部署查詢套件。

  • Application Insights 可以部署在工作區型部署模型中，並以儲存所有資料的 Log Analytics 工作區為基礎。

  • 您可以在 Application Insights 內啟用取樣，以減少傳送的遙測數量，並將資料擷取成本優化。

  • Azure 監視器收集的所有資料 （包括 Application Insights） 都會根據擷取的資料量和資料保留的持續時間來 收費 。

    • 擷取至 Log Analytics 工作區的資料最多可保留前 31 天 （如果已啟用 Sentinel，則為 90 天），無需額外付費
    • 內嵌至工作區型 Application Insights 的資料會在前 90 天保留，不收取額外費用。

  • Log Analytics 承諾層定價模型可降低成本，並採用可預測的資料擷取費用方法。

    • 任何高於保留層級的用量都會以與目前層級相同的價格計費。

  • Log Analytics、Application Insights 和 Azure 資料探索器會使用 Kusto 查詢語言（KQL）。

  • Log Analytics 查詢會儲存為 Log Analytics 工作區內的 函式 （savedSearches）。

設計建議

  • 使用 Log Analytics 工作區作為統一的資料匯集點，以便提供跨所有作業資料集的統一檢視。

    • 將 Log Analytics 工作區分散到所有已使用的部署區域。 每個具有應用程式部署的 Azure 區域都應該考慮 Log Analytics 工作區，以收集源自該區域的所有作業資料。 所有全域資源都應該使用個別的專用 Log Analytics 工作區，該工作區應該部署在主要部署區域內。
      • 將所有作業資料傳送至單一 Log Analytics 工作區會建立單一失敗點。
      • 資料落地的需求可能會禁止資料離開原始區域，而同盟工作區預設會解決此需求。
      • 跨區域傳輸日誌和指標會產生大量輸出成本。
    • 相同區域內的所有部署戳記都可以使用相同的區域 Log Analytics 工作區。

  • 請考慮將資源配置成具有多個診斷設定，這些設定指向不同的 Log Analytics 工作區，以防止因為應用程式的區域部署範圍較少，而導致 Azure Monitor 無法正常運作。

  • 使用 Application Insights 做為跨所有應用程式元件的一致應用程式效能監視 （APM） 工具，以收集應用程式記錄、計量和追蹤。

    • 在工作區型設定中部署 Application Insights，以確保每個區域 Log Analytics 工作區都包含來自應用程式元件和基礎 Azure 資源的記錄和計量。

  • 使用 跨工作區查詢 ，在不同工作區之間維護統一的「單一窗格」。

  • 使用 查詢套件 來保護工作區無法使用時的記錄查詢。

    • 將查詢套件儲存在應用程式 git 存放庫內，做為基礎結構即程式碼資產。

  • 所有 Log Analytics 工作區都應該被視為長時間執行的資源，其生命週期與區域部署戳記中的應用程式資源不同。

  • 從 Log Analytics 工作區匯出重要作業資料，以進行長期保留和分析，以促進 AIOps 和進階分析，以精簡基礎健康情況模型，並為預測動作提供資訊。

  • 仔細評估應該使用哪些資料存放區進行長期保留;並非所有資料都必須儲存在經常性且可查詢的資料存放區中。

    • 強烈建議您在 GRS 設定中使用 Azure 儲存，以進行長期作業資料儲存。
      • 使用 Log Analytics 工作區匯出功能，將所有可用的資料來源匯出至 Azure 儲存體。

  • 在 Log Analytics 中為作業資料類型選取適當的保留期間，並在存在「經常性」可觀察性需求的工作區內設定較長的保留期間。

  • 使用 Azure 原則 來確保所有區域資源都會將作業資料路由傳送至正確的 Log Analytics 工作區。

備註

部署至 Azure 登陸區域時，如果需要集中儲存作業資料，您可以在初始化時分支資料，以便將資料擷取至集中式工具和專用於應用程式的 Log Analytics 工作區。 或者，公開應用程式 Log Analytics 工作區的存取權，讓中央小組可以查詢應用程式資料。 最終，源自解決方案的作業資料可在專用於應用程式的 Log Analytics 工作區內使用，這一點至關重要。

如果需要 SIEM 整合，請勿傳送原始記錄項目，而是傳送重要警示。

  • 只有在需要最佳化效能時，才在 Application Insights 內設定取樣，或如果不需要取樣成本過高。

    • 過度採樣可能會導致操作訊號遺失或不準確。

  • 針對所有追蹤事件和日誌訊息使用相互關聯 ID，將它們與給定的要求繫結。

    • 將所有呼叫的關聯ID傳回給調用者，而不只是失敗的請求。

  • 確保應用程式程式碼包含適當的檢測和記錄，以通知健康情況模型，並在需要時促進後續故障排除或根本原因分析。

    • 應用程式程式碼應該使用 Application Insights 來促進 分散式追蹤，方法是在發生失敗時為呼叫端提供包含相互關聯識別碼的完整錯誤訊息。

  • 對所有日誌訊息使用 結構化記錄 。

  • 將有意義的健康情況探查新增至所有應用程式元件。

    • 使用 AKS 時，請設定每個部署 （Pod） 的健康情況端點，讓 Kubernetes 可以正確判斷 Pod 何時狀況良好或狀況不良。
    • 使用 Azure App Service 時，請設定 健康檢查，讓擴展操作不會因流量被傳送至尚未準備就緒的執行個體而產生錯誤，並確保不健康的執行個體能被快速回收。

如果應用程式已訂閱 Microsoft Mission-Critical 支援，請考慮將重要健康情況探查公開給 Microsoft 支援，以便 Microsoft 支援可以更精確地建立應用程式健康情況模型。

  • 記錄成功的健康檢查請求，除非在應用程式效能的範疇內無法容忍增加的資料量，因為它們為分析建模提供了額外的見解。

  • 請勿將生產 Log Analytics 工作區設定為套用 每日上限，這會限制作業資料的每日擷取，因為這可能會導致重要作業資料遺失。

    • 在較低的環境中，例如開發和測試，可以將每日上限視為一種可選的成本節約機制。

  • 如果作業資料擷取量符合最低層級的閾值，請將 Log Analytics 工作區設定為使用承諾層級定價，以提升相對於「隨用隨付」定價模型的成本效率。

  • 強烈建議使用原始檔控制來儲存 Log Analytics 查詢，並使用 CI/CD 自動化將它們部署至相關的 Log Analytics 工作區執行個體。

可視化

使用關鍵操作數據直觀地表示健康模型對於實現有效運營和最大限度地提高可靠性至關重要。 最終應利用儀表板為 DevOps 團隊提供對應用程式健康狀況的近乎即時的洞察，從而促進快速診斷與穩定狀態的偏差。

Microsoft 提供數種資料視覺化技術，包括 Azure 儀表板、Power BI 和 Azure Managed Grafana （目前為預覽版）。 Azure 儀表板的定位是為 Azure 監視器內的操作數據提供緊密整合的即用視覺化解決方案。 因此，它在關鍵任務工作負載的操作數據和應用程序運行狀況的可視化表示中發揮著重要作用。 不過，將 Azure 儀表板定位為整體可觀察性平臺還有數項限制，因此應考慮補充使用市場上領先的可觀察性解決方案，例如 Grafana，它也是作為 Azure 內提供的受控解決方案。

本節著重於使用 Azure 儀錶板和 Grafana 來建置強大的儀錶板體驗，能夠為應用程式健康情況提供技術和商務視角，讓 DevOps 小組和有效作業成為可能。 強大的儀表板對於診斷已經發生的問題以及支援營運團隊在問題發生時偵測和回應問題至關重要。

設計考量

  • 使用記錄查詢視覺化健康情況模型時，請注意， 並行查詢和佇列查詢以及整體查詢速率有 Log Analytics 限制，後續查詢會排入佇列並節流。

  • 擷取用來計算和表示健康情況分數的作業資料的查詢，可以在 Log Analytics 或 Azure 資料總管中撰寫和執行。

  • Log Analytics 會施加數 個查詢限制，在設計作業儀錶板時必須針對這些限制進行設計。

  • 原始資源指標（例如 CPU 使用率或網路輸送量）的視覺化需要營運團隊手動評估，以確定健康狀態影響，這在活動事件期間可能具有挑戰性。

  • 如果多個使用者在 Grafana 等工具中使用儀錶板，則傳送至 Log Analytics 的查詢數目會迅速成倍增加。

    • 達到 Log Analytics 的並行查詢限制會將後續查詢排入佇列，讓儀錶板體驗感覺「緩慢」。

設計建議

  • 收集並呈現來自所有區域 Log Analytics 工作區和全域 Log Analytics 工作區的查詢輸出，以建置應用程式健康情況的統一檢視。

備註

如果部署至 Azure 登陸區域，請考慮在平臺資源上存在重要相依性時查詢 中央平臺 Log Analytics 工作區 ，例如用於內部部署通訊的 ExpressRoute。

  • 「交通號誌」模型應用於直觀地表示「健康」和「不健康」狀態，綠色用於說明何時完全滿足關鍵非功能性需求並最佳利用資源。 使用「綠色」、「琥珀色」和「紅色」來表示「狀況良好」、「已降級」和「無法使用」狀態。

  • 使用 Azure 儀表板來建立全域資源和區域部署標籤的操作視角，呈現關鍵計量，例如 Azure Front Door 的要求計數、Azure Cosmos DB 的伺服器端延遲、Event Hubs 的傳入/傳出訊息，以及 AKS 的 CPU 使用率或部署狀態。 儀表板應進行客製化以提高營運效率，注入從故障場景中吸取的經驗教訓，以確保 DevOps 團隊能夠直接了解關鍵指標。

  • 如果 Azure 儀錶板無法用來準確代表健康情況模型和必要的商務需求，則強烈建議您考慮將 Grafana 視為替代視覺效果解決方案，提供市場領先的功能和廣泛的開放原始碼外掛程式生態系統。 評估受管 Grafana 預覽產品，以避免管理 Grafana 基礎設施的操作複雜性。

  • 部署自我託管 Grafana 時，請採用高可用性和地理分佈式設計，以確保關鍵操作平台儀表板能夠抵禦區域平台故障和級聯錯誤情境。

    • 將組態狀態分隔成外部資料存放區，例如適用於 Postgres 的 Azure 資料庫或 MySQL，以確保 Grafana 應用程式節點保持無狀態。

      • 跨部署區域設定資料庫複寫。

    • 使用容器型部署，以跨區域內的高可用性設定將 Grafana 節點部署至 App Services。

      • 在考慮的部署區域中部署 App Service 實例。

      App Services 提供低摩擦的容器平台，非常適合小規模案例，例如作業儀錶板，而將 Grafana 與 AKS 隔離，可在主要應用程式平台與該平台的作業表示法之間明確區隔關注點。 請參閱「Application Platform」設計區域以取得進一步的組態建議。

    • 在 GRS 設定中使用 Azure 儲存體來裝載和管理自訂視覺效果和外掛程式。

    • 將應用程式服務和資料庫僅供讀取複本 Grafana 元件部署至至少兩個部署區域，並考慮採用將 Grafana 部署至所有考慮部署區域的模型。

對於以 = 99.99% SLO 為目標的 >案例，Grafana 應部署在至少 3 個部署區域內，以最大化關鍵作業儀表板的整體可靠性。

  • 藉由將查詢彙總成單一或少量查詢 （例如使用 KQL 'union' 運算子） 來減輕 Log Analytics 查詢限制，並在儀錶板上設定適當的重新整理頻率。

    • 適當的最大重新整理率將取決於儀表板查詢的數量和複雜性;需要分析已實現的查詢。

  • 如果達到 Log Analytics 的並行查詢限制，請考慮將儀錶板所需的資料 （暫時） 儲存在高效能資料存放區 （例如 Azure SQL） 中，以最佳化擷取模式。

自動化事件回應

雖然應用程式健康情況的視覺化表示提供了寶貴的營運和業務見解來支援問題偵測和診斷，但它依賴於營運團隊的準備情況和解釋，以及後續人為觸發回應的有效性。 因此，為了最大限度地提高可靠性，有必要實施廣泛的警報，以近乎即時地主動偵測和回應問題。

Azure 監視器 提供廣泛的警示架構，可透過 動作群組偵測、分類及回應作業訊號。 因此，本節將著重於使用 Azure 監視器警示來驅動自動化動作，以回應目前或可能偏離狀況良好的應用程式狀態。

這很重要

警示和自動化動作對於有效偵測問題並迅速回應問題至關重要，以免造成更大的負面影響。 警示也提供一種機制來解譯傳入訊號並做出回應，以防患於未然。

設計考量

  • 警示規則定義為在滿足傳入訊號的條件條件時觸發，其中可能包括各種 資料來源，例如度量、日誌查詢或可用性測試。

  • 警示可以在特定資源的 Log Analytics 或 Azure 監視器中定義。

  • 某些計量只能在 Azure 監視器內進行詢問，因為並非所有診斷資料點都可在 Log Analytics 中使用。

  • Azure 監視器警示 API 可用來擷取作用中和歷史警示。

  • 有與警示和動作群組相關的訂用帳戶限制，這些限制必須針對下列專案進行設計：

    • 可配置警示規則的數目存在限制。
    • 警示 API 有 節流限制，在極端使用案例中應考慮此限制。
    • 動作群組對可配置回應的數目有 數個硬性限制 ，必須針對這些限制進行設計。
      • 每種回應類型限制為 10 個動作，但電子郵件除外，電子郵件限制為 1,000 個動作。

  • 警示可以整合到分層健康情況模型中，方法是從模型的「根」評分函式為已儲存的記錄搜尋查詢建立警示規則。 例如，使用 'WebsiteHealthScore' 並針對代表「狀況不良」狀態的數值發出警示。

設計建議

  • 針對以資源為中心的警示，請在 Azure 監視器內建立警示規則，以確保所有診斷資料都可用於警示規則準則。

  • 將自動化動作整合到最少數量的行動群組中，並與服務團隊保持一致，以支援 DevOps 方法。

  • 透過自動化調整作業回應過多的資源使用率訊號，並儘可能使用 Azure 原生自動調整功能。 如果內建的自動調整功能不適用，請使用元件健康情況分數來建立訊號模型，並判斷何時使用自動調整作業回應。 確保根據容量模型定義自動化調整作業，該模型會量化元件之間的調整關係，以便調整回應包含需要相對於其他元件進行調整的元件。

  • 範例動作以適應優先順序，這應根據業務影響來決定。

  • 使用 Azure 監視器警示 API 來收集歷程警示，以合併在「冷」作業儲存體中，以進行進階分析。

  • 對於無法透過自動回應解決的關鍵失敗案例，請確保作業「運行手冊自動化」已就緒，以便在提供手動解釋和簽核後推動快速且一致的行動。 使用警報通知來快速識別需要手動解釋的問題

  • 在工程衝刺中預留資源，以推動警報的漸進式改進，確保能完全容納先前未考慮的新故障場景到新的自動化措施中。

  • 在 CI/CD 程序中進行作業整備測試，以驗證部署更新的關鍵警示規則。

預測動作和 AI 作業 （AIOps）

機器學習模型可用於關聯營運資料並確定其優先順序，有助於收集與過濾過多警報「噪音」和在問題造成影響之前預測問題相關的關鍵見解，以及在事件造成影響時加速事件回應。

更具體地說，AIOps 方法可以應用於有關系統、使用者和 DevOps 流程行為的關鍵見解。 這些見解可以包括識別現在發生的問題（檢測）、量化問題發生的原因（診斷）或發出未來將發生的情況的信號（預測）。 這類深入解析可用來驅動調整和最佳化應用程式的動作，以減輕作用中或潛在問題，使用關鍵業務指標、系統品質指標和 DevOps 生產力指標，根據業務影響排定優先順序。 已執行的動作本身可以透過回饋循環注入系統，進一步訓練底層模型以提高效率。

關鍵任務 AIOps 方法

Azure 內有多種分析技術，例如 Azure Synapse 和 Azure Databricks，可用來建置和定型 AIOps 的分析模型。 因此，本節將重點放在應用程序設計中如何定位這些技術，以適應 AIOps 並推動預測操作，重點關注 Azure Synapse，通過將最好的 Azure 數據服務與強大的新功能結合在一起來減少摩擦。

AIOps 用於推動預測行動，解釋和關聯持續一段時間內觀察到的複雜操作信號，以便在問題發生之前更好地響應和預防問題。

設計考量

  • Azure Synapse Analytics 提供多種機器學習 （ML） 功能。

    • ML 模型可以在 Synapse Spark 集區上定型和執行，其中包含 MLLib、SparkML 和 MMLSpark 等程式庫，以及熱門的開放原始碼程式庫，例如 Scikit Learn。
    • ML 模型可以使用 PySpark/Python、Scala 或 .NET 等常見資料科學工具進行訓練。

  • Synapse Analytics 透過 Azure Synapse Notebooks 與 Azure ML 整合，可讓 ML 模型使用 自動化 ML 在 Azure ML 工作區中進行定型。

  • Synapse Analytics 也會使用 Azure 認知服務 來啟用 ML 功能，以解決各種網域中的一般問題，例如 異常偵測。 認知服務可用於 Azure Synapse、Azure Databricks，以及透過用戶端應用程式中的 SDK 和 REST API。

  • Azures Synapse 原生與 Azure Data Factory 工具整合，用於在編排工作流程中進行資料擷取、轉換和載入（ETL），或導入資料。

  • Azure Synapse 可將外部資料集註冊至儲存在 Azure Blob Storage 或 Azure Data Lake Storage 中。

    • 已註冊的資料集可用於 Synapse Spark 集區資料分析工作。

  • Azure Databricks 可以整合到 Azure Synapse Analytics 管線中，以取得其他 Spark 功能。

    • Synapse 會協調讀取資料，並將資料傳送至 Databricks 叢集，可在其中轉換資料，並準備進行 ML 模型定型。

  • 來源資料通常需要為分析和 ML 做好準備。

    • Synapse 提供各種工具來協助資料準備，包括 Apache Spark、Synapse Notebooks 和具有 T-SQL 和內建視覺效果的無伺服器 SQL 集區。

  • 已定型、操作化和部署的 ML 模型可用於 Synapse 中的 批次 評分。

    • AIOps 情境，例如在 CI/CD 管線中執行迴歸或降級預測，可能需要 即時評分計算。

  • Azure Synapse 有訂閱限制，應在 AIOps 方法論中充分瞭解。

  • 若要完全整合 AIOps，必須持續將近乎即時的可觀測性資料饋送至即時 ML 推論模型。

    • 異常偵測等功能應在可觀測性資料串流中進行評估。

設計建議

  • 請確定所有 Azure 資源和應用程式元件都已完全檢測，以便完整的作業資料集可用於 AIOps 模型定型。

  • 將 Log Analytics 作業資料從全域和區域 Azure 儲存體帳戶內嵌至 Azure Synapse 進行分析。

  • 使用 Azure 監視器警示 API 來擷取歷程記錄警示，並將其儲存在冷儲存體中，以便作業資料後續在 ML 模型中使用。 如果使用 Log Analytics 資料匯出，請將歷程記錄警示資料儲存在與匯出的 Log Analytics 資料相同的 Azure 儲存體帳戶中。

  • 內嵌的資料準備好進行 ML 定型之後，請將它寫回 Azure 儲存體，以便可用於 ML 模型定型，而不需要執行 Synapse 資料準備計算資源。

  • 確保 ML 模型操作化支援批次和即時評分。

  • 建立 AIOps 模型時，實作 MLOps 並套用 DevOps 實務，以 自動化 ML 生命週期 ，以進行訓練、操作化、評分和持續改進。 為 AIOps ML 模型建立反覆 CI/CD 程序。

  • 評估特定預測案例的 Azure 認知服務 ，因為它們的系統管理和整合額外負荷較低。 考慮異常 偵測 ，以快速標記可觀察性資料串流中的意外差異。

後續步驟

檢閱部署和測試考量。

部署和測試

  • Last updated on