使用健康情況檢查來監視 App Service 執行個體

發行項
01/10/2024

本文會使用 Azure 入口網站中的健康情況檢查來監視App Service實例。健康情況檢查會藉由將要求從狀況不良的實例重新路由傳送，並在實例保持狀況不良時取代實例，藉以增加應用程式的可用性。其方式是每分鐘 ping 您所選擇的 Web 應用程式路徑。

健康情況檢查失敗

請注意， /api/health 只是為了說明目的而新增的範例。我們預設不會建立健康情況檢查路徑。您應該確定您選取的路徑是應用程式內存在的有效路徑

App Service 使用健康情況檢查的用途

在應用程式上指定路徑時，健康情況檢查會以1分鐘間隔在App Service 應用程式的所有實例上偵測此路徑。
如果在指定實例上執行的 Web 應用程式在 10 個要求之後未以 200-299 之間的狀態代碼回應，App Service 會判斷其狀況不良，並將它從此 Web 應用程式的負載平衡器中移除。實例視為狀況不良的必要失敗要求數目，可設定為至少兩個要求。
拿掉之後，健康情況檢查會繼續偵測狀況不良的實例。如果實例開始以狀況良好的狀態代碼（200-299）回應，則會將實例傳回負載平衡器。
如果實例上執行的 Web 應用程式維持狀況不良一小時，實例就會取代為新的應用程式。
相應放大時，App Service 會 ping 健康情況檢查路徑，以確保新的實例已就緒。

注意

健康情況檢查不會遵循 302 重新導向。
每小時最多取代一個執行個體，每個 App Service 方案的每日上限為三個執行個體。
如果您的健康狀態檢查提供狀態 Waiting for health check response ，則檢查可能會因為 HTTP 狀態代碼為 307 而失敗，如果您已啟用 HTTPS 重新導向但已 HTTPS Only 停用，就可能發生此情況。

啟用健康情況檢查

Azure 入口網站中的健康情況檢查導覽

若要啟用健康情況檢查，請流覽至 Azure 入口網站，然後選取您的 App Service 應用程式。
在 [監視] 底下，選取 [健康情況檢查]。
選取[ 啟用 ]，並在您的應用程式上提供有效的 URL 路徑，例如 /health 或 /api/health。
選取 [儲存]。

注意

您的 App Service 方案應調整為兩個或多個實例，以充分利用健康情況檢查。
健康情況檢查路徑應該檢查應用程式的重要元件。例如，如果您的應用程式相依於資料庫和傳訊系統，健康情況檢查端點應該會連線到這些元件。如果應用程式無法連線到重要元件，則路徑應該會傳回 500 層級的回應碼，以指出應用程式狀況不良。此外，如果路徑未在 1 分鐘內傳回回應，則健康情況檢查 Ping 會被視為狀況不良。
選取健康情況檢查路徑時，請確定您選取的路徑只會在應用程式完全熱身時，傳回 200 狀態代碼。
若要在函式應用程式上使用健康情況檢查，您必須使用進階或專用主控方案。
如需有關函式應用程式健康情況檢查的詳細數據，請參閱這裡：使用健康情況檢查來監視函式應用程式。

警告

健康情況檢查組態變更會重新啟動您的應用程式。若要將生產應用程式的影響降到最低，建議您設定預備位置並交換至生產環境。

組態

除了設定健康情況檢查選項之外，您也可以設定下列應用程式設定：

應用程式設定名稱	允許的值	描述
`WEBSITE_HEALTHCHECK_MAXPINGFAILURES`	2 - 10	實例所需的失敗要求數目會被視為狀況不良，並從負載平衡器中移除。例如，當設定為 `2`時，您的實例會在失敗的 Ping 之後 `2` 移除。（預設值為 `10`）
`WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT`	1 - 100	根據預設，不會一次從負載平衡器排除超過一半的實例，以避免造成剩餘狀況良好的實例壓倒性。例如，如果 App Service 方案調整為四個實例，而三個實例狀況不良，則會排除兩個。其他兩個實例（一個狀況良好且一個狀況不良）會繼續接收要求。在狀況不良的案例中，所有實例都狀況不良，則不會排除任何實例。若要覆寫此行為，請將應用程式設定設為和`100`之間的`1`值。較高的值表示會移除狀況不良的實例（預設值為 `50`）。

驗證和安全性

健康情況檢查會與 App Service 的驗證和授權功能整合。如果啟用這些安全性功能，則不需要其他設定。

