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

V tomto článku se pomocí Azure Portal ke sledování instancí App Service používá kontrolu stavu. Při kontrole stavu se zvyšuje dostupnost vaší aplikace tím, že se požadavky znovu směrují z instancí, které nejsou v pořádku, a nahradí instance, pokud zůstanou v pořádku. Plán App Service je třeba škálovat na dvě nebo více instancí, aby bylo možné plně využívat kontrolu stavu. Cesta pro kontrolu stavu by měla kontrolovat kritické součásti aplikace. Například pokud vaše aplikace závisí na databázi a systému zasílání zpráv, koncový bod kontroly stavu by se měl k těmto součástem připojit. Pokud se aplikace nemůže připojit ke kritické součásti, měla by tato cesta vracet kód odpovědi 500 na úrovni, který indikuje, že aplikace není v pořádku.

Selhání kontroly stavu

Co App Service s kontrolami stavu

  • Když při zadání cesty k vaší aplikaci zkontroluje stav, otestuje tato cesta na všech instancích vaší App Service aplikace v intervalu 1 minut.
  • Pokud instance nereaguje na stavový kód mezi 200-299 (včetně) po dvou nebo více požadavcích, nebo nereaguje na odpověď na příkaz, systém zjistí, že není v pořádku, a odebere ho.
  • Po odebrání bude test stavu nadále testovat, zda není instance poškozena. Pokud instance začne reagovat s dobrým stavovým kódem (200-299), instance se vrátí do nástroje pro vyrovnávání zatížení.
  • Pokud instance zůstane po jednu hodinu v nesprávném stavu, bude nahrazena novou instancí.
  • Při vertikálním navýšení nebo zmenšování App Service nástroj příkazového řádku otestuje cestu kontroly stavu, aby bylo zajištěno, že budou nové instance připravené.

Poznámka

  • Kontrolu stavu nedodržuje 302 přesměrování. V jednom z nich bude za hodinu nahrazena maximálně jedna instance, a to s maximálním počtem tří instancí za den a App Service.
  • Všimněte si, že pokud vaše kontrolu stavu dává stav, je Waiting for health check response pravděpodobně neúspěšná kvůli stavu HTTP 307, ke kterému může dojít v případě, že je zapnuté přesměrování https, ale je HTTPS Only zakázané.

Povolit kontrolu stavu

Navigace v oblasti kontroly stavu na webu Azure Portal

  • Pokud chcete povolit kontrolu stavu, přejděte na Azure Portal a vyberte svou aplikaci App Service.
  • V části monitorování vyberte možnost Kontrola stavu.
  • Vyberte Povolit a zadejte platnou cestu adresy URL v aplikaci, například /health nebo /api/health .
  • Klikněte na Uložit.

Upozornění

Změny konfigurace kontroly stavu restartujte aplikaci. Abychom minimalizovali dopad na produkční aplikace, doporučujeme nakonfigurovat pracovní sloty a odkládací prostředí v produkčním prostředí.

Konfigurace

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

Název nastavení aplikace Povolené hodnoty Description
WEBSITE_HEALTHCHECK_MAXPINGFAILURES 2 - 10 Požadovaný počet neúspěšných žádostí pro instanci, která má být považována za není v pořádku a odebrána z nástroje pro vyrovnávání zatížení. Například pokud je nastavena na 2 , vaše instance budou odebrány po 2 neúspěšných příkazech otestuje. (výchozí hodnota je 10)
WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT 0 - 100 Ve výchozím nastavení se neodebere z nástroje pro vyrovnávání zatížení v jednom okamžiku více než polovina instancí, aby se předešlo zahlcení zbývajících instancí v pořádku. Pokud je například plán App Service škálovat na čtyři instance a tři nejsou v pořádku, budou vyloučeny dvě. Ostatní dvě instance (v pořádku a jedna není v pořádku) budou i nadále přijímat požadavky. V nejhorším případě, kdy nejsou všechny instance v pořádku, se nevylučují žádné.
Chcete-li toto chování přepsat, nastavte nastavení aplikace na hodnotu mezi 0 a 100 . Vyšší hodnota znamená, že se odeberou víc instancí, které nejsou v pořádku (výchozí hodnota je 50 ).

Ověřování a zabezpečení

Kontroly stavu se integrují s funkcemi ověřování a autorizaceApp Service. Pokud jsou tyto funkce zabezpečení povoleny, nejsou vyžadovány žádné další nastavení.

Pokud používáte vlastní ověřovací systém, musí cesta k kontrole stavu umožňovat anonymní přístup. K zabezpečení koncového bodu kontroly stavu byste nejdřív měli používat funkce, jako jsou omezení IP adresy, klientské certifikátynebo Virtual Network, které omezují přístup k aplikacím. Koncový bod kontroly stavu můžete zabezpečit tím, že budete vyžadovat, aby User-Agent odpovídaly příchozímu požadavku HealthCheck/1.0 . User-Agent nemůže být zfalšovaný, protože žádost již byla zabezpečena předchozími funkcemi zabezpečení.

Monitorování

