Monitorování instancí služby App Service s využitím kontroly stavu

Tento článek používá kontrolu stavu na webu Azure Portal k monitorování instancí služby App Service. Kontrola stavu zvyšuje dostupnost aplikace přesměrováním požadavků mimo instance, které nejsou v pořádku, a nahrazením instancí, pokud zůstanou v pořádku. Dělá to tak, že příkazem ping každou minutu provedete cestu vaší webové aplikace podle vašeho výběru.

Všimněte si, že /api/health je jen příklad přidaný pro účely ilustrace. Ve výchozím nastavení nevytvoříme cestu kontroly stavu. Měli byste se ujistit, že cesta, kterou vyberete, je platná cesta, která existuje v rámci vaší aplikace.

Co App Service dělá s kontrolami stavu

• Při zadání cesty v aplikaci zkontrolujte příkazem ping tuto cestu ve všech instancích vaší aplikace App Service v 1minutových intervalech.
• Pokud webová aplikace, která běží na dané instanci, neodpovídá stavovým kódem od 200 do 299 (včetně) po 10 požadavcích, App Service zjistí, že není v pořádku, a odebere ji z nástroje pro vyrovnávání zatížení pro tuto webovou aplikaci. Požadovaný počet neúspěšných požadavků pro instanci, která má být považována za poškozenou, je možné nakonfigurovat na minimálně dva požadavky.
• Po odebrání kontrola stavu pokračuje příkazem ping na instanci, která není v pořádku. Pokud instance začne reagovat stavovým kódem v pořádku (200–299), vrátí se instance do nástroje pro vyrovnávání zatížení.
• Pokud webová aplikace spuštěná na instanci zůstane v pořádku po dobu jedné hodiny, nahradí se instance novou.
• Při horizontálním navýšení kapacity app Service odešle příkaz ping na cestu kontroly stavu, aby se zajistilo, že jsou nové instance připravené.

Poznámka:

• Kontrola stavu neprovádí přesměrování 302.
• V rámci plánu služby App Service se za hodinu nahradí maximálně jedna instance (a maximálně tři instance za den).
• Pokud kontrola stavu udává stav Waiting for health check response , kontrola pravděpodobně selhává kvůli stavovém kódu HTTP 307, ke kterému může dojít, pokud máte povolené přesměrování HTTPS, ale je HTTPS Only zakázané.

Povolení kontroly stavu

1. Pokud chcete povolit kontrolu stavu, přejděte na web Azure Portal a vyberte aplikaci App Service.
2. V části Monitorování vyberte Kontrola stavu.
3. Vyberte Povolit a zadejte platnou cestu URL v aplikaci, například /health/api/health.
4. Zvolte Uložit.

Poznámka:

• Plán služby App Service by se měl škálovat na dvě nebo více instancí, aby se plně využila kontrola stavu.
• Cesta kontroly stavu by měla kontrolovat kritické komponenty vaší aplikace. Pokud například vaše aplikace závisí na databázi a systému zasílání zpráv, měl by se koncový bod kontroly stavu připojit k těmto komponentám. Pokud se aplikace nemůže připojit ke kritické komponentě, měla by cesta vrátit kód odpovědi na úrovni 500, který označuje, že aplikace není v pořádku. Pokud cesta nevrací odpověď do 1 minuty, považuje se příkaz ping kontroly stavu za nezdravý.
• Při výběru cesty kontroly stavu se ujistěte, že vybíráte cestu, která vrací stavový kód 200, pouze když je aplikace plně zahřeje.
• Pokud chcete ve své aplikaci function app používat kontrolu stavu, musíte použít plán hostování úrovně Premium nebo dedicated.
• Podrobnosti o kontrole stavu v aplikacích funkcí najdete tady: Monitorování aplikací funkcí pomocí kontroly stavu.

Upozornění

Změny konfigurace kontroly stavu restartují aplikaci. Pokud chcete minimalizovat dopad na produkční aplikace, doporučujeme nakonfigurovat přípravné sloty a prohodit je do produkčního prostředí.

Konfigurace

Kromě konfigurace možností kontroly stavu můžete také nakonfigurovat následující nastavení aplikace:

Název nastavení aplikace	Povolené hodnoty	Popis
WEBSITE_HEALTHCHECK_MAXPINGFAILURES	2 - 10	Požadovaný počet neúspěšných požadavků pro instanci, která má být považována za poškozenou, a odebraná z nástroje pro vyrovnávání zatížení. Pokud je například nastavená hodnota 2, instance se po neúspěšných příkazech ping odeberou 2 . (Výchozí hodnota je 10)
WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT	1 - 100	Ve výchozím nastavení nebude z nástroje pro vyrovnávání zatížení najednou vyloučena více než polovina instancí, aby nedošlo k zahlcení zbývajících instancí, které jsou v pořádku. Pokud je například plán služby App Service škálovaný na čtyři instance a tři nejsou v pořádku, jsou vyloučené dva. Ostatní dvě instance (jedna v pořádku a jedna není v pořádku) nadále přijímají požadavky. V nejhorším scénáři, kdy všechny instance nejsou v pořádku, nejsou vyloučeny. Chcete-li toto chování přepsat, nastavte nastavení aplikace na hodnotu mezi 1 a 100. Vyšší hodnota znamená, že se odeberou více instancí, které nejsou v pořádku (výchozí hodnota je 50).

