若要確認應用程式和服務執行正確，您可以使用健全狀況端點監視模式。 此模式會指定在應用程式中使用功能檢查。 外部工具可以透過公開的端點定期存取這些檢查。
內容和問題
最好監視 Web 應用程式和後端服務。 監視可協助確保應用程式和服務可供使用並正確執行。 商務需求通常包括監視。
有時比內部部署服務更難監視雲端服務。 其中一個原因是您無法完全控制裝載環境。 另一個是服務通常相依於平台廠商和其他人提供的其他服務。
許多因素會影響雲端裝載的應用程式。 範例包括網路等待時間、基礎計算和記憶體系統的效能和可用性，以及它們之間的網路頻寬。 服務可能會因為任何這些因素而完全或部分失敗。 若要確保所需的可用性層級，您必須定期確認您的服務是否正確執行。 您的服務等級協定 （SLA） 可能會指定您需要符合的等級。
解決方案
將要求傳送至應用程式上的端點，以實作健康情況監視。 應用程式應該執行必要的檢查，然後傳回其狀態的指示。
健康情況監視檢查通常會結合兩個因素：
- 會檢查應用程式或服務在回應健康情況驗證端點的要求時所執行的檢查（如果有的話）
- 執行健康情況驗證檢查的工具或架構分析結果
回應碼表示應用程式的狀態。 選擇性地，回應碼也會提供應用程式所使用的元件和服務狀態。 監視工具或架構會執行延遲或回應時間檢查。
下圖提供模式的概觀。
應用程式中的健康情況監視程序代碼也可能執行其他檢查來判斷：
- 雲端記憶體或資料庫的可用性和回應時間。
- 應用程式使用之其他資源或服務的狀態。 這些資源和服務可能位於應用程式或應用程式外部。
服務與工具可藉由將要求提交至一組可設定的端點，來監視 Web 應用程式。 這些服務和工具接著會根據一組可設定的規則評估結果。 為了在系統上執行某些功能測試的唯一目的，建立服務端點相當容易。
監視工具執行的一般檢查包括：
- 驗證回應碼。 例如，HTTP 回應為 200 （OK） 表示應用程式回應時沒有錯誤。 監視系統也可能檢查是否有其他回應碼，以提供更全面的結果。
- 檢查回應的內容以偵測錯誤，即使狀態代碼為 200 （確定）。 藉由檢查內容，您可以偵測只影響傳回網頁或服務回應區段的錯誤。 例如，您可以檢查頁面的標題，或尋找特定片語，指出應用程式傳回正確的頁面。
- 測量回應時間。 值包含網路等待時間，以及應用程式發出要求的時間。 增加的值可能表示應用程式或網路出現的問題。
- 檢查位於應用程式外部的資源或服務。 例如，應用程式用來從全域快取傳遞內容的內容傳遞網路。
- 檢查 TLS 憑證的到期時間。
- 測量應用程式 URL 的 DNS 查閱回應時間。 這項檢查會測量 DNS 延遲和 DNS 失敗。
- 驗證 DNS 查閱傳回的 URL。 藉由驗證，您可以確定項目正確無誤。 您也可以協助防止在 DNS 伺服器遭到攻擊之後可能導致的惡意要求重新導向。
可能的話，也適合從不同的內部部署或託管位置執行這些檢查，然後比較響應時間。 在理想情況下，您應該從接近客戶的位置監視應用程式。 然後，您會從每個位置取得效能的準確檢視。 這種做法提供更健全的檢查機制。 結果也可以協助您做出下列決策：
- 部署應用程式的位置
- 是否要在多個數據中心部署
為了確保您的應用程式適用於所有客戶，請針對客戶使用的所有服務實例執行測試。 例如，如果客戶記憶體分散到多個記憶體帳戶，監視程式應該檢查每個帳戶。
問題和考慮
當您決定如何實作此模式時，請考慮下列幾點：
思考如何驗證回應。 例如，判斷 200 （OK） 狀態代碼是否足以驗證應用程式是否正常運作。 檢查狀態代碼是此模式的最低實作。 狀態代碼提供應用程式可用性的基本量值。 但是，程式代碼提供應用程式中作業、趨勢和可能即將發生問題的很少資訊。
決定要為應用程式公開的端點數目。 其中一種方法是針對應用程式使用的核心服務至少公開一個端點，另一個端點用於較低優先順序的服務。 使用此方法，您可以將不同層級的重要性指派給每個監視結果。 也請考慮公開額外的端點。 您可以針對每個核心服務公開一個，以提高監視粒度。 例如，健康情況驗證檢查可能會檢查資料庫、記憶體，以及應用程式所使用的外部地理編碼服務。 每個可能需要不同層級的運行時間和回應時間。 地理編碼服務或其他一些背景工作可能無法使用幾分鐘。 但應用程式可能仍然狀況良好。
決定是否使用相同的端點來監視和一般存取。 您可以針對兩者使用相同的端點，但設計健康情況驗證檢查的特定路徑。 例如，您可以在一般存取端點上使用 /health 。 透過這種方法，監視工具可以在應用程式中執行一些功能測試。 範例包括註冊新使用者、登入和下單。 同時，您也可以確認一般存取端點可供使用。
判斷服務中要收集的信息類型，以回應監視要求。 您也需要判斷如何傳回這項資訊。 大部分現有的工具和架構只會查看端點傳回的 HTTP 狀態代碼。 若要傳回並驗證其他資訊，您可能必須建立自定義監視公用程式或服務。
找出要收集多少資訊。 檢查期間執行過多處理可能會多載應用程式並影響其他使用者。 處理時間也可能超過監視系統的逾時。 因此，系統可能會將應用程式標示為無法使用。 大部分的應用程式都包含檢測，例如錯誤處理程式和性能計數器。 這些工具可以記錄效能和詳細的錯誤資訊，這可能已足夠。 請考慮使用此數據，而不是從健康情況驗證檢查傳回其他資訊。
請考慮快取端點狀態。 經常執行健康情況檢查可能很昂貴。 例如，如果健康狀態是透過儀錶板回報，您就不希望儀錶板的每個要求觸發健康情況檢查。 相反地，定期檢查系統健康情況，並快取狀態。 公開傳回快取狀態的端點。
規劃如何設定監視端點的安全性。 藉由設定安全性，您可以協助保護端點免於公用存取，這可能會：
- 將應用程式公開為惡意攻擊。
- 風險暴露敏感性資訊。
- 吸引阻斷服務 （DoS） 攻擊。
一般而言，您會在應用程式組態中設定安全性。 然後，您可以輕鬆地更新設定，而不需要重新啟動應用程式。 請考慮使用下列一或多項技術：
要求驗證來保護端點。 如果監視服務或工具支持驗證，您可以在要求標頭中使用驗證安全性密鑰。 您也可以使用要求傳遞認證。 當您使用驗證時，請考慮如何存取健康情況檢查端點。 例如，Azure App 服務 具有與 App Service 驗證和授權功能整合的內建健康情況檢查。
使用模糊或隱藏的端點。 例如，在與默認應用程式 URL 所使用的 IP 位址不同的 IP 位址上公開端點。 在非標準 HTTP 埠上設定端點。 此外，請考慮使用測試頁面的複雜路徑。 您通常可以在應用程式組態中指定額外的端點位址和埠。 如有必要，您可以將這些端點的專案新增至 DNS 伺服器。 然後，您可以避免直接指定IP位址。
在接受金鑰值或作業模式值等參數的端點上公開方法。 當要求送達時，程式代碼可以執行相依於 參數值的特定測試。 如果無法辨識參數值，程式代碼可以傳回 404（找不到）錯誤。 在應用程式組態中定義參數值。
使用個別的端點來執行基本功能測試，而不會影響應用程式的作業。 使用這種方法，您可以協助減少 DoS 攻擊的影響。 在理想情況下，請避免使用可能會公開敏感性信息的測試。 有時候，您必須傳回可能對攻擊者有用的資訊。 在此情況下，請考慮如何保護端點和數據免於未經授權的存取。 依賴模糊是不夠的。 請考慮也使用 HTTPS 連線和加密敏感數據，雖然這種方法會增加伺服器上的負載。
決定如何確保監視代理程式正在正確執行。 其中一種方法是公開端點，其會從應用程式組態傳回值，或是可用來測試代理程式的隨機值。 也請確定監視系統本身會執行檢查。 您可以使用自我測試或內建測試來防止監視系統發出誤判結果。
使用此模式的時機
此模式適用於：
- 監視網站和 Web 應用程式以驗證可用性。
- 監視網站和 Web 應用程式，以檢查是否有正確的作業。
- 監視仲介層或共用服務，以偵測並隔離可能會中斷其他應用程式的失敗。
- 補充應用程式中現有的檢測，例如性能計數器和錯誤處理程式。 健康情況驗證檢查不會取代記錄和稽核的應用程式需求。 檢測可以為監視計數器和錯誤記錄檔的現有架構提供重要資訊，以偵測失敗或其他問題。 但是，如果應用程式無法使用，檢測就無法提供資訊。
工作負載設計
架構設計人員應該評估健康情況端點監視模式如何用於其工作負載的設計，以解決 Azure 良好架構架構支柱中涵蓋的目標和原則。 例如：
| 要素 | 此模式如何支援支柱目標 |
|---|---|
| 可靠性設計決策可協助工作負載復原到故障，並確保它會在發生失敗后復原到完全正常運作的狀態。 | 這些端點支援工作負載的可靠性警示和儀錶板工作。 它們也可以使用它作為自我修復補救的信號。 - RE：07 自我修復和自我保護 - RE：10 監視和警示策略 |
| 營運卓越可透過標準化的流程和小組凝聚力，協助提供工作負載品質。 | 標準化要公開的健康情況端點，以及結果中的詳細程度，將工作負載中的詳細數據層級標準化，可協助您分級問題。 - OE：07 監視系統 |
| 效能效率 可透過調整、數據、程式代碼的優化，有效率地協助您的工作負載 符合需求 。 | 健康情況端點會藉由將流量路由傳送至已驗證為狀況良好之節點，以改善負載平衡邏輯。 透過其他設定，您也可以取得可用節點容量的計量。 - PE：05 調整和分割 |
如同任何設計決策，請考慮對其他可能以此模式導入之目標的任何取捨。
範例
您可以使用 ASP.NET 健康情況 檢查 中間件和連結庫來報告應用程式基礎結構元件的健康情況。 此架構可讓您以一致的方式報告健康情況檢查。 它會實作本文描述的許多作法。 例如，ASP.NET 健康情況檢查包括外部檢查，例如資料庫連線能力，以及像是活躍度和整備探查等特定概念。
GitHub 上有數個使用 ASP.NET 健康情況檢查的範例實作。
監視 Azure 裝載應用程式中的端點
Azure 應用程式中監視端點的選項包括：
- 使用 Azure 的內建監視功能，例如 Azure 監視器。
- 使用第三方服務或 Microsoft System Center Operations Manager 之類的架構。
- 建立自訂公用程式或服務，以在您自己的伺服器或託管伺服器上執行。
雖然 Azure 提供完整的監視選項，但您可以使用其他服務和工具來提供額外的資訊。 Application Insights 是監視功能，專為開發小組所設計。 這項功能可協助您瞭解應用程式的執行方式，以及其使用方式。 Application Insights 會監視要求速率、回應時間、失敗率和相依性速率。 它可協助您判斷外部服務是否減緩您的速度。
您可以監視的條件取決於您為應用程式選擇的裝載機制。 本節中的所有選項都支援警示規則。 警示規則會使用您在服務設定中指定的 Web 端點。 此端點應該會及時回應，讓警示系統能夠偵測到應用程式正常運作。 如需詳細資訊，請參閱 建立新的警示規則。
如果發生重大中斷，用戶端流量應該可路由傳送至可跨其他區域或區域使用的應用程式部署。 這種情況適用於跨單位連線和全域負載平衡。 選擇取決於應用程式是內部還是外部面向。 Azure Front Door、Azure 流量管理員 或內容傳遞網路等服務可以根據健康情況探查提供的數據，跨區域路由傳送流量。
流量管理員 是路由和負載平衡服務。 它可以使用各種規則和設定，將要求散發至應用程式的特定實例。 除了路由要求，流量管理員 可以定期 ping URL、埠和相對路徑。 您可以指定 Ping 目標，以判斷應用程式實例作用中，並回應要求的目標。 如果 流量管理員 偵測到狀態代碼 200 （確定），則會將應用程式標示為可用。 任何其他狀態代碼都會導致 流量管理員 將應用程式標示為離線。 流量管理員 主控台會顯示每個應用程式的狀態。 您可以設定每個規則，將要求重新路由傳送至正在回應的應用程式的其他實例。
流量管理員 等候一定時間從監視URL接收回應。 請確定您的健康情況驗證碼在此時間執行。 允許從 流量管理員 到您的應用程式往返的網路等待時間，然後再返回一次。
下一步
下列指引適用於實作此模式：
- 微服務型應用程式中的健康情況監視指引
- 監視應用程式健康情況以取得可靠性，這是 Azure 架構良好架構的一部分
- 建立新的警示規則