App Service-exemplaren bewaken met behulp van statuscontrole

Artikel
11/04/2021
7 minuten om te lezen

In dit artikel wordt statuscontrole in de Azure Portal gebruikt om App Service te controleren. Statuscontrole verhoogt de beschikbaarheid van uw toepassing door aanvragen om te leiden weg van exemplaren die niet in orde zijn en exemplaren te vervangen als ze niet in orde blijven. Uw App Service moet worden geschaald naar twee of meer exemplaren om de statuscontrole volledig te kunnen gebruiken. Het statuscontrolepad moet essentiële onderdelen van uw toepassing controleren. Als uw toepassing bijvoorbeeld afhankelijk is van een database en een berichtensysteem, moet het eindpunt van de statuscontrole verbinding maken met deze onderdelen. Als de toepassing geen verbinding kan maken met een kritiek onderdeel, moet het pad een responscode van 500-niveau retourneren om aan te geven dat de app niet in orde is.

Fout bij statuscontrole

Wat App Service met statuscontroles

Wanneer u een pad in uw app krijgt, pingt de statuscontrole dit pad op alle exemplaren van uw App Service app met intervallen van 1 minuut.
Als een exemplaar niet reageert met een statuscode tussen 200-299 (inclusief) na twee of meer aanvragen, of niet reageert op de ping, bepaalt het systeem dat deze niet in orde is en wordt deze verwijderd.
Na verwijdering blijft de statuscontrole het exemplaar dat niet in orde is pingen. Als het exemplaar begint te reageren met een statuscode die in orde is (200-299), wordt het exemplaar geretourneerd naar de load balancer.
Als een exemplaar gedurende één uur niet in orde blijft, wordt deze vervangen door een nieuw exemplaar.
Wanneer u omhoog of uitschaalt, App Service bovendien het statuscontrolepad pingen om ervoor te zorgen dat nieuwe exemplaren gereed zijn.

Notitie

Statuscontrole volgt geen 302-omleidingen. Maximaal één exemplaar wordt per uur vervangen, met maximaal drie exemplaren per dag per App Service abonnement.
Opmerking: als uw statuscontrole de status geeft, mislukt de controle waarschijnlijk vanwege de Waiting for health check response HTTP-statuscode 307. Dit kan gebeuren als u HTTPS-omleiding hebt ingeschakeld, maar is HTTPS Only uitgeschakeld.

Statuscontrole inschakelen

Navigatie voor statuscontrole in Azure Portal

Als u Statuscontrole wilt inschakelen, bladert u naar Azure Portal en selecteert u uw App Service app.
Selecteer onder Bewaking de optie Statuscontrole.
Selecteer Inschakelen en geef een geldig URL-pad op voor uw toepassing, zoals /health of /api/health .
Klik op Opslaan.

Waarschuwing

Statuscontroleconfiguratiewijzigingen starten uw app opnieuw op. Om de gevolgen voor productie-apps te minimaliseren, raden we u aan om faseringssleuven te configureren en om te wisselen naar productie.

Configuratie

Naast het configureren van de opties voor statuscontrole kunt u ook de volgende app-instellingen configureren:

Naam van app-instelling	Toegestane waarden	Description
`WEBSITE_HEALTHCHECK_MAXPINGFAILURES`	2 - 10	Het vereiste aantal mislukte aanvragen voor een exemplaar dat als niet in orde moet worden beschouwd en uit de load balancer. Als deze bijvoorbeeld is ingesteld op `2` , worden uw exemplaren verwijderd na mislukte `2` pings. (standaardwaarde is `10`)
`WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT`	0 - 100	Standaard wordt niet meer dan de helft van de exemplaren tegelijk uitgesloten van de load balancer om te voorkomen dat de resterende gezonde exemplaren worden overstelpen. Als bijvoorbeeld een App Service-abonnement wordt geschaald naar vier exemplaren en drie exemplaren een slechte status hebben, worden er twee uitgesloten. De andere twee exemplaren (één in orde en één met een slechte status) blijven aanvragen ontvangen. In het ergste geval waarin alle exemplaren een slechte status hebben, wordt er geen uitgesloten. Als u dit gedrag wilt overschrijven, stelt u de app-instelling in op een waarde tussen `0` en `100` . Een hogere waarde betekent dat meer exemplaren met slechte status worden verwijderd (de standaardwaarde is `50` ).

Verificatie en beveiliging

Statuscontrole kan worden geïntegreerd met App Service verificatie- en autorisatiefuncties van uw systeem. Er zijn geen aanvullende instellingen vereist als deze beveiligingsfuncties zijn ingeschakeld.

Als u uw eigen verificatiesysteem gebruikt, moet het statuscontrolepad anonieme toegang toestaan. Als u het eindpunt van de statuscontrole wilt beveiligen, moet u eerst functies zoals IP-beperkingen, clientcertificatenof een Virtual Network om de toegang tot toepassingen te beperken. U kunt het eindpunt van de statuscontrole beveiligen door te vereisen User-Agent dat de van de binnenkomende aanvraag overeenkomt met HealthCheck/1.0 . De User-Agent kunnen niet worden vervalst omdat de aanvraag al zou worden beveiligd door eerdere beveiligingsfuncties.

Bewaking

