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

發行項
06/01/2024

注意

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

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

如需詳細資訊，請參閱 App Service 資源的唯一預設主機名。

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

健康情況檢查失敗

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

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

在應用程式上指定路徑時，健康情況檢查會以 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 入口網站中的健康情況檢查導覽

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

注意

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

警告

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

組態

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

應用程式設定名稱	允許的值	描述
`WEBSITE_HEALTHCHECK_MAXPINGFAILURES`	2 - 10	將執行個體視為狀況不良並從負載平衡器移除所需要的失敗要求數目。例如，設定為 `2` 時，系統會在 `2` 的 Ping 失敗後移除您的執行個體。 (預設值為 `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 方案，則會列在 [重新啟動] 按鈕的開啟刀鋒視窗上。

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

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

診斷資訊收集

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

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

監視

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

限制

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

常見問題集

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

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

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

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

健康情況檢查要求是否透過 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。如果應用程式 A 在這兩個執行個體上的狀況不良狀態持續超過一小時，則只有在這些執行個體上的應用程式 B 也狀況不良時，才會取代這些執行個體。如果應用程式 B 狀況良好，則不會取代執行個體。

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

注意

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

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

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

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

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

共用方式為