Share via

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

  • 發行項

健康情況模型化和可檢視性是將可靠性最大化的基本概念，著重于強固且內容相關的檢測和監視。 這些概念提供應用程式健康情況的重要見解，促進問題的快速識別和解決方式。

大部分任務關鍵性應用程式在規模和複雜度方面都很重要，因此會產生大量的作業資料，因此很難評估及判斷最佳的作業動作。 健康情況模型最終會藉由使用關鍵商務需求來增強原始監視記錄和計量，以量化應用程式健康情況，推動健康狀態的自動化評估，以達到一致且加速的作業，以最大化可觀察性。

此設計區域著重于定義健全健康情況模型的程式，透過可觀察性和作業建構來對應數量化應用程式健康情況狀態，以達到作業成熟度。

重要

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

在努力將可靠性最大化時，作業成熟度有三個主要層級。

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

影片：定義任務關鍵性工作負載的健康情況模型

分層應用程式健康情況

若要建置健康情況模型，請先在關鍵商務需求的內容中定義應用程式健康情況，方法是以分層且可測量的格式量化「狀況良好」和「狀況不良」狀態。 然後，針對每個應用程式元件，在穩定執行狀態的內容中精簡定義，並根據應用程式使用者流程進行匯總。 將效能和可用性的重要非功能性商務需求加總。 最後，匯總每個個別使用者流程的健康情況狀態，以形成整體應用程式健康情況的可接受的標記法。 建立之後，應該使用這些分層健全狀況定義來通知所有系統元件的重要監視計量，並驗證操作子系統組合。

重要

定義「狀況不良」狀態時，代表應用程式的所有層級。 請務必區分暫時性和非暫時性失敗狀態，以限定相對於無法使用的服務降低。

設計考量

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

  • 健康情況模型完全相依于它所代表的解決方案內容，因此無法解決「現成可用的」，因為「一個大小不符合全部」。

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

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

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

  • 雲端解決方案內的失敗可能不會隔離發生。 單一元件的中斷可能會導致數個功能或其他元件無法使用。

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

設計建議

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

    • 健康情況模型應該分層並反映應用程式結構。
    • 基礎層應該考慮個別的應用程式元件，例如 Azure 資源。
    • 基礎元件應與關鍵非功能性需求一起匯總，以建置商務內容化鏡頭，以建置系統流程的健康情況。
    • 系統流程應根據業務重要性來匯總適當的權數，以建置有意義的整體應用程式健康情況定義。 財務顯著或面向客戶的使用者流程應該優先處理。
    • 健康情況模型的每一層都應該擷取「狀況良好」和「狀況不良」狀態所代表的內容。
    • 確定熱度模型可以區分暫時性和非暫時性狀況不良狀態，以隔離服務降低與無法使用。

  • 藉由匯總對應相依元件的健康情況分數，將關鍵非功能性需求視為係數，以針對每個相異應用程式元件和每個使用者流程使用細微健康情況分數來表示健康情況狀態。

    • 使用者流程的健康情況分數應該以所有對應元件的最低分數來表示，根據使用者流程的非功能需求來考慮相對措施。
    • 用來計算健康情況分數的模型必須一致地反映作業健康情況，如果不是，則應該調整並重新部署模型以反映新的學習。
    • 定義健康情況分數閾值以反映健全狀態。

  • 健康情況分數必須根據基礎計量自動計算，其可透過可檢視模式視覺化，並透過自動化作業程式採取行動。

    • 健康情況分數應成為監視解決方案的核心，讓作業小組不再需要解譯作業資料，並將作業資料對應至應用程式健康情況。

  • 使用健康情況模型來計算可用性服務等級目標 (SLO) ，而不是原始可用性，確保服務降低與無法使用之間的分隔會反映為個別的 SLO。

  • 使用 CI/CD 管線和測試週期內的健全狀況模型，在程式碼和組態更新之後驗證應用程式健康情況。

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

  • 建置和維護健康情況模型是反復的程式，工程投資應配合以推動持續改善。

    • 定義持續評估和微調模型精確度的程式，並考慮投資機器學習模型以進一步定型模型。

範例 - 分層健康情況模型

這是分層應用程式健康情況模型的簡化標記法，以供說明之用。 Mission-Critical 參考實作中提供完整的內容化健康情況模型：

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

任務關鍵性範例健康情況定義任務

此健康情況定義後續可由 KQL 查詢表示，如下列範例查詢所示範，該查詢會匯總 InsightsMetrics (Container Insights) 和 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 Data Explorer為基礎。 記錄查詢會儲存在可跨訂用帳戶共用的查詢套件中，並用來驅動可檢視性元件，例如儀表板、活頁簿或其他報告和視覺效果工具。
    • 計量會儲存在內部時間序列資料庫中。 針對大部分的 Azure 資源，計量會自動收集並 保留 93 天。 計量資料也可以使用資源的 診斷設定 傳送至 Log Analytics 工作區。

  • 所有 Azure 資源都會公開記錄和計量，但資源必須適當地設定為將診斷資料路由傳送至您想要的資料接收。