Nadat u het statuscontrolepad van uw toepassing hebt opgeslagen, kunt u de status van uw site controleren met behulp van Azure Monitor. Klik op de blade Statuscontrole in de portal op de Metrische gegevens in de bovenste werkbalk. Hiermee opent u een nieuwe blade waar u de historische status van de site kunt zien en een nieuwe waarschuwingsregel kunt maken. Zie voor meer informatie over het bewaken van uw sites de handleiding over Azure Monitor.

Beperkingen

Statuscontrole mag niet worden ingeschakeld op Premium Functions-sites. Vanwege het snelle schalen van Premium Functions, kunnen statuscontroleaanvragen onnodige schommelingen in HTTP-verkeer veroorzaken. Premium Functies hebben hun eigen interne statustests die worden gebruikt om schaalbeslissingen te nemen.
Statuscontrole kan worden ingeschakeld voor gratis en gedeelde App Service-abonnementen, zodat u metrische gegevens over de status van de site kunt hebben en waarschuwingen kunt instellen, maar omdat gratis en gedeelde sites niet kunnen worden geschaald, worden slechte exemplaren niet vervangen. U moet omhoog schalen naar de basic-laag of hoger, zodat u kunt uitschalen naar 2 of meer exemplaren en het volledige voordeel van statuscontrole kunt gebruiken. Dit wordt aanbevolen voor productietoepassingen, omdat dit de beschikbaarheid en prestaties van uw app verhoogt.

Veelgestelde vragen

Wat gebeurt er als mijn app wordt uitgevoerd op één exemplaar?

Als uw app slechts naar één exemplaar wordt geschaald en beschadigd raakt, wordt deze niet verwijderd uit de load balancer omdat uw toepassing hierdoor volledig uit bedrijf wordt genomen. Schaal uit naar twee of meer exemplaren naar twee of meer exemplaren om het voordeel van de statuscontrole voor opnieuw routeren te krijgen. Als uw app wordt uitgevoerd op één exemplaar, kunt u nog steeds de controlefunctie van de statuscontrole gebruiken om de status van uw toepassing bij te houden.

Waarom wordt de statuscontroleaanvraag niet weergegeven in mijn front-endlogboeken?

De statuscontroleaanvraag wordt intern naar uw site verzonden, zodat de aanvraag niet wordt weer geven in de front-endlogboeken. Dit betekent ook dat de aanvraag een oorsprong heeft van omdat de 127.0.0.1 aanvraag intern wordt verzonden. U kunt logboekverklaringen toevoegen aan uw statuscontrolecode om logboeken bij te houden wanneer uw statuscontrolepad wordt gepingd.

Worden de statuscontroleaanvragen verzonden via HTTP of HTTPS?

Aan Windows App Service worden de statuscontroleaanvragen verzonden via HTTPS wanneer alleen HTTPS is ingeschakeld op de site. Anders worden ze verzonden via HTTP. Op Linux App Service worden de statuscontroleaanvragen alleen verzonden via HTTP en kunnen ze op dit moment niet worden verzonden via HTTP S.

Wat gebeurt er als ik meerdere apps op hetzelfde App Service heb?

Exemplaren met een slechte status worden altijd verwijderd uit de load balancer rotatie, ongeacht andere apps in het App Service-abonnement (tot het percentage dat is opgegeven in WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT ). Wanneer een app op een exemplaar gedurende meer dan een uur niet in orde blijft, wordt het exemplaar alleen vervangen als alle andere apps waarop Statuscontrole is ingeschakeld, ook niet in orde zijn. Er wordt geen rekening gehouden met apps waarvoor statuscontrole is ingeschakeld.

Voorbeeld

Imagine hebt u twee toepassingen (of één app met een sleuf) met Statuscontrole ingeschakeld, App A en App B genoemd. Ze hebben dezelfde App Service plan en dat het plan wordt geschaald naar 4 exemplaren. Als App A op twee exemplaren niet meer in orde is, stopt de load balancer het verzenden van aanvragen naar App A op deze twee exemplaren. Aanvragen worden op die instanties nog steeds doorgeleid naar App B, mits App B in orde is. Als App A gedurende meer dan een uur niet in orde is op deze twee exemplaren, worden deze exemplaren alleen vervangen als app B ook een slechte status heeft op deze instanties. Als App B in orde is, wordt het exemplaar niet vervangen.

Visueel diagram waarin het bovenstaande voorbeeldscenario wordt uitgelegd.

Notitie

Als er een andere site of site op het plan (Site C) is zonder dat statuscontrole is ingeschakeld, wordt er geen rekening gehouden met de exemplaarvervanging.

Wat gebeurt er als al mijn exemplaren niet in orde zijn?

In het scenario waarin alle exemplaren van uw toepassing beschadigd zijn, App Service exemplaren uit de load balancer tot het percentage dat is opgegeven in WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT . In dit scenario zou het verwijderen van alle exemplaren van slechte apps uit de roulatie load balancer leiden tot een storing voor uw toepassing.

Werkt statuscontrole in App Service omgevingen?

Ja, op App Service-omgevingen (ASE's) pingt het platform uw exemplaren op het opgegeven pad en verwijdert het exemplaren met een slechte status uit de load balancer zodat aanvragen er niet naar worden doorgeleid. Deze exemplaren met een slechte status worden momenteel echter niet vervangen door nieuwe exemplaren als ze gedurende één uur niet in orde blijven.