任務關鍵性工作負載的健康建模

2025-06-27

監視應用程式和基礎結構是任何基礎結構部署的重要部分。對於任務關鍵性工作負載，監視是部署的重要部分。監視 Azure 資源的應用程式健康情況和關鍵計量可協助您了解環境是否如預期般運作。

若要完全了解這些計量並評估工作負載的整體健康情況，需要全面瞭解所有受監視的數據。健康情況模型可藉由顯示工作負載健康情況的明確指示，而不是原始計量，協助評估整體健康狀態。狀態通常會顯示為「交通燈」指標，例如紅色、綠色或黃色。具有清楚指標的健康情況模型表示，可讓操作員直覺地瞭解工作負載的整體健康情況，並快速回應所發生的問題。

健康建模可以擴展為下列任務關鍵部署的操作工作：

應用程式健全狀況服務 - 計算叢集上的應用程式元件，提供 API 來判斷戳記的健康情況。
監控 - 收集用於評估應用程式和基礎設施健康狀況和效能的效能與應用程式計數器。
警示 - 基礎結構和應用程式中問題或中斷的可採取行動的警示。
失敗分析 - 對任何失敗進行分解和分析，包括根本原因的記錄。

這些工作構成任務關鍵基礎結構的完整健康情況模型。健康情況模型的開發可以是任何任務關鍵性部署的詳盡且不可或缺的一部分。

如需詳細資訊，請參閱 Azure 上任務關鍵性工作負載的健康情況模型化和可觀察性。

應用程式健康服務

應用程式健全狀況服務（HealthService）是一個應用程式元件，與目錄服務（CatalogService）和背景處理器（BackgroundProcessor）一起位於計算叢集內。 HealthService 會為 Azure Front Door 提供 REST API 來呼叫，以判斷戳記的健康情況。 HealthService 是一個複雜的元件，它不僅反映自身的狀態，還反映相依元件的狀態。

當計算叢集關閉時，健康檢查服務不會回應。當服務啟動並執行時，它會對基礎結構中的下列元件執行定期檢查：

它會嘗試對 Azure Cosmos DB 執行查詢。
它會嘗試將訊息傳送至事件中樞。背景工作者會篩選出訊息。
它會在記憶體帳戶中查閱狀態檔案。此檔案可以用來關閉區域，即使其他檢查仍在正常運作。此檔案可用來與其他進程通訊。例如，如果要為了維護目的而暫時停止使用印章，可以刪除檔案，以強制進入故障狀態並重新導引流量。
它會查詢健康情況模型，以判斷所有作業計量是否都在預先決定的閾值內。當健康模型顯示標記不健康時，即使 HealthService 執行的其他測試成功，流量也不應該路由至該標記。健康模型會考慮更完整的健康狀態看法。

根據預設，所有健康檢查結果會在記憶體中快取10秒，可根據需要進行設定。此作業可能會在偵測中斷時新增一小個延遲，但可確保並非每個 HealthService 查詢都需要後端呼叫，因而降低叢集和下游服務的負載。

此快取模式很重要，因為當使用 Azure Front Door 之類的全域路由器時，HealthService 查詢數目會大幅增加：每個 Azure 數據中心中的每個邊緣節點都會呼叫 HealthService，以判斷其是否具有運行正常的後端連接。快取結果可減少健康檢查所產生的額外叢集負載。

組態

HealthService 和 CatalogService 在元件之間具有通用的組態設定，但 HealthService 專用的下列設定除外：

設定	值
`HealthServiceCacheDurationSeconds`	控制記憶體快取的到期時間，以秒為單位。
`HealthServiceStorageConnectionString`	儲存帳戶中應包含狀態檔的連接字串。
`HealthServiceBlobContainerName`	應存在狀態檔的記憶體容器。
`HealthServiceBlobName`	狀態檔的名稱 - 健康檢查會尋找此檔案。
`HealthServiceOverallTimeoutSeconds`	整體檢查的超時設定 - 預設為 3 秒。如果在此間隔內檢查未完成，服務將回報為不健康狀態。

