Monitorování instancí služby App Service pomocí kontroly stavu

Poznámka:

Od 1. června 2024 budou mít všechny nově vytvořené aplikace App Service možnost vygenerovat jedinečný výchozí název hostitele pomocí zásad <app-name>-<random-hash>.<region>.azurewebsites.netvytváření názvů . Stávající názvy aplikací zůstanou beze změny.

Příklad: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Další podrobnosti najdete v tématu Jedinečný výchozí název hostitele pro prostředek služby App Service.

Tento článek popisuje, jak pomocí kontroly stavu na webu Azure Portal monitorovat instance 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 každou minutu otestujete webovou aplikaci příkazem ping, a to prostřednictvím zvolené cesty.

Všimněte si, že /api/health je jen příkladem. Neexistuje žádná výchozí cesta kontroly stavu. Měli byste se ujistit, že zvolená cesta je platná cesta, která existuje v rámci vaší aplikace.

Jak funguje kontrola stavu

• Při zadání cesty v aplikaci zkontrolujte příkazem ping cestu ve všech instancích aplikace App Service v 1minutových intervalech.
• Pokud webová aplikace, která běží na dané instanci, neodpovídá stavovým kódem mezi 200 a 299 (včetně) po 10 požadavcích, App Service určí, že instance není v pořádku, a odebere ji z nástroje pro vyrovnávání zatížení webové aplikace. 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.
• Jakmile se instance odebere, kontrola stavu ji bude dál testovat příkazem ping. 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.
• Ve většině případů se jedna instance nahradí za hodinu maximálně třemi instancemi za den na plán služby App Service.
• Pokud kontrola stavu odesílá 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 pro vaši 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ěď během jedné minuty, považuje se příkaz ping kontroly stavu za nezdravý.
• Při výběru cesty kontrola stavu se ujistěte, že vybíráte cestu, která vrací stavový kód 200, jenom když je aplikace plně zahřeje.
• Pokud chcete použít kontrolu stavu v aplikaci funkcí, musíte použít plán hostování úrovně Premium nebo Dedicated.
• Podrobnosti o kontrole stavu u aplikací 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á 2hodnota , instance se odeberou po 2 neúspěšných příkazech ping. (Výchozí hodnota je 10.)
WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT	1 - 100	Pokud chcete zabránit zahlcení zbývajících instancí, které jsou v pořádku, nebude z nástroje pro vyrovnávání zatížení najednou vyloučeno více než polovina instancí. 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. Ve scénáři, kdy všechny instance nejsou v pořádku, nejsou vyloučeny. Chcete-li toto chování přepsat, nastavte toto 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 zajistit zabezpečení koncového bodu 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 tyto funkce použijete, můžete ověřit požadavek kontroly stavu tak, že zkontrolujete hlavičku x-ms-auth-internal-token a ověříte, ž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:

Pro ověřování azure Functions musí 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ě App Service pro Windows.

Instance

Po povolení kontroly stavu můžete z karty instance restartovat a monitorovat stav instancí aplikace. Na kartě Instance se zobrazí název vaší instance a stav instance dané aplikace. Instanci můžete také restartovat ručně z této karty.

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 jednu instanci.) To ovlivní také všechny aplikace, které používají stejný plán služby App Service.

U aplikací pro Windows můžete procesy zobrazit také 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 se přidá pravidlo automatického opravování, které vytvoří výpisy paměti pro instance, které nejsou v pořádku, a uloží je 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 účet úložiště nebo zvolit existující účet 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, kde uvidíte historii stavu webu a vytvoříte nové pravidlo upozornění. Metriky kontroly stavu agregují úspěšné příkazy ping a selhání zobrazení pouze v případě, že instance byla považována za poškozenou na základě konfigurace kontroly stavu. Další informace o monitorování webů najdete v tématu Aplikace Azure Kvóty a výstrahy služby.

Omezení

• U plánů Free a Shared App Service je možné povolit kontrolu stavu, takže můžete mít metriky týkající se stavu webu a nastavit upozornění. Vzhledem k tomu, že se bezplatné a sdílené weby nedají škálovat na více instancí, instance, které nejsou v pořádku, se nenahradí. Měli byste vertikálně navýšit kapacitu na úroveň Basic nebo vyšší, abyste mohli škálovat na dvě nebo více instancí a získat plnou výhodu kontroly stavu. To se doporučuje pro produkční aplikace, protože zvyšuje 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 nekonfigurovatelný. 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ě odebrala. 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 dál pomocí funkce monitorování kontroly stavu sledovat stav 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?

V App Service pro Windows a Linux se požadavky na kontrolu stavu odesí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.

Dodržuje kontrola stavu nakonfigurované přesměrování kódu aplikace mezi výchozí doménou a vlastní doménou?

Ne, funkce kontroly stavu odešle příkaz ping cestu výchozí domény webové aplikace. Pokud existuje přesměrování z výchozí domény na vlastní doménu, pak stavový kód, který vrací kontrolu stavu, nebude 200. Bude to přesměrování (301), které označuje, že pracovní proces 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 ve špatném stavu déle než jednu hodinu, instance se nahradí jenom v případě, že všechny ostatní aplikace, na kterých je povolená kontrola 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. Nazývají se 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 v těchto instancích stále směrují do aplikace B, pokud je aplikace B v pořádku. Pokud aplikace A není v těchto dvou instancích v pořádku déle než hodinu, nahradí se 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 (App C) existoval jiný web nebo slot bez povolené kontroly stavu, nemělo by se brát v úvahu nahrazení instance.

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

Pokud 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 výpadky všech instancí aplikace, které nejsou v pořádku, z rotace nástroje pro vyrovnávání zatížení efektivně způsobily výpadek vaší aplikace. K nahrazení instance však stále dojde.

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