App Service-exemplaren bewaken met behulp van statuscontrole

In dit artikel wordt health check in Azure Portal gebruikt om App Service-exemplaren te bewaken. De statuscontrole verhoogt de beschikbaarheid van uw toepassing door aanvragen weg te routeren van beschadigde exemplaren en instanties te vervangen als ze niet in orde zijn. Dit doet u door elke minuut een pad naar uw webtoepassing naar keuze te pingen.

Houd er rekening mee dat /api/health slechts een voorbeeld is dat is toegevoegd voor illustratiedoeleinden. We maken standaard geen pad voor statuscontrole. Zorg ervoor dat het pad dat u selecteert een geldig pad is dat bestaat in uw toepassing

Wat App Service doet met statuscontroles

• Wanneer u een pad op uw app krijgt, pingt Health dit pad op alle exemplaren van uw App Service-app met intervallen van 1 minuut.
• Als een web-app die wordt uitgevoerd op een bepaald exemplaar niet reageert met een statuscode tussen 200 en 299 (inclusief) na 10 aanvragen, bepaalt App Service dat deze niet in orde is en wordt deze verwijderd uit de load balancer voor deze web-app. Het vereiste aantal mislukte aanvragen voor een exemplaar dat als niet in orde wordt beschouwd, kan worden geconfigureerd tot minimaal twee aanvragen.
• Na verwijdering blijft de statuscontrole de beschadigde instantie pingen. Als het exemplaar begint te reageren met een statuscode (200-299), wordt het exemplaar teruggezet naar de load balancer.
• Als de web-app die wordt uitgevoerd op een exemplaar één uur niet in orde blijft, wordt de instantie vervangen door een nieuwe.
• Wanneer u uitschaalt, pingt App Service het pad Statuscontrole om ervoor te zorgen dat nieuwe exemplaren gereed zijn.

Notitie

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

Statuscontrole inschakelen

1. Als u statuscontrole wilt inschakelen, bladert u naar Azure Portal en selecteert u uw App Service-app.
2. Selecteer Statuscontrole onder Controleren.
3. Selecteer Inschakelen en geef een geldig URL-pad op voor uw toepassing, zoals /health of /api/health.
4. Selecteer Opslaan.

Notitie

• Uw App Service-plan moet worden geschaald naar twee of meer exemplaren om de statuscontrole volledig te kunnen gebruiken.
• Het pad statuscontrole moet kritieke 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 antwoordcode op 500-niveau retourneren om aan te geven dat de app niet in orde is. Als het pad binnen 1 minuut geen antwoord retourneert, wordt de statuscontrole ping als beschadigd beschouwd.
• Wanneer u het pad Statuscontrole selecteert, moet u ervoor zorgen dat u een pad selecteert dat een statuscode van 200 retourneert, alleen wanneer de app volledig is opgewarmd.
• Als u statuscontrole wilt gebruiken voor uw functie-app, moet u een premium- of toegewezen hostingabonnement gebruiken.
• Meer informatie over statuscontrole in functie-apps vindt u hier: Functie-apps bewaken met statuscontrole.

Let op

Configuratiewijzigingen voor statuscontrole starten uw app opnieuw op. Om de impact op productie-apps te minimaliseren, raden we u aan faseringssites te configureren en over te schakelen naar productie.

Configuratie

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

Naam van de app-instelling	Toegestane waarden	Beschrijving
WEBSITE_HEALTHCHECK_MAXPINGFAILURES	2 - 10	Het vereiste aantal mislukte aanvragen voor een exemplaar dat als niet in orde wordt beschouwd en uit de load balancer wordt verwijderd. Wanneer de instelling bijvoorbeeld is ingesteld 2, worden uw exemplaren verwijderd na 2 mislukte pings. (Standaardwaarde is 10)
WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT	1 - 100	Standaard worden niet meer dan de helft van de exemplaren tegelijk uitgesloten van de load balancer om te voorkomen dat de resterende gezonde exemplaren worden overstuurd. Als een App Service-plan bijvoorbeeld wordt geschaald naar vier exemplaren en drie niet in orde zijn, worden er twee uitgesloten. De andere twee exemplaren (één in orde en één beschadigde) blijven aanvragen ontvangen. In het slechtste scenario waarin alle exemplaren niet in orde zijn, worden geen exemplaren uitgesloten. Als u dit gedrag wilt overschrijven, stelt u de app-instelling in op een waarde tussen 1 en 100. Een hogere waarde betekent dat meer beschadigde exemplaren worden verwijderd (standaardwaarde is 50).