執行

所有檢查都會以異步方式和平行方式執行。如果其中一個失敗， 則會將整個戳記視為無法使用。

檢查結果會快取在記憶體中，使用標準、非分散式的 ASP.NET Core MemoryCache。 SysConfig.HealthServiceCacheDurationSeconds 控制快取過期時間。默認設定為10秒。

注意

SysConfig.HealthServiceCacheDurationSeconds 組態設定可減少由健康檢查產生的額外負載，因為並非每個請求都會導致對相依服務的下游呼叫。

下表詳細說明基礎結構中元件的健全狀況檢查：

元件	健康情況檢查
儲存帳戶 Blob	Blob 檢查目前有兩個功能： 1. 測試是否可以連線到 Blob 記憶體。儲存帳戶被佈建環境中的其他元件使用，並被視為關鍵資源。 2. 以刪除狀態檔案的方式手動「關閉」區域。已做出設計決策，即檢查只會尋找指定 Blob 容器中狀態檔案是否存在。不會處理檔案的內容。有可能設立一個更為複雜的系統，可以讀取檔案的內容，並根據檔案的內容返回不同的狀態。內容範例為狀況良好、狀況不良和維護。移除狀態檔案會停用戳記。部署應用程式之後，請確定健康情況檔案存在。若沒有健康情況檔案，服務一律會回應 UNHEALTHY。 Front Door 無法確認後端為可用狀態。 Terraform 會建立檔案，且在基礎結構部署完成後應存在。
事件中樞	事件中樞的健康狀況報告會處理 `EventHubProducerService`。如果此服務能夠將新訊息傳送至事件中樞，則報告狀況良好。為了篩選，此訊息已新增識別屬性： `HEALTHCHECK=TRUE` 接收端會忽略此訊息。配置 `AlwaysOn.BackgroundProcessor.EventHubProcessorService.ProcessEventHandlerAsync()` 設定會檢查 `HEALTHCHECK` 屬性。
Azure Cosmos DB	Azure Cosmos DB 健康狀態報告會處理 `CosmosDbService`，並在以下情況下顯示為健康： 1。能夠連線到 Azure Cosmos DB 資料庫並執行查詢。 2. 能夠將測試檔寫入資料庫。測試文件設置了一個很短的存活時間。 Azure Cosmos DB 會自動移除它。 HealthService 會執行兩個不同的探測。如果 Azure Cosmos DB 處於讀取可運作但寫入無法運作的狀態，這兩個探查可確保觸發警示。

Azure Cosmos DB 查詢

針對唯讀查詢，會使用下列查詢，此查詢不會擷取任何數據，而且對整體負載沒有太大影響：

SELECT GetCurrentDateTime ()

寫入查詢會創建一個具備最少內容的虛擬 ItemRating：

var testRating = new ItemRating()
{
    Id = Guid.NewGuid(),
    CatalogItemId = Guid.NewGuid(), // Create some random (=non-existing) item id
    CreationDate = DateTime.UtcNow,
    Rating = 1,
    TimeToLive = 10 // will be auto-deleted after 10sec
};

await AddNewRatingAsync(testRating);

監視

Azure Log Analytics 會作為所有應用程式和基礎結構元件的記錄和度量的中央儲存庫。 Azure 應用程式 Insights 用於所有應用程式監視數據。基礎結構中的每個標籤都有專用的 Log Analytics 工作區和 Application Insights 實例。個別的Log Analytics工作區會用於全域共用的資源，例如 Front Door 和 Azure Cosmos DB。

所有郵票的壽命都很短，並且會在每次新發行時持續更換。每個戳記式的 Log Analytics 工作區部署為獨立監視資源群組中的全域資源，作為戳記 Log Analytics 資源。這些資源不會共用戳記的生命週期。