Po poskytnutí cesty pro kontrolu stavu vaší aplikace můžete monitorovat stav svého webu pomocí Azure Monitor. V okně pro kontrolu stavu na portálu klikněte na metriky na horním panelu nástrojů. Otevře se nové okno, kde můžete zobrazit historický stav webu a vytvořit nové pravidlo výstrahy. Další informace o monitorování vašich lokalit najdete v příručce k Azure monitor.

Omezení

  • v lokalitách Premium functions by neměla být povolena kontrolu stavu. kvůli rychlému škálování Premium funkcí můžou žádosti o kontrolu stavu způsobit zbytečné výkyvy v provozu HTTP. Premium Funkce mají své vlastní interní sondy stavu, které slouží k informování o škálování rozhodnutí.
  • Je možné povolit kontrolu stavu pro bezplatné a sdílené App Service plány, abyste mohli mít metriky stavu lokality a nastavili upozornění, ale protože bezplatné a sdílené lokality se nemůžou škálovat, všechny instance, které nejsou v pořádku, se nenahrazují. Měli byste škálovat až na úroveň Basic nebo vyšší, abyste se mohli škálovat na 2 nebo více instancí a využívat všechny výhody kontroly stavu. Tato akce se doporučuje pro produkční aplikace, protože zvyšují dostupnost a výkon vaší aplikace.

Nejčastější dotazy

Co se stane, když je moje aplikace spuštěná na jedné instanci?

Pokud je vaše aplikace jenom škálovaná na jednu instanci a přestane být v pořádku, neodebere se z nástroje pro vyrovnávání zatížení, protože by vaše aplikace byla úplně mimo provoz. Nahorizontální navýšení kapacity na dvě nebo více instancí, aby bylo možné získat výhodu opětovného směrování kontroly stavu. Pokud je vaše aplikace spuštěná na jedné instanci, můžete i nadále používat funkci monitorování kontroly stavu a sledovat stav vaší aplikace.

Proč se žádost o kontrolu stavu nezobrazuje v mých protokolech front-endu?

Požadavek na kontrolu stavu se pošle na váš web interně, takže se v protokolech front-endunebude žádost zobrazovat. To také znamená, že požadavek bude mít původ od chvíle, kdy se 127.0.0.1 žádost odesílá interně. Do kódu kontroly stavu můžete přidat příkazy log, abyste zachovali protokoly, když je cesta k kontrole stavu na základě příkazu.

Jsou požadavky na kontrolu stavu odesílány přes protokol HTTP nebo HTTPS?

v Windows App Service budou požadavky na kontrolu stavu odesílány prostřednictvím protokolu https, pokud je na serveru povolen pouze protokol https . V opačném případě jsou odesílány prostřednictvím protokolu HTTP. V App Service pro Linux se žádosti o kontrolu stavu odesílají jenom přes HTTP a v tuto chvíli se nedají poslat přes HTTP S .

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

Instance, které nejsou v pořádku, se vždy z rotace vyrovnávání zatížení odstraní bez ohledu na jiné aplikace v plánu App Service (až do procenta uvedeného v části WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT ). Když aplikace v instanci zůstane v nesprávném stavu po dobu jedné hodiny, instance se nahradí jenom v případě, že všechny ostatní aplikace s povolenou kontrolou stavu jsou taky v pořádku. Aplikace, které nemají povolenou kontrolu stavu, se nebudou brát v úvahu.

Příklad

Imagine máte dvě aplikace (nebo jednu aplikaci se slotem) s povolenou kontrolou stavu, která se nazývá app a a app B. Mají stejný plán App Service a plán se škáluje na 4 instance. Pokud se aplikace A stane v nesprávném stavu na dvou instancích, nástroj pro vyrovnávání zatížení přestane odesílat požadavky do aplikace A na těchto dvou instancích. V případě, že je v pořádku aplikace B, požadavky budou i nadále směrovány do aplikace B na těchto instancích. Pokud aplikace A zůstane ve špatném stavu po celou hodinu na těchto dvou instancích, budou tyto instance nahrazené jenom v případě, že je aplikace B v těchto případech taky poškozená. Pokud je aplikace B v pořádku, instance se nenahradí.

Vizuální diagram vysvětlující výše vzorový scénář

Poznámka

Pokud existoval jiný web nebo slot v plánu (lokalita C) bez povolení kontroly stavu, nebere se v úvahu pro nahrazení instance.

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

V případě, že všechny instance aplikace nejsou v pořádku, App Service odstraní instance z nástroje pro vyrovnávání zatížení až do procenta uvedeného v WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT . V tomto scénáři by všechny instance aplikace, které nejsou v pořádku, z rotace nástroje pro vyrovnávání zatížení efektivně způsobily výpadek vaší aplikace.

Funguje v prostředí App Service Environment kontrolu stavu?

Ano, v prostředí App Service (služby ASE), bude platforma testovat vaše instance v zadané cestě a odebrat z nástroje pro vyrovnávání zatížení všechny instance, které nejsou v pořádku, takže do nich nebudou požadavky směrovány. V současné době se ale tyto instance, které nejsou v pořádku, nahradí novými instancemi, pokud zůstanou v pořádku po dobu 1 hodiny.

Další kroky