練習 - 建置應用程式健康情況模型
- 60 分鐘
Contoso Shoes 需要一種能夠在此結構中偵測、診斷及預測問題的方式。 您想要建置健康情況模型,並且可藉由套用至使用者和系統流程健全狀態進行測量。 目標是在發生中斷之前，就先識別出潛在的失敗點。
目前的狀態和問題
到目前為止，您已新增健康情況檢查 API，並在結構中建置多區域功能。 但是，沒有方法可以深入解析包含使用者和系統流程的複雜拓撲。 您需要填補此差距，SRE 小組才能快速識別並解決問題。
在最近的事件中，小組無法看到因 API 元件影響其平台相依性所造成問題的級聯影響。 他們花費了大量時間進行疑難排解，因為無法立即找出狀況不良的元件。 無法有效率地解決問題導致更長的停機時間，最終造成公司財務損失。
規格
設計健康情況模型，以顯示結構中所有元件之間的關聯性，包括應用程式元件和平台相依性。 請將要求流程中的既有項目納入考量，包括閘道、計算、資料庫、儲存體、快取等等。 這也包含通常在要求流程外部的元件。 例如，Open Container Initiative (OCI) 成品、秘密存放區、設定服務和其他項目。 所有 Azure 服務皆必須設定為傳送「診斷」資料。
在結構中新增已整合的資料接收器，以便從各種來源收集資料。
根據彙總的歷程記錄和計量定義整體健全狀態。 代表三種健全狀態中的其中一種：狀況不良、衰退和狀況良好。
將在階層中表示所有流程的所有元件健全狀態視覺化。
建議的方法
若要開始設計，建議您依照這些步驟操作：
重要
健康情況模型化是全方位的練習。 本章節中的方法旨在協助您開始使用。 充分將模型套用至任務關鍵性設計中的所有功能和非功能性流程，以取得系統的整體檢視。
1–開始健康情況模型化
此練習為理論。 您在由上而下的設計活動中進行健康情況模型化時，將會需要結構中所使用元件的完整清單。 此清單應包含所有應用程式元件和 Azure 服務。
將這些元件放在可顯示解決方案階層式檢視的相依性關係圖中。 頂層具有「使用者流程」，可追蹤來自終端使用者、傳送至網站，以及位於應用程式 API 層級流程的要求。 底層包含來自 Azure 服務的「系統流程」。 同時也對應 Azure 資源之間的相依性。
您的圖表看起來應該如下所示：
檢查進度： 分層應用程式健康情況
2–定義健康情況分數
針對每個元件收集計量和計量閾值，然後決定應將元件視為「狀況良好」、「衰退」和「狀況不良」的值。 該決策應該將預期效能和非功能性商業需求納入考量。 將您的計量分類為：
應用程式計量：來自應用程式程式代碼的數據點，例如例外狀況計數。
服務計量：來自 Azure 服務的數據點，例如使用中的資料庫交易單位（DTU）。
解決方案計量：解決方案層級數據點，例如要求的端對端處理時間。
以下是 Azure 應用程式服務的範例：
| APP 服務 | 健全狀態 |
|---|---|
| 回應時間 < 200 毫秒 HTTP 伺服器錯誤 < 2 |
 |
| 回應時間 < 500 毫秒 HTTP 伺服器錯誤 < 2 |
 |
| 回應時間 > 500 毫秒 HTTP 伺服器錯誤 > 2 |
 |
3–定義整體健全狀態
針對每個使用者和系統流程定義整體狀態。 您必須彙總參與該流程的個別元件健全狀態。
假設系統流程是由應用程式元件、Azure App Service 方案和 App Services 所組成。
| API | App Service 方案 | APP 服務 | 健全狀態 |
|---|---|---|---|
| 延遲上限 < 30 毫秒 | CPU % < 70% HTTP 佇列長度 < 5 |
回應時間 < 200 毫秒 HTTP 伺服器錯誤 < 2 |
|
| 延遲上限 < 30 毫秒 | CPU % < 90% HTTP 佇列長度 < 5 |
回應時間 < 500 毫秒 HTTP 伺服器錯誤 < 2 |
|
| 延遲上限 > 30 毫秒 | CPU % > 90% HTTP 佇列長度 >5 |
回應時間 > 500 毫秒 HTTP 伺服器錯誤 > 2 |
|
使用者流程的健康情況分數應該以所有對應元件的最低分數來表示。 針對系統流程，根據商業關鍵性套用適當的權數。 在兩個流程之間，應優先處理財務重大或直接應對客戶的使用者流程。
檢查進度： 範例 - 分層健康情況模型
4–收集監視資料
您將會需要每個區域中有整合的資料接收器，以收集作為區域戳記一部分部署的所有應用程式和平台服務記錄和計量。 您也會需要另一個接收器來儲存從全域資源發出的計量，例如 Azure Front Door 和 Cosmos DB。
技術選擇
- Azure Application Insights：用來收集所有應用程式遙測。
- Azure 監視器記錄：收集 Azure 服務 Application Insights 和平臺計量所傳送的數據。
- Azure Log Analytics：用來分析來自所有應用程式和基礎結構元件的記錄和計量的中央工具。
檢查進度： 統一數據匯集以進行關聯分析
5 –設定監視資料的查詢
Kusto 查詢語言 (KQL) 與 Log Analytics 有良好整合。 實作自訂 KQL 查詢作為函式，以從 Azure 監視器擷取資料。
將自訂查詢儲存在程式碼存放庫中，以便在持續整合/持續傳遞 (CI/CD) 管道中自動匯入和套用。
6–將健全狀態視覺化
您可以使用紅綠燈標記法，將具有健康情況分數的相依性關係圖進行視覺化。 使用 Azure 儀表板、監視活頁簿或 Grafana 等工具。 以下為範例：
檢查進度： 視覺效果
7–設定狀態變更的警示
您應將儀表板與警示搭配使用，以引起對問題的立即注意。
如果元件的健全狀態變更為「衰退」或「狀況不良」，則應該立即通知操作員。 請在根節點設定警示，因為此節點的任何變更都表示基礎使用者流程或資源中出現狀況不良狀態。
檢查進度： 警示
檢查您的工作
觀看這個關於監視和健康情況模型化的示範。 您是否已涵蓋設計中的所有層面？
- 您是否有整合的資料接收器，以進行相互關聯分析？
- 您是否已包含應用程式記錄、平台計量和解決方案資料點？
- 您是否已設定儀表板，以視覺化所有元件的健全狀態？
- 您是否有考慮到每個服務 (或該服務其中一部分) 的失敗點，可能導致中斷或防止您調整、部署、監視的情況？
- 您是否有考慮使用查詢套件來擷取有助於更快速分類問題的關鍵查詢？
- 您的健康情況檢查 API 在此模型中實用嗎？ 您是否需要改變該 API 以更符合健康情況模型？