如需詳細資訊，請參閱整合數據接收以進行相互關聯的分析。

監視：數據源

診斷設定：所有用於 Azure 關鍵任務的 Azure 服務均配置為將其所有診斷數據，包括記錄和計量，傳送至特定於部署（全球或戳記）的 Log Analytics 工作區。此程式會在 Terraform 部署過程中自動執行。新選項會自動識別，並新增為 terraform apply的一部分。
Kubernetes 監視：診斷設定可用來將 Azure Kubernetes Service （AKS）記錄和計量傳送至 Log Analytics。 AKS 已設定為使用 Container Insights。 Container Insights 會在 AKS 叢集中的每個節點上，透過 Kubernetes DaemonSet 部署 OMSAgentForLinux。 OMSAgentForLinux 能夠從 Kubernetes 叢集中收集額外的記錄和計量，並將其傳送至其對應的Log Analytics工作區。這些額外的日誌和度量包括有關 Pods（工作負載執行單元）、部署、服務和整體叢集健康狀況的更詳細數據。若要從 ingress-nginx、cert-manager 和其他部署在 Kubernetes 中的重要工作負載旁的元件中獲得更多深入解析，可以使用 Prometheus 資料抓取。 Prometheus 抓取會將 OMSAgentForLinux 設定為從叢集內各種端點擷取 Prometheus 計量。
Application Insights 資料監視：Application Insights 可用來從應用程式收集監視數據。程式代碼會經過檢測，以使用ApplicationInsights SDK收集應用程式效能的數據。收集重要資訊，如產生的狀態代碼、相依性呼叫的持續時間，以及未處理例外狀況的計數器。這項信息用於健康情況模型，並可用於警示和疑難解答。

監控：Application Insights 可用性測試

若要從外部角度監視個別戳記和整體解決方案的可用性， Application Insights 可用性測試會設定在兩個地方：

區域可用性測試：這些測試是在區域 Application Insights 實例中設定，用來監視戳記的可用性。這些測試直接以叢集和標籤的靜態儲存帳戶為目標。若要直接呼叫叢集的輸入點，要求必須攜帶正確的 Front Door 標識符標頭，否則輸入控制器會拒絕呼叫。
全域可用性測試：這些測試是在全域 Application Insights 實例中設定，並用來透過 Ping Front Door 來監視整體解決方案的可用性。使用兩個測試：一個用來測試對 CatalogService 的 API 呼叫，另一個用來測試網站的首頁。

監視：查詢

Azure Mission-Critical 會使用不同的 Kusto 查詢語言（KQL）查詢來實作自定義查詢作為函式，以從Log Analytics 擷取數據。這些查詢會以個別檔案的形式儲存在我們的程式碼存放庫中，並區分為全球和標記部署。這些內容會自動透過 Terraform 匯入並套用，作為每個基礎設施管線執行的一部分。

此方法會將查詢邏輯與視覺效果層分開。 Log Analytics 查詢會直接從程式代碼呼叫，例如來自 HealthService API。另一個範例是來自可視化工具，例如 Azure 儀錶板、監視器活頁簿或 Grafana。

監視：視覺化

我們會使用 Grafana，在參考實作中將 Log Analytics 健康情況查詢的結果可視化。 Grafana 會顯示 Log Analytics 查詢的結果，且不包含任何邏輯本身。我們會將 Grafana 套件與解決方案部署的生命週期獨立發行。

如需詳細資訊，請參閱視覺效果。

警示

警示是整體作業策略的重要部分。主動式監控，例如使用儀錶板時，應搭配警示以立即引起對問題的注意。

這些警示是健康模型的延伸，通過通知操作員健康狀態的變更，即降級的黃色狀態或不健康的紅色狀態。藉由將警示設定為健全狀況模型的根節點，操作員會立即知道任何商務層級對解決方案狀態的影響：畢竟，如果任何基礎使用者流程或資源報告黃色或紅色計量，此根節點將會變成黃色或紅色。操作員可以將注意力導向健康情況模型視覺效果，以進行疑難解答。

