練習 - 定義健全狀態、計量和閾值
在本練習中，我們將繼續使用您先前建立的健康情況模型結構。 您的工作是量化範例應用程式個別元件的健全狀態。
在健康情況模型結構中，首先藉由使用者流程評估從頂端開始的層，然後繼續評估較低層。
使用者流程健全狀態
到目前為止，我們已識別兩個使用者流程：列出目錄項目和新增註解。 若要判斷每個流程的健全狀態，請提出如下問題：
- 何時會將使用者流程視為狀況良好？
- 其可在降級狀態下操作嗎？
根據實作和功能需求，識別參與使用者流程的應用程式元件。 這些元件會在範例架構元件中加以說明。
| 使用者流程 | 元件 |
|---|---|
| 列出目錄項目 | 前端內部 Web 應用程式、目錄 API |
| 新增註解 | 前端內部 Web 應用程式、目錄 API、背景處理器 |
如果其中任何元件變成狀況不良，使用者流程預期會變成狀況不良。
注意
某些應用程式可在特殊「降級」模式下操作。 例如，如果 Contoso Shoes 實作本機瀏覽器快取，則使用 Web 應用程式的員工可以建立註解，但無法傳送註解且不會更新客戶檢視，直到目錄 API 變成狀況良好為止，瀏覽器可以持續檢查這種情況。
應用程式元件健全狀態
判斷參與元件健全狀態的計量。 針對此步驟，您必須知道元件的功能。 提出如下問題：
- 可接受 API 中的哪個處理時間，以維持良好的使用者體驗？
- 是否有任何預期的錯誤？ 什麼是「正常」錯誤率？
- 什麼是「正常」處理時間？ 如果處理時間高於正常，這代表什麼意思？
- 如果無法連線到 Azure Cosmos DB，寫入作業會發生什麼情況？
這些問題應該會將您引導至關鍵計量的特定且可測量閾值。 例如，您可能考慮將這些閾值用於目錄 API 元件。
| 計量和閾值 | 健全狀態 |
|---|---|
| 回應時間 < 150 毫秒 失敗的要求計數 < 10 |
Healthy |
| 回應時間 < 300 毫秒 失敗的要求計數 < 50 |
已降級 |
| 回應時間 > 300 毫秒 失敗的要求計數 > 50 |
Unhealthy |
您可以從應用程式監視解決方案取得值，例如 Application Insights。
Azure 資源健全狀態
Azure 服務健全狀態是以特定資源為基礎。 例如，Azure Cosmos DB 會報告 DTU 使用率，而 Azure App Service 會提供 CPU 使用率的相關資訊。
如需依資源類型計量的相關資訊，請參閱 Azure 監視器支援的計量。
健全狀態和閾值
在評估了所有的應用程式層之後，您應該會有一份元件清單及其健全狀態定義，看起來類似此範例。
| 元件 | 指標/計量 | Healthy | 已降級 | Unhealthy |
|---|---|---|---|---|
| 「列出目錄項目」使用者流程 | 基礎健全狀態 | 前端狀況良好且目錄 API 狀況良好 | ||
| 「新增註解」使用者流程 | 基礎健全狀態 | 前端狀況良好、目錄 API 狀況良好，以及背景處理器狀況良好 | ||
| 前端 Web 應用程式 | 非 20x HTTP 回應數/分鐘 | 0 | 1-10 | > 10 |
| 目錄 API | 例外狀況數/秒 | < 10 | 10-50 | > 10 |
| 平均處理時間 (毫秒) | < 150 | 150-500 | > 500 | |
| 背景處理器 | 佇列中的平均時間 (毫秒) | < 200 | 200-1,000 | > 1,000 |
| 平均處理時間 (毫秒) | < 100 | 100-200 | > 200 | |
| 失敗計數 | < 3 | 3-10 | > 10 | |
| Azure Cosmos DB | DTU 使用率 | < 70% | 70%-90% | > 90% |
| Azure Key Vault | 失敗計數 | < 3 | 3-10 | > 10 |
| Azure 事件中樞 | 處理待辦項目長度 (外寄郵件/內送郵件) | < 3 | 3-20 | > 20 |
| Azure Blob 儲存體 | 平均延遲 (毫秒) | < 100 | 100-200 | > 200 |
在此範例中，前端 Web 應用程式和目錄 API 的容錯不同。 這項差異與對應用程式的技術了解有關。 所有前端錯誤都應該由用戶端處理，因此會有零閾值。 不過，在 API 層上，允許 10 個例外狀況說明使用者造成的錯誤。 例如，「404 - 找不到」這類的錯誤不一定表示健康情況問題。