Verificatie en beveiliging

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

Als u uw eigen verificatiesysteem gebruikt, moet het pad statuscontrole anonieme toegang toestaan. Als u het eindpunt statuscontrole wilt beveiligen, moet u eerst functies zoals IP-beperkingen, clientcertificaten of een virtueel netwerk gebruiken om de toegang tot toepassingen te beperken. Zodra u deze functies in-place hebt, kunt u de statuscontroleaanvraag verifiëren door de header x-ms-auth-internal-tokente inspecteren en te valideren dat deze overeenkomt met de SHA256-hash van de omgevingsvariabele WEBSITE_AUTH_ENCRYPTION_KEY. Als deze overeenkomen, is de statuscontroleaanvraag geldig en afkomstig van App Service.

Notitie

Met name voor Azure Functions-verificatie moet de functie die als statuscontrole-eindpunt fungeert anonieme toegang toestaan.

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

Notitie

De x-ms-auth-internal-token header is alleen beschikbaar in Windows App Service.

Exemplaren

Zodra statuscontrole is ingeschakeld, kunt u de status van uw toepassingsexemplaren opnieuw starten en controleren via het tabblad Exemplaren. Het tabblad Exemplaren toont de naam van uw exemplaar, de status van het exemplaar van die toepassing en geeft u de mogelijkheid om het exemplaar handmatig opnieuw op te starten.

Als de status van uw toepassingsexemplaren niet in orde is, kunt u het exemplaar handmatig opnieuw opstarten met behulp van de knop Opnieuw opstarten in de tabel. Houd er rekening mee dat andere toepassingen die worden gehost in hetzelfde App Service-plan, ook worden beïnvloed door het opnieuw opstarten van het exemplaar. Als er andere toepassingen zijn die gebruikmaken van hetzelfde App Service-plan als het exemplaar, worden ze weergegeven op de blade Openen vanaf de knop Opnieuw opstarten.

Als u het exemplaar opnieuw opstart en het proces voor opnieuw opstarten mislukt, krijgt u de optie om de werkrol te vervangen (er kan slechts één exemplaar per uur worden vervangen). Dit is ook van invloed op alle toepassingen die gebruikmaken van hetzelfde App Service-plan.

Windows-toepassingen hebben ook de mogelijkheid om processen weer te geven via Process Explorer. Hiermee krijgt u meer inzicht in de processen van het exemplaar, waaronder het aantal threads, het privégeheugen en de totale CPU-tijd.

Het verzamelen van diagnostische gegevens

Voor Windows-toepassingen kunt u diagnostische gegevens verzamelen op het tabblad Statuscontrole. Als u diagnostische verzameling inschakelt, wordt een regel voor automatisch herstellen toegevoegd waarmee geheugendumps voor beschadigde exemplaren worden gemaakt en opgeslagen in een aangewezen opslagaccount. Als u deze optie inschakelt, worden configuraties voor automatisch herstellen gewijzigd. Als er bestaande regels voor automatisch herstellen zijn, raden we u aan dit in te stellen via Diagnostische gegevens van App Service.

Zodra diagnostische verzameling is ingeschakeld, kunt u een bestaand opslagaccount voor uw bestanden maken of kiezen. U kunt alleen opslagaccounts selecteren in dezelfde regio als uw toepassing. Houd er rekening mee dat het opslaan van uw toepassing opnieuw wordt gestart. Als na het opslaan blijkt dat uw site-exemplaren beschadigd zijn na continue pings, kunt u naar uw opslagaccountresource gaan en de geheugendumps bekijken.

Controleren

Nadat u het statuscontrolepad van uw toepassing hebt opgegeven, kunt u de status van uw site bewaken met behulp van Azure Monitor. Selecteer op de blade Statuscontrole in de portal de metrische gegevens op de bovenste werkbalk. Hiermee opent u een nieuwe blade waarin u de historische status van de site en de optie voor het maken van een nieuwe waarschuwingsregel kunt zien. Metrische statuscontrolegegevens aggregeren de geslaagde pings en weergavefouten alleen wanneer het exemplaar als beschadigd werd beschouwd op basis van de statuscontroleconfiguratie. Zie de handleiding voor Azure Monitor voor meer informatie over het bewaken van uw sites.

Beperkingen