提示

Azure 提供各種內 建原則 ，可套用以確保已部署的資源已設定為將記錄和計量傳送至 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，都會根據擷取的資料量，以及保留資料的持續時間 來收費 。

    • 如果已啟用 Sentinel，則擷取到 Log Analytics 工作區的資料最多可以保留 31 天 (90 天)
    • 擷取到工作區型 Application Insights 的資料會保留前 90 天，不需額外費用。

  • Log Analytics 承諾用量層定價模型提供較低的成本和可預測的資料擷取費用方法。

    • 保留層級上方的任何使用量會以與目前層相同的價格計費。

  • Log Analytics、Application Insights 和 Azure Data Explorer會使用 Kusto 查詢語言 (KQL) 。

  • Log Analytics 查詢會儲存為 Log Analytics 工作區中的 函 式， (savedSearches) 。

設計建議

  • 使用 Log Analytics 工作區做為統一的資料接收，為所有運算元據集提供「單一窗格」。

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

  • 請考慮使用指向不同 Log Analytics 工作區的多個診斷設定來設定資源，以防止具有較少區域部署戳記的應用程式無法使用 Azure 監視器。

  • 在所有應用程式元件中使用 Application Insights 作為一致的應用程式效能監視 (APM) 工具來收集應用程式記錄、計量和追蹤。

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

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

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

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

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

  • 從 Log Analytics 工作區匯出重要的作業資料以進行長期保留和分析，以協助 AIOps 和進階分析精簡基礎健康情況模型，並通知預測性動作。

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

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

  • 針對記錄分析內的作業資料類型選取適當的保留期限，並在存在「經常性」可觀察性需求的工作區內設定較長的保留期間。

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

注意

部署至 Azure 登陸區域時，如果需要集中儲存作業資料，您可以在具現化時分 叉 資料，使其內嵌至應用程式專用的集中式工具和 Log Analytics 工作區。 或者，公開對應用程式 Log Analytics 工作區的存取權，讓中央小組可以查詢應用程式資料。 最後，源自解決方案的運算元據在專用於應用程式的 Log Analytics 工作區內是重要的。

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

  • 只有在需要將效能優化時，或在非取樣變成成本禁止的情況下，才在 Application Insights 中設定取樣。

    • 過度取樣可能會導致作業訊號遺失或不正確。

  • 針對所有追蹤事件和記錄訊息使用相互關聯識別碼，將它們系結至指定的要求。

    • 針對所有呼叫，將相互關聯識別碼傳回給呼叫端，而不只是失敗的要求。

  • 請確定應用程式程式碼會納入適當的檢測和記錄，以通知健康情況模型，並在必要時進行後續的疑難排解或根本原因分析。

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

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

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

    • 使用 AKS 時，請針對每個部署設定健康情況端點， (Pod) ，讓 Kubernetes 能夠正確判斷 Pod 狀況良好或狀況不良。
    • 使用Azure App 服務時，請設定健康情況檢查，讓相應放大作業不會因為將流量傳送到尚未就緒的實例而造成錯誤，並確保狀況不良的實例會快速回收。

如果應用程式已訂閱 Microsoft Mission-Critical 支援，請考慮將關鍵健康情況探查公開給Microsoft 支援服務，因此應用程式健康情況可以透過Microsoft 支援服務更精確地建立模型。

  • 記錄成功的健康情況檢查要求，除非應用程式效能內容中無法容許增加的資料磁片區，因為它們提供分析模型的額外見解。

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

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

  • 提供的作業資料擷取磁片區符合最低層級閾值，請設定 Log Analytics 工作區，以使用承諾層型定價來推動相對於「隨用隨付」定價模式的成本效益。

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

視覺效果

以視覺化方式表示具有重要作業資料的健全狀況模型，是達到有效作業並最大化可靠性的必要條件。 儀表板最終應該用來為 DevOps 小組提供應用程式健康情況的近乎即時見解，以利快速診斷與穩定狀態的偏差。

Microsoft 提供數種資料視覺效果技術，包括 Azure 儀表板、Power BI 和 Azure 受控 Grafana (目前預覽) 。 Azure 儀表板是用來為 Azure 監視器內的作業資料提供緊密整合的現成視覺效果解決方案。 因此，對於任務關鍵性工作負載的作業資料和應用程式健康情況，其具有視覺標記法的基本角色。 不過，在將 Azure 儀表板定位為整體可觀察性平臺方面有數個限制，因此應該考慮使用領先市場之可觀察性解決方案的補充用途，例如 Grafana，亦即 Azure 中的受控解決方案。

本節著重于使用 Azure 儀表板和 Grafana 來建置強大的儀表板體驗，以提供技術和商務鏡頭到應用程式健康情況、啟用 DevOps 小組和有效作業。 健全的儀表板是診斷已發生的問題，並支援操作小組偵測和回應問題。

