App Service-exemplaren bewaken met behulp van statuscontrole

Notitie

Vanaf 1 juni 2024 hebben alle nieuw gemaakte App Service-apps de mogelijkheid om een unieke standaardhostnaam te genereren met behulp van de naamconventie <app-name>-<random-hash>.<region>.azurewebsites.net. Bestaande app-namen blijven ongewijzigd.

Voorbeeld: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Raadpleeg de unieke standaardhostnaam voor App Service-resource voor meer informatie.

In dit artikel wordt beschreven hoe u 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 uw webtoepassing te pingen, via een pad dat u kiest.

Houd er rekening mee dat /api/health slechts een voorbeeld is. Er is geen standaardpad voor statuscontrole. Zorg ervoor dat het pad dat u kiest een geldig pad is dat in uw toepassing aanwezig is.

Hoe statuscontrole werkt

• Wanneer u een pad op uw app hebt gekregen, pingt Health het 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 het exemplaar niet in orde is en verwijdert deze uit de load balancer voor de web-app. Het vereiste aantal mislukte aanvragen voor een exemplaar dat als niet in orde wordt beschouwd, kan worden geconfigureerd tot minimaal twee aanvragen.
• Nadat het exemplaar is verwijderd, blijft de statuscontrole deze 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 door maximaal drie exemplaren per dag per App Service-plan.
• Als de statuscontrole de status Waiting for health check responseverzendt, mislukt de controle waarschijnlijk vanwege een HTTP-statuscode van 307. Dit kan gebeuren als https-omleiding is ingeschakeld, maar deze 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 één minuut geen antwoord retourneert, wordt de ping van de statuscontrole als beschadigd beschouwd.
• Wanneer u het pad Statuscontrole selecteert, moet u ervoor zorgen dat u een pad selecteert dat alleen een 200-statuscode retourneert wanneer de app volledig is opgewarmd.
• Als u Statuscontrole wilt gebruiken voor een 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. Als dit bijvoorbeeld is ingesteld 2op, worden uw exemplaren verwijderd na 2 mislukte pings. (De standaardwaarde is 10.)
WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT	1 - 100	Standaard wordt niet meer dan de helft van de exemplaren tegelijk uitgesloten van de load balancer om de resterende gezonde exemplaren te overweldigen. 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 een scenario waarin alle exemplaren niet in orde zijn, worden geen exemplaren uitgesloten. Als u dit gedrag wilt overschrijven, stelt u deze app-instelling in op een waarde tussen 1 en 100. Een hogere waarde betekent dat meer beschadigde exemplaren worden verwijderd. (De standaardwaarde is 50.).

Verificatie en beveiliging

Statuscontrole kan worden geïntegreerd met de App Service-verificatie - en autorisatiefuncties. 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 beveiliging wilt bieden voor het eindpunt statuscontrole, moet u eerst functies zoals IP-beperkingen, clientcertificaten of een virtueel netwerk gebruiken om de toegang tot toepassingen te beperken. Zodra u deze functies hebt geïmplementeerd, kunt u de statuscontroleaanvraag verifiëren door de header x-ms-auth-internal-token te controleren 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

Voor Azure Functions-verificatie moet de functie die fungeert als het eindpunt statuscontrole 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 App Service voor Windows.

Exemplaren

Zodra statuscontrole is ingeschakeld, kunt u de status van uw toepassingsexemplaren opnieuw starten en controleren vanaf het tabblad Exemplaren. Op het tabblad Exemplaren ziet u de naam van uw exemplaar en de status van het exemplaar van die toepassing. U kunt het exemplaar ook handmatig opnieuw opstarten vanaf dit tabblad.

Als de status van uw toepassingsexemplaren 'beschadigd' 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 deze 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.

Voor Windows-toepassingen kunt u ook processen bekijken via Process Explorer. Dit geeft 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 hebt u de mogelijkheid om diagnostische gegevens te 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 opslagaccount maken of een bestaande voor uw bestanden 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 metrische gegevens op de bovenste werkbalk. Hiermee opent u een nieuwe blade waarin u de statusgeschiedenis van de site kunt zien en een nieuwe waarschuwingsregel kunt maken. Metrische statuscontrolegegevens aggregeren de geslaagde pings en weergavefouten alleen wanneer het exemplaar als beschadigd werd beschouwd op basis van de statuscontroleconfiguratie. Zie Azure-app Servicequota en -waarschuwingen 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 over de status van de site kunt hebben en waarschuwingen kunt instellen. Omdat gratis en gedeelde sites echter niet kunnen worden uitgeschaald, worden beschadigde exemplaren niet vervangen. U moet omhoog schalen naar de Basic-laag of hoger, zodat u kunt uitschalen naar twee of meer exemplaren en het volledige voordeel van statuscontrole kunt krijgen. Dit wordt aanbevolen voor productiegerichte toepassingen, omdat deze de beschikbaarheid en prestaties van uw app verhoogt.
• Een App Service-plan kan maximaal één beschadigde instantie per uur vervangen 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 uw toepassing hierdoor 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 nog steeds de functie Statuscontrole 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 statuscontroleaanvragen verzonden via HTTP of HTTPS?

In App Service voor Windows en Linux worden de statuscontroleaanvragen verzonden via HTTPS wanneer HTTPS alleen is ingeschakeld op de site. Anders worden ze verzonden via HTTP.

Volgt de statuscontrole 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, is de statuscode die door de statuscontrole wordt geretourneerd, geen 200. Het is een omleiding (301), die de werkrol als beschadigd markeert.

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 één uur niet in orde blijft, wordt het exemplaar alleen vervangen als alle andere apps waarop statuscontrole is ingeschakeld, ook beschadigd 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. Ze worden App A en App B genoemd. Ze bevinden zich in hetzelfde App Service-plan en 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 deze exemplaren, ervan uitgaande dat App B in orde is. Als App A langer dan een uur in orde blijft op deze twee exemplaren, worden de exemplaren alleen vervangen als App B ook niet in orde is op deze exemplaren. Als app B in orde is, worden de exemplaren niet vervangen.

Notitie

Als er een andere site of site op het plan (App 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?

Als 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 instantievervanging vindt echter nog steeds plaats.

Werkt statuscontrole in App Service-omgevingen?

Ja, statuscontrole is beschikbaar voor App Service Environment v3, maar niet voor versie 1 of 2. Als u de oudere versies van 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