如需詳細資訊，請參閱自動化事件回應。

失敗分析

撰寫失敗分析主要是理論規劃練習。這個理論練習應該用來作為持續驗證過程中自動故障注入的輸入。藉由模擬此處定義的失敗模式，我們可以針對這些失敗驗證解決方案的復原能力，以將中斷降到最低。

下表列出 Azure Mission-Critical 參考實作各種元件的範例失敗案例。

服務	風險	作用/緩和措施/評論	中斷
Microsoft Entra 身份識別	Microsoft Entra 識別碼變成無法使用。	目前沒有可能的緩和措施。多區域方法不會降低任何中斷，因為它是全域服務。此服務是強依賴。 Microsoft Entra 識別碼用於控制平面作業，例如建立新的 AKS 節點、從 ACR 提取容器映射，或在 Pod 啟動時存取金鑰保存庫。現有執行中的元件應該能夠在Microsoft Entra ID 遇到問題時繼續執行。新的 Pod 或 AKS 節點可能無法繁衍。在此期間需要執行大規模作業，可能會導致用戶體驗降低，甚至可能導致服務中斷。	部分
Azure DNS	Azure DNS 變得無法使用，且 DNS 解析失敗。	如果 Azure DNS 變成無法使用，則使用者要求的 DNS 解析，以及應用程式的不同元件之間的 DNS 解析會失敗。此案例目前沒有可能的緩和措施。多區域方法不會降低任何中斷，因為它是全域服務。 Azure DNS 是硬式相依性。外部 DNS 服務作為備份並無濟於事，因為所使用的所有 PaaS 元件都依賴 Azure DNS。切換至IP來略過 DNS 不是選項。 Azure 服務沒有靜態、保證的IP位址。	完整
前門	常見的前端中斷。	如果 Front Door 完全關閉，則沒有緩和措施。此服務是強依賴。	是的
前門	路由/前端/後端設定錯誤。	部署時，可能會因為組態不符而發生。應該在測試階段中發現。使用 DNS 的前端組態是每個環境特有的。緩解：回復至先前的設定應能修復大部分的問題。在 Front Door 中的變更需要花幾分鐘的時間才能完成部署，導致服務中斷。	完整
前門	管理的 TLS/SSL 憑證已刪除。	部署時，可能會因為組態不符而發生。應該在測試階段中發現。就技術上來說，網站仍可運作，但 TLS/SSL 憑證錯誤會防止使用者存取它。緩解措施：重新發行憑證可能需要大約 20 分鐘的時間，外加修正並重新執行流程。	完整
Azure Cosmos DB	資料庫/集合已重新命名。	可能會因為部署時組態不符而發生 - Terraform 會覆寫整個資料庫，這可能會導致數據遺失。您可以使用資料庫/集合層級鎖定來防止數據遺失。應用程式無法存取任何數據。應用程式組態必須更新，且需要重新啟動Pod。	是的
Azure Cosmos DB	區域性停電	Azure Mission-Critical 已啟用多重區域寫入。如果讀取或寫入失敗，用戶端會重試目前的作業。所有未來的作業都將根據偏好的順序永久轉送至下一個區域。如果偏好清單只有一個條目（或是空白），但帳戶有其他可用區域，則會路由到帳戶清單中的下一個區域。	不
Azure Cosmos DB	由於缺少 RU 而進行廣泛的節流。	根據 Front Door 層級採用的請求單位數目和負載平衡，某些戳記可能在 Azure Cosmos DB 使用上會過載，而其他戳記可以接收更多的請求。緩解措施：較佳的負載分佈或更多 RUs。	不
Azure Cosmos DB	磁碟分區已滿	Azure Cosmos DB 邏輯分割區大小限製為 20 GB。如果容器內數據分割索引鍵的數據達到這個大小，額外的寫入要求就會失敗，並出現「分割區索引鍵達到大小上限」錯誤。	部分功能（已停用資料庫寫入）
Azure Container Registry	區域性停電	容器註冊表會使用流量管理員在複本區域之間進行故障轉移。任何要求都應該自動重新路由傳送至另一個區域。最壞的情況是，當 DNS 故障轉移發生時，AKS 節點不會提取 Docker 映射幾分鐘。	不
Azure Container Registry	圖片已被刪除	無法提取任何影像。此中斷應該只會影響新繁衍/重新啟動的節點。現有的節點應該已快取影像。風險降低：如果能夠迅速偵測到問題，重新執行最新的構建管線，應該會將映像檔帶回註冊中心。	不
Azure Container Registry	調節	速度限制可能會延遲擴展作業，這可能會導致效能暫時降低。風險降低：Azure Mission-Critical 使用進階版 SKU，每分鐘提供 1 萬次讀取操作。容器映射已優化，且只有少量的圖層。 ImagePullPolicy 會設定為 IfNotPresent，以先使用本機快取的版本。批注：下載容器映像由多個讀取作業組成，取決於圖層的數量。每分鐘讀取作業數目有限，取決於 ACR SKU 大小。	不
Azure Kubernetes 服務	叢集升級失敗	AKS 節點升級應該在集群的不同時間分批進行。如果某個升級失敗，則不應該影響另一個叢集。叢集升級應該以滾動方式部署在節點，以防止所有節點變成無法使用。	不
Azure Kubernetes 服務	服務要求時，應用程式 Pod 會終止。	此結果可能會導致使用者遇到錯誤和用戶體驗不佳。緩解措施： Kubernetes 預設會以優雅的方式移除 Pod。 Pods 會先從服務中移除，然後工作負載會收到附有寬限期的 SIGTERM，以便在終止之前完成未完成的請求並寫入資料。應用程式程式代碼必須瞭解SIGTERM，如果工作負載需要較長的時間才能關機，可能需要調整寬限期。	不
Azure Kubernetes 服務	區域中無法使用計算容量，以新增更多節點。	向上/向外擴展作業失敗，但不應該影響現有的節點及其作業。理想情況下，流量應該會自動轉移到其他區域以進行負載平衡。	不
Azure Kubernetes 服務	訂用帳戶已達到 CPU 核心配額，無法新增節點。	向上/向外擴展作業失敗，但不應該影響現有的節點及其作業。理想情況下，流量應該會自動轉移到其他區域以進行負載平衡。	不
Azure Kubernetes 服務	Let’s Encrypt 的 TLS/SSL 憑證無法發行或更新。	叢集應向 Front Door 回報故障狀況，流量應轉移到其他節點。減輕措施：調查問題/修復失敗的根本原因。	不
Azure Kubernetes 服務	當資源請求/限制設定不當時，Pod 可能會達到 100% 的 CPU 利用率，導致請求失敗。應用程式重試機制應該能夠復原失敗的要求。重試嘗試可能會導致請求時間延長，而不會將錯誤顯示給客戶。過多的負載最終會導致失敗。	否（如果負載不過度）
Azure Kubernetes 服務	第三方容器映像/註冊表無法使用	某些元件，例如 cert-manager 和 ingress-nginx，需要從外部容器註冊表下載容器映像檔及 helm 圖表（出站流量）。如果這些儲存庫或映像檔中有一個或多個無法使用，新節點上的新實例（其中尚未快取映像檔）可能無法啟動。可能的緩和：在某些情況下，將第三方容器映像匯入至個別解決方案容器登錄很合理。此案例會增加額外的複雜度，且應謹慎規劃及運作。	部分（在調整和更新/升級作業期間）
事件中樞	無法將訊息傳送至事件中樞	戳記無法再用於寫入操作。健康服務應該會自動偵測到此情況，並將該圖章移出使用。	不
事件中樞	BackgroundProcessor 無法讀取訊息	訊息會排入佇列。訊息不應該遺失，因為它們是持續儲存的。目前，健康服務並未涵蓋此次失敗。工作程序中應該設置監控和警報，以偵測讀取訊息時的錯誤。應對措施：在修正問題之前，應該手動停用戳記。	不
儲存體帳戶	事件中樞檢查點令工作者無法使用儲存帳戶。	Stamp 不會處理來自 Event Hubs 的訊息。 HealthService 也會使用記憶體帳戶。 HealthService 會偵測到儲存問題，並應該將標記移出使用循環。預期戳記中的其他服務會同時受到影響。	不
儲存體帳戶	靜態網站遇到問題。	如果靜態網站遇到問題，Front Door 會偵測到此失敗。流量不會傳送至此記憶體帳戶。 Front Door 服務的快取能減輕此問題。	不
金鑰保存庫	金鑰庫`GetSecret`作業無法使用。	在新的 Pod 啟動時，AKS CSI 驅動程式嘗試從 Key Vault 擷取所有秘密，但未能成功。 Pod 無法啟動運作。目前每 5 分鐘會有一次自動更新。更新失敗。錯誤應該會顯示在`kubectl describe pod`中，但Pod會持續運行。	不
金鑰保存庫	金鑰保存庫無法使用於`GetSecret`或`SetSecret`作業。	無法執行新的部署。目前，此失敗可能會導致整個部署管線停止，即使只有一個區域受到影響也一樣。	不
金鑰保存庫	金鑰保存庫流量限制	Key Vault 每 10 秒限制 1,000 個作業。由於密鑰的自動更新，如果在一個群集中有數千個 Pod，理論上可以達到這個限制。可能的風險降低：進一步降低更新頻率，或完全關閉更新頻率。	不
應用程式	設定錯誤	插入至應用程式的連接字串或秘密不正確。透過自動化部署（管線會自動處理設定）和藍綠部署更新來減輕風險。	不
應用程式	過期憑證（憑證資源）	例如，如果事件中樞 SAS 令牌或記憶體帳戶密鑰已變更，而不會在 Key Vault 中正確更新金鑰，讓 Pod 可以使用它們，則個別的應用程式元件會失敗。然後，此失敗應該會影響醫療服務，而且標籤應該會自動撤除。緩解措施：對於所有支援它的服務，使用基於 Microsoft Entra ID 的驗證。 AKS 要求 Pod 使用 Microsoft Entra 工作負載 ID 進行驗證（預覽）。參考實作中已考慮使用 Pod 身分識別。發現 Pod 身分識別目前不夠穩定，且已決定不要用於目前的參考架構。 Pod 身分識別可能是未來的解決方案。	不
應用程式	過期的認證（全域共用資源）	例如，如果 Azure Cosmos DB API 金鑰被更改，但沒有在所有的 Key Vault 中正確更新以使 Pod 可以使用，相關的應用程式元件將會失敗。此故障會同時使所有標記失效，並導致整個作業負載中斷。如需使用 Microsoft Entra 驗證中繞過金鑰和秘密需求的可能方法，請參閱上一項內容。	完整
虛擬網路	子網IP位址空間用盡	如果子網上的 IP 位址空間已用盡，則無法進行任何擴展操作，例如建立新的 AKS 節點或 Pod。不會發生中斷，但可能會降低效能，而影響用戶體驗。緩解措施：增加 IP 空間（若可能的話）。如果這不是選項，它可能有助於增加每個節點的資源（較大的 VM SKU）或每個 Pod （更多 CPU/記憶體），讓每個 Pod 可以處理更多流量，因而減少向外延展的需求。	不

下一步

部署參考實施，以全面了解此架構中使用的資源及其設定。

實施：關鍵線上任務