Ověření a zabezpečení

Kontrola stavu se integruje s funkcemi ověřování a autorizace služby App Service. Pokud jsou tyto funkce zabezpečení povolené, nevyžadují se žádná další nastavení.

Pokud používáte vlastní ověřovací systém, musí cesta kontroly stavu povolit anonymní přístup. Pokud chcete zabezpečit koncový bod kontroly stavu, měli byste nejprve použít funkce, jako jsou omezení PROTOKOLU IP, klientské certifikáty nebo virtuální síť, abyste omezili přístup k aplikacím. Jakmile budete mít tyto funkce na místě, můžete ověřit požadavek na kontrolu stavu kontrolou hlavičky a ověřením, x-ms-auth-internal-tokenže odpovídá hodnotě hash SHA256 proměnné WEBSITE_AUTH_ENCRYPTION_KEYprostředí . Pokud se shodují, je žádost o kontrolu stavu platná a pochází ze služby App Service.

Poznámka:

Konkrétně pro ověřování Azure Functions potřebuje funkce, která slouží jako koncový bod kontroly stavu, povolit anonymní přístup.

.NET

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;
}

Python

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

Java

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);
}

Node.js

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;
}

Poznámka:

Hlavička x-ms-auth-internal-token je dostupná jenom ve službě Windows App Service.

Instance

Jakmile je povolená kontrola stavu, můžete stav instancí aplikace restartovat a monitorovat na kartě Instance. Na kartě Instance se zobrazí název vaší instance, stav instance aplikace a možnost ručního restartování instance.

Pokud stav instance aplikace není v pořádku, můžete instanci restartovat ručně pomocí tlačítka restartovat v tabulce. Mějte na paměti, že restartování ovlivní také všechny ostatní aplikace hostované ve stejném plánu služby App Service jako instance. Pokud existují jiné aplikace, které používají stejný plán služby App Service jako instance, jsou uvedené v úvodním okně z tlačítka restartování.

Pokud instanci restartujete a proces restartování selže, budete mít možnost nahradit pracovní proces (za hodinu je možné nahradit pouze 1 instanci). To ovlivní také všechny aplikace používající stejný plán služby App Service.

Aplikace systému Windows budou mít také možnost zobrazit procesy prostřednictvím Průzkumníka procesů. Získáte tak další přehled o procesech instance, včetně počtu vláken, privátní paměti a celkového času procesoru.

Shromažďování diagnostických informací

U aplikací pro Windows máte možnost shromažďovat diagnostické informace na kartě Kontrola stavu. Povolením diagnostické kolekce přidáte pravidlo automatické léčování, které vytvoří výpisy paměti pro instance, které nejsou v pořádku, a uloží ho do určeného účtu úložiště. Povolením této možnosti se změní konfigurace automatického opravování. Pokud existují existující pravidla automatického oprav, doporučujeme toto nastavení nastavit prostřednictvím diagnostiky služby App Service.

Po povolení diagnostické kolekce můžete vytvořit nebo zvolit existující účet úložiště pro vaše soubory. Můžete vybrat jenom účty úložiště ve stejné oblasti jako vaše aplikace. Mějte na paměti, že ukládání restartuje aplikaci. Pokud po průběžných příkazech ping zjistíte, že vaše instance webu nejsou v pořádku, můžete přejít do prostředku účtu úložiště a zobrazit výpisy paměti.

Sledování

Po zadání cesty kontroly stavu vaší aplikace můžete monitorovat stav webu pomocí služby Azure Monitor. V okně Kontrola stavu na portálu vyberte metriky na horním panelu nástrojů. Otevře se nové okno, ve kterém uvidíte historický stav webu a možnost vytvořit nové pravidlo upozornění. Metriky kontroly stavu agregují úspěšná selhání příkazů ping a zobrazení pouze v případě, že instance není v pořádku na základě konfigurace kontroly stavu. Další informace o monitorování webů najdete v příručce ke službě Azure Monitor.

Omezení

• U plánů Free a Shared App Service je možné povolit kontrolu stavu, takže můžete mít metriky pro upozornění na stav a nastavení webu, ale protože bezplatné a sdílené weby nejde škálovat na více instancí, nenahradí se žádné instance, které nejsou v pořádku. Měli byste vertikálně navýšit kapacitu na úroveň Basic nebo vyšší, abyste mohli škálovat na 2 nebo více instancí a využívat plnou výhodu kontroly stavu. To se doporučuje pro produkční aplikace, protože zvýší dostupnost a výkon vaší aplikace.
• Plán služby App Service může mít maximálně jednu instanci, která není v pořádku, nahrazena za hodinu a maximálně tři instance za den.
• Celkový počet instancí nahrazených kontrolou stavu na jednotku škálování je omezený nekonfigurovatelným limitem. Pokud dosáhnete tohoto limitu, nenahradí se žádné instance, které nejsou v pořádku. Tato hodnota se resetuje každých 12 hodin.