如果您使用自己的驗證系統，健康情況檢查路徑必須允許匿名存取。若要保護健康情況檢查端點，您應該先使用IP限制、客戶端憑證或虛擬網絡等功能來限制應用程式存取。就地擁有這些功能之後，您可以檢查標頭來驗證健康情況檢查要求， x-ms-auth-internal-token並驗證它是否符合環境變數 WEBSITE_AUTH_ENCRYPTION_KEY的SHA256哈希。如果相符，則健康情況檢查要求有效且源自App Service。

注意

特別是針對 Azure Functions 驗證，作為健康情況檢查端點的函式必須允許匿名存取。

using System;
using System.Text;

/// <summary>
/// Method <c>HeaderMatchesEnvVar</c> returns true if <c>headerValue</c> matches WEBSITE_AUTH_ENCRYPTION_KEY.
/// </summary>
public Boolean HeaderMatchesEnvVar(string headerValue) {
    var sha = System.Security.Cryptography.SHA256.Create();
    String envVar = Environment.GetEnvironmentVariable("WEBSITE_AUTH_ENCRYPTION_KEY");
    String hash = System.Convert.ToBase64String(sha.ComputeHash(Encoding.UTF8.GetBytes(envVar)));
    return hash == headerValue;
}

from hashlib import sha256
import base64
import os

def header_matches_env_var(header_value):
    """
    Returns true if SHA256 of header_value matches WEBSITE_AUTH_ENCRYPTION_KEY.
    
    :param header_value: Value of the x-ms-auth-internal-token header.
    """
    
    env_var = os.getenv('WEBSITE_AUTH_ENCRYPTION_KEY')
    hash = base64.b64encode(sha256(env_var.encode('utf-8')).digest()).decode('utf-8')
    return hash == header_value

import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.Base64;
import java.nio.charset.StandardCharsets;

public static Boolean headerMatchesEnvVar(String headerValue) throws NoSuchAlgorithmException {
    MessageDigest digest = MessageDigest.getInstance("SHA-256");
    String envVar = System.getenv("WEBSITE_AUTH_ENCRYPTION_KEY");
    String hash = new String(Base64.getDecoder().decode(digest.digest(envVar.getBytes(StandardCharsets.UTF_8))));
    return hash.equals(headerValue);
}

var crypto = require('crypto');

function envVarMatchesHeader(headerValue) {
    let envVar = process.env.WEBSITE_AUTH_ENCRYPTION_KEY;
    let hash = crypto.createHash('sha256').update(envVar).digest('base64');
    return hash == headerValue;
}

注意

標頭 x-ms-auth-internal-token 僅適用於 Windows App Service。

執行個體

啟用健康情況檢查之後，您可以透過 [實例] 索引標籤重新啟動並監視應用程式實例的狀態。[實例] 索引標籤會顯示實例的名稱、該應用程式實例的狀態，並提供您手動重新啟動實例的選項。

如果應用程式實例的狀態狀況不良，您可以使用資料表中的 [重新啟動] 按鈕手動重新啟動實例。請記住，裝載在與實例相同的 App Service 方案上的任何其他應用程式也會受到重新啟動的影響。如果有其他應用程式使用與實例相同的 App Service 方案，則會列在 [重新啟動] 按鈕的開啟刀鋒視窗上。

如果您重新啟動實例，而重新啟動程序失敗，則系統會提供取代背景工作角色的選項（每小時只能取代 1 個實例）。這也會影響使用相同 App Service 方案的任何應用程式。

Windows 應用程式也可以透過 [行程總管] 來檢視進程。這可讓您進一步了解實例的進程，包括線程計數、私人記憶體和 CPU 總時間。

診斷資訊收集

針對 Windows 應用程式，您可以選擇在 [健康情況檢查] 索引標籤中收集診斷資訊。啟用診斷收集會新增自動癒合規則，以建立狀況不良實例的記憶體轉儲，並將它儲存至指定的記憶體帳戶。啟用此選項會變更自動癒合組態。如果有現有的自動癒合規則，建議您透過App Service診斷來設定此規則。

啟用診斷收集之後，您可以為檔案建立或選擇現有的記憶體帳戶。您只能選取與應用程式位於相同區域中的記憶體帳戶。請記住，儲存會重新啟動您的應用程式。儲存之後，如果您的月台實例在連續 Ping 之後發現狀況不良，您可以移至記憶體帳戶資源並檢視記憶體轉儲。

監視