• Statuscontrole kan worden ingeschakeld voor gratis en gedeelde App Service-abonnementen, zodat u metrische gegevens kunt hebben over de status- en instellingswaarschuwingen van de site, maar omdat gratis en gedeelde sites niet kunnen worden uitgeschaald, worden beschadigde 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 productiegerichte toepassingen, omdat hiermee de beschikbaarheid en prestaties van uw app worden verhoogd.
• Het App Service-plan kan maximaal één beschadigde instantie per uur vervangen hebben en maximaal drie exemplaren per dag.
• Er is een niet-configureerbare limiet voor het totale aantal exemplaren dat is vervangen door statuscontrole per schaaleenheid. Als deze limiet is bereikt, worden er geen beschadigde exemplaren vervangen. Deze waarde wordt elke 12 uur opnieuw ingesteld.

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 hierdoor uw toepassing volledig wordt uitgeschakeld. Na een uur doorlopende beschadigde pings wordt het exemplaar echter vervangen. Schaal uit naar twee of meer exemplaren om het rerouting-voordeel van de statuscontrole te krijgen. Als uw app wordt uitgevoerd op één exemplaar, kunt u de bewakingsfunctie van health check nog steeds gebruiken om de status van uw toepassing bij te houden.

Waarom worden de statuscontroleaanvragen niet weergegeven in mijn webserverlogboeken?

De statuscontroleaanvragen worden intern naar uw site verzonden, zodat de aanvraag niet wordt weergegeven in de webserverlogboeken. U kunt logboekinstructies toevoegen aan uw statuscontrolecode om logboeken bij te houden wanneer uw pad voor statuscontrole wordt pingen.

Worden de statuscontroleaanvragen verzonden via HTTP of HTTPS?

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

Wordt statuscontrole uitgevoerd na de door de toepassingscode geconfigureerde omleidingen tussen het standaarddomein en het aangepaste domein?

Nee, de functie Statuscontrole pingt het pad van het standaarddomein van de webtoepassing. Als er een omleiding van het standaarddomein naar een aangepast domein is, wordt de statuscode die de statuscontrole retourneert, geen 200, maar een omleiding (301), die de werkrol in orde zal markeren.

Wat gebeurt er als ik meerdere apps in hetzelfde App Service-plan heb?

Beschadigde exemplaren worden altijd verwijderd uit de load balancer-rotatie, ongeacht andere apps in het App Service-plan (tot het opgegeven percentage).WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT Wanneer een app op een exemplaar langer dan een uur niet in orde blijft, wordt het exemplaar alleen vervangen als alle andere apps waarvoor statuscontrole is ingeschakeld, ook niet in orde zijn. Apps waarvoor geen statuscontrole is ingeschakeld, worden niet meegenomen.

Opmerking

Stel dat u twee toepassingen (of één app met een site) hebt waarvoor Statuscontrole is ingeschakeld, app A en app B. Ze bevinden zich in hetzelfde App Service-plan en dat het plan wordt uitgeschaald naar vier exemplaren. Als App A beschadigd raakt op twee exemplaren, stopt de load balancer met het verzenden van aanvragen naar App A op deze twee exemplaren. Aanvragen worden nog steeds doorgestuurd naar App B op die exemplaren, ervan uitgaande dat App B in orde is. Als App A langer dan een uur in orde blijft op deze twee exemplaren, worden deze exemplaren alleen vervangen als App B ook niet in orde is op die exemplaren. Als app B in orde is, wordt het exemplaar niet vervangen.

Notitie

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

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

In het scenario waarin alle exemplaren van uw toepassing niet in orde zijn, verwijdert App Service geen exemplaren uit de load balancer. In dit scenario zou het nemen van alle beschadigde app-exemplaren uit de load balancer-rotatie een storing voor uw toepassing veroorzaken; de vervanging van exemplaren wordt echter nog steeds uitgevoerd.

Werkt statuscontrole in App Service-omgevingen?

Ja, statuscontrole is beschikbaar voor de App Service Environment v3, maar niet voor versie 1 of 2. Als u de oudere versies van de App Service Environment gebruikt, kunt u de migratiefunctie gebruiken om uw App Service Environment te migreren naar versie 3.

Volgende stappen

• Een waarschuwing voor activiteitenlogboek maken om alle bewerkingen van de engine voor automatisch schalen in uw abonnement te bewaken
• Een waarschuwing voor activiteitenlogboek maken om alle mislukte schaalbewerkingen voor automatisch schalen/uitschalen in uw abonnement te controleren
• Naslaginformatie over omgevingsvariabelen en app-instellingen