設計考量

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

  • 擷取用來計算及表示健康情況分數的查詢，可以在 Log Analytics 或 Azure Data Explorer中寫入和執行。

  • Log Analytics 會強制執行數個 查詢限制，這在設計操作儀表板時必須設計。

  • 原始資源計量的視覺效果，例如 CPU 使用率或網路輸送量，需要由作業小組手動評估，以判斷健康狀態影響，這在作用中事件期間可能很困難。

  • 如果多個使用者使用 Grafana 之類的工具內的儀表板，則傳送至 Log Analytics 的查詢數目會快速乘以。

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

設計建議

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

注意

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

  • 「交通燈」模型應該用來以視覺化方式表示「狀況良好」和「狀況不良」狀態，而綠色用來說明關鍵非功能需求何時已完全滿足，且資源會以最佳方式使用。 使用 「綠色」、「Amber」和「紅色」來代表「狀況良好」、「降級」和「無法使用」狀態。

  • 使用 Azure 儀表板來建立全域資源和區域部署戳記的操作鏡頭，代表關鍵計量，例如 Azure Front Door 的要求計數、Azure Cosmos DB 的伺服器端延遲、事件中樞的傳入/傳出訊息，以及 AKS 的 CPU 使用率或部署狀態。 儀表板應量身打造，以推動營運效率，並運用失敗案例的學習，以確保 DevOps 小組能直接查看關鍵計量。

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

  • 部署自我裝載 Grafana 時，採用高可用性和異地分散式設計，以確保重要的作業儀表板可以復原區域平臺失敗和串聯錯誤案例。

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

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

    • 使用容器型部署，將 Grafana 節點部署至應用程式服務，在區域內的高可用性組態中部署。

      • 跨已考慮的部署區域部署App Service實例。

      App Services 提供低摩擦容器平臺，適用于低規模案例，例如操作儀表板，並將 Grafana 與 AKS 隔離，可提供主要應用程式平臺與該平臺作業標記法之間的明確考慮區隔。 如需進一步的設定建議，請參閱應用程式平臺移除簽署區域。

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

    • 將 App Service 和資料庫讀取複本 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 來收集歷史警示，以納入「冷」作業儲存體以進行進階分析。

  • 對於無法與自動化回應相符的重大失敗案例，請確定作業「Runbook 自動化」已就地提供手動解譯和登出之後，以快速且一致的動作。 使用警示通知來快速識別需要手動解譯的問題

  • 在工程短期衝刺內建立額度，以推動警示的累加改善，以確保先前尚未考慮的新失敗案例可在新的自動化動作中完全配合。

  • 在 CI/CD 程式中執行作業整備測試，以驗證部署更新的重要警示規則。

AIOps) (預測動作和 AI 作業

機器學習模型可以套用至相互關聯並排定運算元據的優先順序，協助收集與篩選過多警示「雜訊」相關的重要深入解析，以及在造成影響之前預測問題，以及加速事件回應。

更具體來說，AIOps 方法可以套用至系統、使用者和 DevOps 程式列為的重要深入解析。 這些深入解析可能包括識別現在發生的問題， (偵測) 、量化問題發生的原因 (診斷) ，或指出未來會發生什麼事 (預測) 。 這類深入解析可用來推動調整和優化應用程式的動作，以降低作用中或潛在問題，使用關鍵商務計量、系統品質計量和 DevOps 生產力計量，根據業務影響來排定優先順序。 執行動作本身可以透過意見反應迴圈將自己內嵌至系統，以進一步訓練基礎模型，以提升額外效率。

任務關鍵 AIOps 方法任務

Azure 內有多個分析技術，例如 Azure Synapse 和 Azure Databricks，可用來建置和定型 AIOps 的分析模型。 因此，本節將著重于這些技術如何在應用程式設計中定位，以配合 AIOps 並推動預測性動作，著重于將 Azure 資料服務的最佳功能與強大的新功能結合在一起，以降低衝突的Azure Synapse。

AIOps 可用來推動預測性動作、解譯和相互關聯在持續期間觀察到的複雜操作訊號，以便更妥善地回應並防止問題發生之前發生。

設計考量

  • Azure Synapse分析提供多個 Machine Learning (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。

  • Azure Synapse原生整合Azure Data Factory工具，以擷取、轉換和載入 (ETL) 或內嵌協調流程管線內的資料。

  • Azure Synapse可讓外部資料集注冊儲存在 Azure Blob 儲存體或Azure Data Lake Storage中的資料。

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

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

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

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

    • Synapse 提供各種工具來協助資料準備，包括 Apache Spark、Synapse Notebook，以及具有 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 認知服務 ，因為其管理與整合額外負荷很低。 請考慮 異常偵測 ，以快速標示可觀察性資料流程中的非預期變異數。

後續步驟

檢閱部署和測試考慮。

部署和測試