Nejčastější dotazy

Co se stane, když aplikace běží na jediné instanci?

Pokud je vaše aplikace škálovaná jenom na jednu instanci a není v pořádku, neodebere se z nástroje pro vyrovnávání zatížení, protože by se aplikace úplně odstranila. Po jedné hodině nepřetržitých příkazů ping, které nejsou v pořádku, se však instance nahradí. Horizontální navýšení kapacity na dvě nebo více instancí, abyste získali výhodu přesměrování kontroly stavu. Pokud je vaše aplikace spuštěná v jedné instanci, můžete stále používat funkci monitorování kontroly stavu, abyste měli přehled o stavu vaší aplikace.

Proč se požadavky kontroly stavu nezobrazují v protokolech webového serveru?

Žádosti o kontrolu stavu se odesílají interně na váš web, takže se požadavek nezobrazí v protokolech webového serveru. Do kódu kontroly stavu můžete přidat příkazy protokolu, které budou uchovávat protokoly, kdy je cesta kontroly stavu ping.

Posílají se požadavky kontroly stavu přes PROTOKOL HTTP nebo HTTPS?

Ve službě Windows App Service se žádosti o kontrolu stavu posílají prostřednictvím protokolu HTTPS, pokud je na webu povolený jenom HTTPS. V opačném případě se odešlou přes protokol HTTP. V Linux App Service se požadavky na kontrolu stavu odesílají jenom přes protokol HTTP a v tuto chvíli se nedají odesílat přes HTTPS .

Kontroluje se kontrola stavu podle nakonfigurovaného kódu aplikace přesměrování mezi výchozí doménou a vlastní doménou?

Ne, funkce kontroly stavu testuje cestu výchozí domény webové aplikace příkazem ping. Pokud je k dispozici přesměrování z výchozí domény na vlastní doménu, pak stavový kód, který vrací kontrola stavu, nebude 200, ale přesměrování (301), což bude označit pracovní proces, který není v pořádku.

Co když mám ve stejném plánu služby App Service více aplikací?

Instance, které nejsou v pořádku, se vždy odeberou z obměny nástroje pro vyrovnávání zatížení bez ohledu na ostatní aplikace v plánu služby App Service (až do procenta uvedeného v WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT). Pokud aplikace v instanci zůstane po dobu jedné hodiny v pořádku, instance se nahradí jenom v případě, že všechny ostatní aplikace s povolenou kontrolou stavu nejsou v pořádku. Aplikace, které nemají povolenou kontrolu stavu, se nebudou brát v úvahu.

Příklad

Představte si, že máte dvě aplikace (nebo jednu aplikaci s slotem) s povolenou kontrolou stavu označovanou jako App A a App B. Jsou ve stejném plánu služby App Service a plán se škáluje na čtyři instance. Pokud aplikace A není ve dvou instancích v pořádku, nástroj pro vyrovnávání zatížení přestane odesílat požadavky do aplikace A v těchto dvou instancích. Požadavky se na tyto instance stále směrují do aplikace B za předpokladu, že je aplikace B v pořádku. Pokud aplikace A na těchto dvou instancích není v pořádku déle než hodinu, nahradí se tyto instance pouze v případě, že aplikace B není v těchto instancích v pořádku. Pokud je aplikace B v pořádku, instance se nenahradí.

Poznámka:

Pokud by v plánu (site C) existoval jiný web nebo slot bez povolené kontroly stavu, nebyl by při nahrazení instance brán v úvahu.

Co když všechny moje instance nejsou v pořádku?

Ve scénáři, kdy všechny instance vaší aplikace nejsou v pořádku, app Service neodebere instance z nástroje pro vyrovnávání zatížení. V tomto scénáři by při výpadku obměny nástroje pro vyrovnávání zatížení došlo k výpadku všech instancí aplikace, které nejsou v pořádku; nahrazení instancí však bude i nadále dodrženo.

Funguje kontrola stavu ve službě App Service Environment?

Ano, kontrola stavu je dostupná pro App Service Environment verze 3, ale ne pro verze 1 nebo 2. Pokud používáte starší verze služby App Service Environment, můžete pomocí funkce migrace migrovat službu App Service Environment na verzi 3.

Další kroky

• Vytvoření upozornění protokolu aktivit pro monitorování všech operací modulu automatického škálování ve vašem předplatném
• Vytvoření upozornění protokolu aktivit pro monitorování všech neúspěšných operací horizontálního škálování nebo horizontálního navýšení kapacity ve vašem předplatném
• Referenční informace k proměnným prostředí a nastavením aplikace