任務關鍵性工作負載的健康情況模型
監視應用程式和基礎結構是任何基礎結構部署的重要部分。 對於任務關鍵性工作負載，監視是部署的重要部分。 監視 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 和 CatalogService 在元件之間具有通用的組態設定，但 HealthService 專用的下列設定除外：
| 設定 | 值 |
|---|---|
HealthServiceCacheDurationSeconds |
控制記憶體快取的到期時間，以秒為單位。 |
HealthServiceStorageConnectionString |
應存在狀態檔之記憶體帳戶的連接字串。 |
HealthServiceBlobContainerName |
應存在狀態檔的記憶體容器。 |
HealthServiceBlobName |
狀態檔的名稱 - 健康情況檢查會尋找此檔案。 |
HealthServiceOverallTimeoutSeconds |
整個檢查的逾時 - 預設為 3 秒。 如果檢查未在此間隔內完成，服務會回報狀況不良。 |
實作
所有檢查都會以異步方式和 平行方式執行。 如果其中一個失敗， 則會將整個戳記視為無法使用。
使用標準、非分散式 ASP.NET Core MemoryCache，在記憶體中快取檢查結果。 快取到期由 SysConfig.HealthServiceCacheDurationSeconds 控制，且預設設定為10秒。
注意
組 SysConfig.HealthServiceCacheDurationSeconds 態設定可減少健康情況檢查所產生的額外負載，因為並非所有要求都會導致下游呼叫相依服務。
下表詳細說明基礎結構中元件的健全狀況檢查：
| 元件 | 健康情況檢查 |
|---|---|
| 記憶體帳戶 Blob | Blob 檢查目前有兩個用途： 1。 測試是否可以連線到 Blob 記憶體。 記憶體帳戶會由戳記中的其他元件使用，並視為重要資源。 2. 刪除狀態檔案以手動「關閉」區域。 已做出設計決策，即檢查 只會尋找指定 Blob 容器中是否有狀態檔案 。 不會處理檔案的內容。 設定更複雜的系統可能會讀取檔案的內容，並根據檔案的內容傳回不同的狀態。 內容範例為狀況良好、狀況不良和維護。 拿掉狀態檔案將會停用戳記。 部署應用程式之後，請確定健康情況檔案存在。 若沒有健康情況檔案，服務一律會以 HEALTHY 回應。 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，部署 OMSAgentForLinus 。 OMSAgentForLinux 能夠從 Kubernetes 叢集中收集額外的記錄和計量，並將其傳送至其對應的Log Analytics工作區。 這些額外的記錄和計量包含Pod、部署、服務和整體叢集健康情況的更細微數據。 若要從輸入 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。
監視：視覺效果
為了可視化Log Analytics健康情況查詢的結果，我們已在參考實作中使用 Grafana。 Grafana 可用來顯示 Log Analytics 查詢的結果，而且不包含任何邏輯本身。 Grafana 堆疊不是解決方案部署生命週期的一部分，而是分開發行。
如需詳細資訊，請參閱 視覺效果。
警示
警示是整體作業策略的重要部分。 主動式監視，例如使用儀錶板時，應該與警示搭配使用，以立即注意問題。
這些警示會形成健全狀況模型的延伸，方法是將操作員警示為健康情況狀態的變更、降級/黃色狀態或狀況不良/紅色狀態。 藉由將警示設定為健全狀況模型的根節點，操作員會立即知道任何商務層級對解決方案狀態的影響：畢竟，如果任何基礎使用者流程或資源報告黃色或紅色計量，此根節點將會變成黃色或紅色。 操作員可以將注意力導向健康情況模型視覺效果，以進行疑難解答。
如需詳細資訊，請參閱 自動化事件回應。
失敗分析
撰寫失敗分析主要是理論規劃練習。 這個理論練習應該用來作為連續驗證程式一部分之自動化失敗插入的輸入。 藉由模擬此處定義的失敗模式，我們可以針對這些失敗驗證解決方案的復原能力，以確保它們不會導致中斷。
下表列出 Azure Mission-Critical 參考實作各種元件的範例失敗案例。
| 服務 | 風險 | 影響/風險降低/批注 | Outage |
|---|---|---|---|
| Microsoft Entra ID | Microsoft Entra 識別碼變成無法使用。 | 目前沒有可能的緩和措施。 多區域方法不會減輕任何中斷，因為它是全域服務。 此服務是硬式相依性。 Microsoft Entra 識別碼用於控制平面作業，例如建立新的 AKS 節點、從 ACR 提取容器映射，或在 Pod 啟動時存取 金鑰保存庫。 預期現有的執行元件應該能夠在Microsoft Entra ID 遇到問題時繼續執行。 新的 Pod 或 AKS 節點可能會無法繁衍。 在此期間需要調整作業，可能會導致用戶體驗降低，而且可能會中斷。 | Partial |
| Azure DNS | Azure DNS 變得無法使用，且 DNS 解析失敗。 | 如果 Azure DNS 變成無法使用，則使用者要求的 DNS 解析，以及應用程式的不同元件之間的 DNS 解析可能會失敗。 此案例目前沒有可能的緩和措施。 多區域方法不會減輕任何中斷，因為它是全域服務。 Azure DNS 是硬式相依性。 外部 DNS 服務作為備份並無濟於事，因為所使用的所有 PaaS 元件都依賴 Azure DNS。 切換至IP來略過 DNS 不是選項。 Azure 服務沒有靜態、保證的IP位址。 | 完整 |
| Front Door | 一般 Front Door 中斷。 | 如果 Front Door 完全關閉，則沒有緩和措施。 此服務是硬式相依性。 | Yes |
| Front Door | 路由/前端/後端設定錯誤。 | 部署時，可能會因為組態不符而發生。 應該在測試階段中攔截。 使用 DNS 的前端組態是每個環境特有的。 風險降低：回復至先前的設定應該會修正大部分的問題。 由於 Front Door 中的變更需要幾分鐘的時間才能部署，因此會導致中斷。 | 完整 |
| Front Door | 受控 TLS/SSL 憑證已刪除。 | 部署時，可能會因為組態不符而發生。 應該在測試階段中攔截。 在技術上，網站仍可運作，但 TLS/SSL 憑證錯誤會防止使用者存取它。 風險降低：重新發行憑證可能需要大約 20 分鐘的時間，以及修正並重新執行管線。 | 完整 |
| Azure Cosmos DB | 資料庫/集合已重新命名。 | 可能會因為部署時組態不符而發生 - Terraform 會覆寫整個資料庫，這可能會導致數據遺失。 您可以使用資料庫/集合層級鎖定來防止數據遺失。 應用程式將無法存取任何數據。 應用程式組態必須更新並重新啟動Pod。 | Yes |
| Azure Cosmos DB | 區域中斷 | Azure Mission-Critical 已啟用多重區域寫入。 如果讀取或寫入失敗，用戶端會重試目前的作業。 所有未來的作業都會依喜好設定的順序永久路由傳送至下一個區域。 如果喜好設定清單有一個專案（或空白），但帳戶有其他區域可用，則會路由傳送至帳戶清單中的下一個區域。 | No |
| Azure Cosmos DB | 由於缺少 RU 而進行廣泛的節流。 | 根據 Front Door 層級採用的 RU 數目和負載平衡，某些戳記可能會在 Azure Cosmos DB 使用率上執行經常性存取，而其他戳記可以提供更多要求。 風險降低：較佳的負載分佈或更多 RU。 | No |
| Azure Cosmos DB | 分割區已滿 | Azure Cosmos DB 邏輯分割區大小限製為 20 GB。 如果容器內的分割區索引鍵數據達到此大小，其他寫入要求將會失敗，並出現「分割區索引鍵達到大小上限」錯誤。 | 部份 （已停用資料庫寫入） |
| Azure Container Registry | 區域中斷 | 容器登錄會使用 流量管理員 在複本區域之間故障轉移。 任何要求都應該自動重新路由傳送至另一個區域。 最壞的情況是，DNS 故障轉移發生時，AKS 節點無法提取 Docker 映射幾分鐘。 | No |
| Azure Container Registry | Image（s） 已刪除 | 無法提取任何影像。 此中斷應該只會影響新繁衍/重新啟動的節點。 現有的節點應該已快取映像。 **風險降低：如果偵測到快速重新執行最新的組建管線，應該會將映射帶回登錄。 | No |
| Azure Container Registry | 節流 | 節流可能會延遲相應放大作業，這可能會導致效能暫時降低。 風險降低：Azure Mission-Critical 會使用進階 SKU，每分鐘提供 10k 個讀取作業。 容器映射已優化，且只有少量的圖層。 ImagePullPolicy 會設定為 IfNotPresent，以先使用本機快取的版本。 批注：提取容器映像是由多個讀取作業所組成，視圖層數目而定。 每分鐘讀取作業數目有限，取決於 ACR SKU 大小。 | No |
| Azure Kubernetes Service | 叢集升級失敗 | AKS 節點升級應該在戳記的不同時間進行。 如果某個升級失敗，則不應該影響另一個叢集。 叢集升級應該以滾動方式部署在節點，以防止所有節點變成無法使用。 | No |
| Azure Kubernetes Service | 服務要求時，應用程式 Pod 會終止。 | 這可能會導致使用者遇到錯誤和用戶體驗不佳。 風險降低： Kubernetes 預設會以正常方式移除 Pod。 Pod 會先從服務中移除，工作負載會收到寬限期的 SIGTERM，以在終止之前完成開啟的要求和寫入數據。 應用程式程式代碼必須瞭解SIGTERM，如果工作負載需要較長的時間才能關機，可能需要調整寬限期。 | No |
| Azure Kubernetes Service | 區域中無法使用計算容量，以新增更多節點。 | 相應增加/相應放大作業將會失敗，但不應該影響現有的節點及其作業。 在理想情況量應該會自動轉移到其他區域以進行負載平衡。 | No |
| Azure Kubernetes Service | 訂用帳戶達到 CPU 核心配額以新增節點。 | 相應增加/相應放大作業將會失敗，但不應該影響現有的節點及其作業。 在理想情況量應該會自動轉移到其他區域以進行負載平衡。 | No |
| Azure Kubernetes Service | 讓我們加密 TLS/SSL 憑證無法發行/更新。 | 叢集應該向 Front Door 回報狀況不良，流量應該轉移到其他戳記。 風險降低：調查問題/更新失敗的根本原因。 | No |
| Azure Kubernetes Service | 當資源要求/限制設定不正確時，Pod 可以達到 100% 的 CPU 使用率，並失敗要求。 應用程式重試機制應該能夠復原失敗的要求。 重試可能會造成較長的要求持續時間，而不會將錯誤呈現給用戶端。 過多的負載最終會導致失敗。 | 否 （如果負載不過度） | |
| Azure Kubernetes Service | 第三方容器映像/登錄無法使用 | 某些元件，例如 cert-manager 和 ingress-nginx，需要從外部容器登錄下載容器映像和 helm 圖表（輸出流量）。 如果其中一或多個存放庫或映射無法使用，新節點上的新實例（其中尚未快取映像）可能無法啟動。 可能的風險降低：在某些情況下，將 第三方容器映像匯入每個解決方案容器登錄可能很合理。 這會增加額外的複雜度，而且應該謹慎規劃及運作。 | 部分 （在調整和更新/升級作業期間） |
| 事件中樞 | 無法將訊息傳送至事件中樞 | 戳記變成無法用於寫入作業。 健康情況服務應該會自動偵測到此情況 ，並淘汰輪替。 | No |
| 事件中樞 | BackgroundProcessor 無法讀取 訊息 | 訊息會排入佇列。 訊息不應該因為保存而遺失。 目前，健全狀況服務並未涵蓋此失敗。 背景工作角色上應該有監視/警示，以偵測讀取訊息時的錯誤。 風險降低：在修正問題之前，應該手動停用戳記。 | No |
| 儲存體帳戶 | 事件中樞檢查點的背景工作角色無法使用記憶體帳戶 | 戳記不會處理來自事件中樞的訊息。 HealthService 也會使用記憶體帳戶。 HealthService 應該偵測到記憶體的預期問題，而且戳記應該從輪替中取出。 預期戳記中的其他服務將會同時受到影響。 | No |
| 儲存體帳戶 | 靜態網站遇到問題。 | 如果靜態網站的服務遇到問題，Front Door 應該偵測到此失敗。 流量不會傳送至此記憶體帳戶。 Front Door 的快取也可以減輕此問題。 | No |
| 金鑰保存庫 | 金鑰保存庫 作業無法使用GetSecret。 |
在新 Pod 開始時，AKS CSI 驅動程式會從 金鑰保存庫 擷取所有秘密並失敗。 Pod 將無法啟動。 目前每 5 分鐘會有一次自動更新。 更新將會失敗。 錯誤應該會顯示在 中 kubectl describe pod ，但 Pod 會持續運作。 |
No |
| 金鑰保存庫 | 金鑰保存庫 或 SetSecret 作業無法使用GetSecret。 |
無法執行新的部署。 目前，此失敗可能會導致整個部署管線停止，即使只有一個區域受到影響也一樣。 | No |
| 金鑰保存庫 | 金鑰保存庫 節流 | 金鑰保存庫 每 10 秒限制 1000 個作業。 由於秘密的自動更新，如果戳記中有數千個 Pod，理論上可以達到這個限制。 可能的風險降低：進一步降低更新頻率，或完全關閉更新頻率。 | No |
| 應用程式 | 設定錯誤 | 插入至應用程式的 連接字串 或秘密不正確。 應透過自動化部署來減輕風險（管線會自動處理設定），以及更新的藍綠推出。 | No |
| 應用程式 | 過期認證 （戳記資源） | 例如，如果事件中樞 SAS 令牌或記憶體帳戶密鑰已變更，而不需在 金鑰保存庫 中正確更新它們，讓 Pod 可以使用它們，則個別的應用程式元件將會失敗。 然後，此失敗應該會影響 健全狀況服務，而且戳記應該會自動從旋轉中取出。 風險降低：針對支援它的所有服務，使用 Microsoft Entra ID 型驗證。 AKS 要求 Pod 使用 Microsoft Entra 工作負載 ID 進行驗證（預覽）。 參考實作中已考慮使用Pod身分識別。 發現 Pod 身分識別目前不夠穩定，且已決定不要用於目前的參考架構。 Pod 身分識別可能是未來的解決方案。 | No |
| 應用程式 | 過期的認證（全域共用資源） | 例如，如果 Azure Cosmos DB API 金鑰已變更，而不會在所有戳記 金鑰保存庫 中正確更新，讓 Pod 可以使用它們，則個別的應用程式元件將會失敗。 此失敗會同時關閉所有戳記，並導致整個工作負載中斷。 如需使用 Microsoft Entra 驗證之金鑰和秘密需求的可能方式，請參閱上一個專案。 | 完整 |
| 虛擬網路 | 子網IP位址空間用盡 | 如果子網上的IP位址空間已用盡，就可能發生任何相應放大作業，例如建立新的AKS節點或Pod。 這不會造成中斷，但可能會降低效能並影響用戶體驗。 風險降低：增加IP空間（可能的話）。 如果這不是選項，它可能有助於增加每個節點的資源（較大的 VM SKU）或每個 Pod （更多 CPU/記憶體），讓每個 Pod 可以處理更多流量，進而減少相應放大的需求。 | No |
下一步
部署參考實施，以全面了解此架構中使用的資源及其設定。