提供應用程式的健康情況檢查路徑之後，您可以使用 Azure 監視器來監視月臺的健康情況。從入口網站的 [ 健康情況檢查 ] 刀鋒視窗中，選取 頂端工具列中的 [計量 ]。這會開啟新的刀鋒視窗，您可以在其中看到網站的歷程記錄健全狀況狀態，以及建立新警示規則的選項。健康情況檢查計量只會根據健康情況檢查組態，匯總成功的 Ping 和顯示失敗。如需監視網站的詳細資訊，請參閱 Azure 監視器上的指南。

限制

您可以針對免費和共用 App Service方案啟用健康情況檢查，讓您可以在網站的健全狀況和設定警示上取得計量，但由於免費和共用網站無法相應放大，因此不會取代任何狀況不良的實例。您應該相應增加至基本層或更高層級，以便相應放大至 2 或多個實例，並利用健康情況檢查的完整優點。這建議用於生產環境面向的應用程式，因為它會增加您應用程式的可用性和效能。
App Service 方案最多可以每小時更換一個狀況不良的實例，而且最多每天有三個實例。
每個縮放單位的健康情況檢查所取代的實例總數有不可設定的限制。如果達到此限制，則不會取代狀況不良的實例。此值會每隔 12 小時重設一次。

常見問題集

如果我的應用程式在單一執行個體上執行，會發生什麼事？

如果您的應用程式只會調整為一個實例並變成狀況不良，則不會從負載平衡器中移除，因為這會完全關閉您的應用程式。不過，在持續狀況不良的 Ping 之後，會取代實例。向外延展至兩個或多個實例，以取得健康情況檢查的重新路由權益。如果您的應用程式是在單一實例上執行，您仍然可以使用健康情況檢查的監視功能來追蹤應用程式的健康情況。

為什麼健康情況檢查要求未顯示在我的網頁伺服器記錄中？

健康情況檢查要求會在內部傳送至您的網站，因此要求不會顯示在網頁伺服器記錄中。您可以在健康情況檢查程序代碼中新增記錄語句，以在偵測健康情況檢查路徑時保留的記錄。

健康情況檢查要求是否透過 HTTP 或 HTTPS 傳送？

在 Windows App Service 上，只有在網站上啟用 HTTPS 時，健康情況檢查要求會透過 HTTPS 傳送。否則，會透過 HTTP 傳送它們。在Linux App Service上，健康情況檢查要求只會透過 HTTP 傳送，目前無法透過 HTTPS 傳送。

健康情況檢查是否遵循在預設網域與自定義網域之間設定的應用程式程式代碼重新導向？

否，健康情況檢查功能正在 Ping Web 應用程式的預設網域路徑。如果有從預設網域重新導向至自定義網域，則健康狀態檢查傳回的狀態代碼不會是 200，而是重新導向（301），這會標示背景工作角色狀況不良。

如果我在同一個 App Service 方案上有多個應用程式，該怎麼辦？

不論 App Service 方案上的其他應用程式為何，狀況不良的實例一律都會從負載平衡器輪替中移除（最多指定 WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT百分比）。當實例上的應用程式維持狀況不良一個多小時時，只有在啟用健康情況檢查的其他所有應用程式也都狀況不良時，才會取代實例。未啟用健康情況檢查的應用程式將不會納入考慮。

範例

假設您有兩個應用程式（或一個位置的應用程式）已啟用健康情況檢查，稱為應用程式 A 和應用程式 B。它們位於相同的 App Service 方案上，且方案會相應放大為四個實例。如果應用程式 A 在兩個實體上變成狀況不良，負載平衡器就會停止將要求傳送至這兩個實例上的應用程式 A。如果應用程式 B 狀況良好，要求仍會路由傳送至這些實例上的應用程式 B。如果這兩個實例上的 App A 保持狀況不良一個多小時，則只有在這些實例上的 App B 也狀況不良時，才會取代這些實例。如果應用程式 B 狀況良好，則不會取代實例。

說明上述範例案例的可視化圖表。

注意

如果方案（Site C）上有另一個網站或位置，但未啟用健康情況檢查，則不會考慮實例取代。

如果我的所有實例都狀況不良，該怎麼辦？

在應用程式的所有實例狀況不良的情況下，App Service 不會從負載平衡器中移除實例。在此案例中，將所有狀況不良的應用程式實例從負載平衡器輪替中取出，實際上會導致應用程式的中斷;不過，仍會接受實例取代。

健康情況檢查是否適用於 App Service 環境？

是，App Service 環境 v3 提供健康情況檢查，但不適用於第 1 版或 2 版。如果您使用舊版的 App Service 環境，您可以使用移轉功能將 App Service 環境移轉至第 3 版。