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

發行項
10/16/2024

注意

從 2024 年 6 月 1 日起，所有新建立的 App Service 應用程式都可以選擇使用命名慣例 <app-name>-<random-hash>.<region>.azurewebsites.net 來產生唯一的預設主機名稱。現有的應用程式名稱將保持不變。

範例: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

如需詳細資料，請參閱 App Service 資源的唯一預設主機名稱 (英文)。

本文說明如何使用 Azure 入口網站中的健康情況檢查來監視 App Service 執行個體。健康情況檢查會從狀況不良的執行個體重新路由傳送要求，並在執行個體持續狀況不良時加以取代，以增加應用程式的可用性。具體方式是透過您選擇的路徑，每分鐘偵測您的 Web 應用程式一次。

顯示健康情況檢查運作方式的圖表。

請注意，/api/health 只是範例。並沒有預設的健康情況檢查路徑。您應確定您選擇的路徑是存在於應用程式內的有效路徑。

健康情況檢查的運作方式

在應用程式上指定路徑時，健康情況檢查會以 1 分鐘為間隔，在 App Service 應用程式的所有執行個體上偵測此路徑。
如果在指定執行個體上執行的 Web 應用程式未在 10 個要求後回應 200 與 299 (含此二值) 之間的狀態碼，則 App Service 會判定該執行個體狀況不良，並從 Web 應用程式的負載平衡器將其移除。執行個體視為狀況狀況不良的失敗要求必要數目可設定為至少兩個要求。
執行個體移除後，健康情況檢查會繼續加以偵測。如果執行個體開始以狀況良好的狀態碼 (200-299) 回應，則會將該執行個體傳回負載平衡器。
如果在執行個體上執行的 Web 應用程式處於不良狀況達一小時，就會以新的執行個體取而代之。
在擴增時，App Service 會偵測健康情況檢查路徑，以確保新的執行個體已就緒。

注意

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

啟用健康情況檢查

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

注意

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

警告

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

組態

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

應用程式設定名稱	允許的值	描述
`WEBSITE_HEALTHCHECK_MAXPINGFAILURES`	2 - 10	將執行個體視為狀況不良並從負載平衡器移除所需要的失敗要求數目。例如，在設定為 `2` 時，您的執行個體將會在偵測失敗兩次後移除。 (預設值為 `10`。)
`WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT`	1 - 100	根據預設，為了避免讓其餘狀況良好的執行個體負荷過度，不會一次從負載平衡器排除超過半數的執行個體。例如，如果 App Service 方案擴增為四個執行個體，而其中三個狀況不良，則會排除兩個。另外兩個執行個體 (一個狀況良好，另一個狀況不良) 會繼續接收要求。如果所有執行個體都狀況不良，則不會排除任何執行個體。若要覆寫此行為，請將此應用程式設定設為 `1` 與 `100` 之間的值。值越高，表示會移除越多狀況不良的執行個體。 (預設值為 `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 方案，則會列在 [重新啟動] 按鈕的開啟刀鋒視窗上。

如果您重新啟動執行個體，而重新啟動程序失敗，系統會為您提供取代背景工作角色的選項。 (每小時只能取代一個執行個體。)這也會影響到任何使用相同 App Service 方案的應用程式。

對於 Windows 應用程式，您也可以透過「程序總管」來檢視程序。這可讓您進一步了解執行個體的處理序，包括執行緒計數、私人記憶體和 CPU 時間總計。

診斷資訊收集

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

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

監視

提供應用程式的健康情況檢查路徑之後，您可以使用 Azure 監視器來監視網站的健康情況。從入口網站的 [健康情況檢查] 刀鋒視窗中，選取頂端工具列中的 [計量]。這會開啟新的刀鋒視窗，您可以在其中查看網站的健全狀態歷程記錄，並建立新的警示規則。只有在執行個體根據健康情況檢查設定被視為狀況不良時，健康情況檢查計量才會彙總成功的偵測及顯示失敗。如需監視網站的詳細資訊，請參閱 Azure App Service 配額和警示。

限制

您可以為免費和共用 App Service 方案啟用健康情況檢查，以取得網站健康情況的計量並設定警示。不過，由於免費和共用網站無法擴增，因此不會取代狀況不良的執行個體。您應該擴大至基本層或更高層級，才能擴增到兩個或更多執行個體，並充分運用健康情況檢查的優勢。建議用於實際執行對應的應用程式，因為它會增加應用程式的可用性和效能。
App Service 方案最多可以每小時取代一個狀況不良的執行個體，以及最多每天取代三個執行個體。
每個縮放單位的健康情況檢查所取代的執行個體總數有不可設定的限制。如果達到此限制，則不會取代任何狀況不良的執行個體。此值會每隔 12 小時重設一次。

常見問題集

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

如果您的應用程式只擴增為一個執行個體且變成狀況不良，則不會從負載平衡器中移除，因為這樣會完全關閉您的應用程式。不過，在狀況不良的 ping 連續一小時之後，會取代執行個體。請擴增到兩個以上的執行個體，以獲得健康情況檢查的重新路由優點。如果您的應用程式是在單一執行個體上執行，您仍然可以使用健康情況檢查的監視功能來追蹤應用程式的健康情況。

我的 Web 伺服器記錄為什麼不顯示健康情況檢查要求？

健康情況檢查要求會內部傳送至您的網站，所以要求不會顯示在 Web 伺服器記錄中。您可以在健康情況檢查程式碼中新增記錄陳述式，以便在偵測健康情況檢查路徑時保留記錄。

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

在適用於 Windows 和 Linux 的 App Service 上，當網站啟用 [僅限 HTTPS] 時，會透過 HTTPS 傳送健康情況檢查要求。否則，透過 HTTP 傳送要求。

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

否，健康情況檢查功能會偵測 Web 應用程式的預設網域路徑。如果有從預設網域到自訂網域的重新導向，則健康情況檢查傳回的狀態碼不會是 200。這將是重新導向 (301)，會將背景工作角色標示為狀況不良。

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

無論 App Service 方案有多少個其他的應用程式，一律會從負載平衡器輪替中移除狀況不良的執行個體 (最多達 WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT 指定的百分比)。若執行個體上的應用程式狀況不良狀態持續超過一小時，只有在所有其他已啟用健康情況檢查的應用程式也狀況不良時，才會取代該執行個體。未啟用健康情況檢查的應用程式將不會納入考慮。

範例

假設您有兩個應用程式 (或一個具有位置的應用程式)，且已啟用健康情況檢查。其名稱為應用程式 A 和應用程式 B。兩者屬於相同的 App Service 方案，而該方案擴增為四個執行個體。如果應用程式 A 在兩個執行個體上變成狀況不良，負載平衡器會停止傳送要求給這兩個執行個體上的應用程式 A。如果應用程式 B 狀況良好，要求仍會路由傳送至這些執行個體上的應用程式 B。如果應用程式 A 在這兩個執行個體上的狀況不良狀態持續超過一小時，則只有在這些執行個體上的應用程式 B 也狀況不良時，才會取代這些執行個體。如果應用程式 B 狀況良好，則不會取代執行個體。

範例案例的圖表。

注意

如果方案中有另一個網站或位置 (應用程式 C) 未啟用健康情況檢查，則不會將其納入取代執行個體的考量之中。

如果我的所有執行個體都狀況不良，該怎麼辦？

如果應用程式的所有執行個體都狀況不良，App Service 將不會從負載平衡器移除這些執行個體。在此情況下，將所有狀況不良的應用程式執行個體從負載平衡器輪替中移除，實際上會導致應用程式中斷。不過，執行個體取代仍會發生。

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

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

共用方式為