Überwachen von App Service-Instanzen mit der Integritätsprüfung

Hinweis

Ab dem 1. Juni 2024 haben alle neu erstellten App Service-Apps die Möglichkeit, einen eindeutigen Standardhostnamen mit der Namenskonvention <app-name>-<random-hash>.<region>.azurewebsites.net zu erstellen. Vorhandene App-Namen bleiben unverändert.

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

Ausführlichere Informationen finden Sie unter Eindeutiger Standardhostname für App Service-Ressourcen.

Dieser Artikel beschreibt, wie Sie die Integritätsprüfung im Azure-Portal verwenden, um App Service-Instanzen zu überwachen. Die Integritätsprüfung erhöht die Verfügbarkeit Ihrer Anwendung, indem Anforderungen von fehlerhaften Instanzen weggeleitet und Instanzen ersetzt werden, wenn sie fehlerhaft bleiben. Dies geschieht, indem Sie Ihre Webanwendung jede Minute über einen von Ihnen ausgewählten Pfad pingen.

Beachten Sie, dass /api/health nur ein Beispiel ist. Es gibt keinen standardmäßigen Pfad für die Integritätsprüfung. Sie müssen sicherstellen, dass der von Ihnen ausgewählte Pfad ein gültiger Pfad ist, der in Ihrer Anwendung vorhanden ist.

Funktionsweise der Integritätsprüfung

• Wenn der Integritätsprüfung ein Pfad zu Ihrer App übergeben wird, pingt diese den Pfad bei allen Instanzen Ihrer App Service-App in Intervallen von 1 Minute.
• Wenn eine Web-App, die auf einer bestimmten Instanz ausgeführt wird, nach 10 Anforderungen nicht mit einem Statuscode zwischen 200 und 299 (einschließlich) antwortet, stellt App Service fest, dass die Instanz fehlerhaft ist, und entfernt sie aus dem Lastenausgleich für diese Web-App. Die erforderliche Anzahl fehlerhafter Anforderungen, damit eine Instanz als fehlerhaft eingestuft wird, kann auf ein Minimum von zwei Anforderungen konfiguriert werden.
• Nachdem die Instanz entfernt wurde, fährt die Integritätsprüfung mit dem Pingen fort. Wenn die Instanz mit einem fehlerfreien Statuscode (200–299) zu antworten beginnt, wird die Instanz an den Lastenausgleich zurückgegeben.
• Wenn die Web-App, die auf einer Instanz ausgeführt wird, eine Stunde lang fehlerhaft bleibt, wird die Instanz durch eine neue ersetzt.
• Beim Aufskalieren pingt App Service den Pfad der Integritätsüberprüfung, um sicherzustellen, dass neue Instanzen bereit sind.

Hinweis

• Die Integritätsprüfung folgt keinen 302-Umleitungen.
• Pro Stunde wird höchstens eine Instanz ersetzt, wobei der Maximalwert bei drei Instanzen pro Tag und App Service-Plan liegt.
• Wenn die Integritätsprüfung den Status Waiting for health check response sendet, schlägt die Prüfung wahrscheinlich aufgrund eines HTTP-Statuscodes von 307 fehl, was passieren kann, wenn Sie die HTTPS-Umleitung aktiviert, aber HTTPS Only deaktiviert haben.

Aktivieren der Integritätsprüfung

1. Um die Integritätsprüfung zu aktivieren, wechseln Sie zum Azure-Portal, und wählen Sie Ihre App Service-App aus.
2. Wählen Sie unter Überwachung die Option Integritätsprüfung aus.
3. Wählen Sie Aktivieren aus, und geben Sie einen gültigen URL-Pfad für Ihre Anwendung an, z. B. /health oder /api/health.
4. Klicken Sie auf Speichern.

Hinweis

• Ihr App Service-Plan sollte auf zwei oder mehr Instanzen skaliert sein, um die Integritätsprüfung in vollem Umfang nutzen zu können.
• Der Pfad der Integritätsüberprüfung sollte die kritischen Komponenten Ihrer Anwendung überprüfen. Wenn Ihre Anwendung z. B. von einer Datenbank und einem Messagingsystem abhängig ist, sollte der Endpunkt der Integritätsüberprüfung eine Verbindung mit diesen Komponenten herstellen. Wenn die Anwendung keine Verbindung mit einer kritischen Komponente herstellen kann, sollte der Pfad einen Antwortcode auf 500-Ebene zurückgeben, um damit anzugeben, dass die App fehlerhaft ist. Wenn der Pfad innerhalb von einer Minute keine Antwort zurückgibt, wird der Ping der Integritätsprüfung ebenfalls als fehlerhaft betrachtet.
• Stellen Sie beim Auswählen des Pfads für die Integritätsprüfung sicher, dass Sie einen Pfad auswählen, der nur dann einen Statuscode 200 zurückgibt, wenn die App vollständig hochgefahren ist.
• Um die Integritätsprüfung für Ihre Funktions-App zu verwenden, müssen Sie einen Premium- oder dediziertem Hostingplan verwenden.
• Details zur Integritätsprüfung für Funktions-Apps finden Sie hier: Überwachen von Funktions-Apps mithilfe der Integritätsprüfung.

Achtung

Durch Änderungen an der Konfiguration der Integritätsprüfung wird Ihre App neu gestartet. Um die Auswirkungen auf Produktions-Apps zu minimieren, empfehlen wir, Stagingslots zu konfigurieren und diese in die Produktion zu tauschen.

Konfiguration

Zusätzlich zum Konfigurieren der Optionen der Integritätsprüfung können Sie auch die folgenden App-Einstellungen konfigurieren:

Name der App-Einstellung	Zulässige Werte	BESCHREIBUNG
WEBSITE_HEALTHCHECK_MAXPINGFAILURES	2–10	Die erforderliche Anzahl fehlerhafter Anforderungen, damit eine Instanz als fehlerhaft eingestuft und aus dem Lastenausgleich entfernt wird. Wenn dies beispielsweise auf 2 festgelegt ist, werden Ihre Instanzen nach 2 fehlerhaften Pings entfernt. (Der Standardwert ist 10.)
WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT	1–100	Um zu vermeiden, dass die verbleibenden fehlerfreien Instanzen überlastet werden, werden standardmäßig nicht mehr als die Hälfte der Instanzen gleichzeitig aus dem Lastenausgleich ausgeschlossen. Wenn z. B. ein App Service-Plan auf vier Instanzen skaliert ist und drei fehlerhaft sind, werden zwei ausgeschlossen. Die anderen beiden Instanzen (eine fehlerfreie und eine fehlerhafte) empfangen weiterhin Anforderungen. In einem Szenario, in dem alle Instanzen fehlerhaft sind, wird keine ausgeschlossen. Um dieses Verhalten zu überschreiben, legen Sie diese App-Einstellung auf einen Wert zwischen 1 und 100 fest. Ein höherer Wert führt dazu, dass mehr fehlerhafte Instanzen entfernt werden. (Der Standardwert ist 50.).

Authentifizierung und Sicherheit

Die Integritätsprüfung integriert sich in die Authentifizierungs- und Autorisierungsfeatures von App Service. Es sind keine anderen Einstellungen erforderlich, wenn diese Sicherheitsfeatures aktiviert sind.

Wenn Sie ein eigenes Authentifizierungssystem verwenden, muss der Pfad der Integritätsüberprüfung anonymen Zugriff zulassen. Um Sicherheit für den Endpunkt der Integritätsprüfung bereitzustellen, sollten Sie zunächst Features wie IP-Einschränkungen, Clientzertifikate oder ein virtuelles Netzwerk verwenden, um den Anwendungszugriff einzuschränken. Sobald Sie diese Features installiert haben, können Sie die Integritätsprüfungsanforderung authentifizieren, indem Sie den Header x-ms-auth-internal-token überprüfen und validieren, ob er dem SHA256-Hash der Umgebungsvariablen WEBSITE_AUTH_ENCRYPTION_KEY entspricht. Wenn sie übereinstimmen, ist die Integritätsprüfungsanforderung gültig und stammt aus App Service.

Hinweis

Speziell für die Azure Functions-Authentifizierung muss die Funktion, die als Endpunkt für die Integritätsprüfung dient, anonymen Zugriff zulassen.

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

Hinweis

Der Header x-ms-auth-internal-token ist nur in App Service für Windows verfügbar.

Instanzen

Sobald die Integritätsprüfung aktiviert ist, können Sie Ihre Anwendungsinstanzen über die Registerkarte „Instanzen“ neu starten und den Status überwachen. Auf der Registerkarte „Instanzen“ werden der Name Ihrer Instanz und der Status der Instanz dieser Anwendung angezeigt. Sie können die Instanz auch manuell über diese Registerkarte neu starten.

Wenn Ihre Anwendungsinstanz einen Status „fehlerhaft“ aufweist, können Sie die Instanz mithilfe der Schaltfläche „Neustart“ in der Tabelle manuell neu starten. Beachten Sie, dass alle anderen Anwendungen, die auf demselben App Service-Plan wie die Instanz gehostet werden, ebenfalls vom Neustart betroffen sind. Wenn es andere Anwendungen gibt, die denselben App Service-Plan wie die Instanz verwenden, werden diese auf dem geöffneten Blatt nach Auswählen der Schaltfläche „Neustart“ aufgeführt.

Wenn Sie die Instanz neu starten und der Neustartvorgang fehlschlägt, erhalten Sie die Möglichkeit, den Worker zu ersetzen. (Pro Stunde kann nur eine Instanz ersetzt werden.) Dies wirkt sich auch auf alle Anwendungen aus, die denselben App Service-Plan verwenden.

Für Windows-Anwendungen können Sie Prozesse auch über den Prozess-Explorer anzeigen. Dadurch erhalten Sie weitere Erkenntnisse in die Prozesse der Instanz, einschließlich Threadanzahl, privater Arbeitsspeicher und Gesamt-CPU-Zeit.

Sammlung von Diagnoseinformationen

Für Windows-Anwendungen haben Sie die Möglichkeit, Diagnoseinformationen auf der Registerkarte „Integritätsprüfung“ zu sammeln. Durch aktivieren der Diagnosesammlung wird eine Regel zum automatischen Korrigieren hinzugefügt, die Speicherabbilder für fehlerhafte Instanzen erstellt und sie in einem designierten Speicherkonto speichert. Durch Aktivieren dieser Option werden die Konfigurationen für die automatische Reparatur geändert. Wenn Regeln für die automatische Reparatur vorhanden sind, empfiehlt es sich, dies über die App Service-Diagnose einzurichten.

Sobald die Diagnosesammlung aktiviert ist, können Sie ein Speicherkonto erstellen oder ein bestehendes Konto für Ihre Dateien auswählen. Sie können nur Speicherkonten auswählen, die sich in derselben Region wie Ihre Anwendung befinden. Denken Sie daran, dass durch das Speichern die Anwendung neu gestartet wird. Wenn sich nach dem Speichern herausstellt, dass nach kontinuierlichem Pingen Ihre Standortinstanzen fehlerhaft sind, können Sie zu Ihrer Speicherkontoressource wechseln und die Speicherabbilder anzeigen.

Überwachung

Nachdem Sie den Pfad der Integritätsüberprüfung der Anwendung angegeben haben, können Sie die Integrität Ihres Standorts mithilfe von Azure Monitor überwachen. Wählen Sie im Portal auf dem Blatt Integritätsprüfung auf der oberen Symbolleiste Metriken aus. Dadurch wird ein neues Blatt geöffnet, in dem Sie den Integritätsstatusverlauf der Website sehen und eine neue Warnungsregel erstellen können. Integritätsprüfungsmetriken aggregieren die erfolgreichen Pings und zeigen Fehler nur dann an, wenn die Instanz basierend auf der Konfiguration der Integritätsprüfung als fehlerhaft eingestuft wurde. Weitere Informationen zur Überwachung Ihrer Websites finden Sie unter Azure App Service-Kontingente und -Warnungen.

Begrenzungen

• Die Integritätsprüfung kann für Free und Shared App Service-Pläne aktiviert werden, sodass Sie Metriken zur Integrität der Website haben und Warnungen einrichten können. Da Free und Shared Websites jedoch nicht aufskaliert werden können, werden fehlerhafte Instanzen nicht ersetzt. Sie sollten auf den Basic-Tarif oder höher hochskalieren, damit Sie horizontal auf zwei oder mehr Instanzen skalieren und den vollen Vorteil der Integritätsprüfung nutzen können. Dies wird für Produktionsanwendungen empfohlen, da dies die Verfügbarkeit und Leistung Ihrer App erhöht.
• Ein App Service-Plan kann maximal eine fehlerhafte Instanz pro Stunde und höchstens drei Instanzen pro Tag ersetzt erhalten.
• Es gibt einen nicht konfigurierbaren Grenzwert für die Gesamtanzahl von Instanzen, die durch die Integritätsprüfung pro Skalierungseinheit ersetzt werden. Bei Erreichen dieses Grenzwerts werden keine fehlerhaften Instanzen mehr ersetzt. Dieser Wert wird alle 12 Stunden zurückgesetzt.

Häufig gestellte Fragen

Was geschieht, wenn meine App auf einer einzelnen Instanz ausgeführt wird?

Wenn Ihre App nur auf eine Instanz skaliert ist und fehlerhaft wird, wird sie nicht aus dem Lastenausgleich entfernt, da dadurch Ihre Anwendung vollständig ausfallen würde. Nach einer Stunde fortlaufender fehlerhafter Pings wird die Instanz jedoch ersetzt. Skalieren Sie auf zwei oder mehr Instanzen auf, um den Umleitungsvorteil der Integritätsprüfung zu erhalten. Wenn Ihre App auf einer einzelnen Instanz ausgeführt wird, können Sie weiterhin das Feature Überwachung der Integritätsprüfung verwenden, um die Integrität Ihrer Anwendung nachzuverfolgen.

Warum werden die Integritätsprüfungsanforderungen nicht in meinen Webserverprotokollen angezeigt?

Die Integritätsprüfungsanforderungen werden intern an Ihren Standort gesendet, sodass die Anforderung nicht in den Webserverprotokollen angezeigt wird. Sie können Ihrem Integritätsprüfungscode Protokollanweisungen hinzufügen, um Protokolle darüber zu führen, wenn ihr Integritätsprüfungspfad gepingt wird.

Werden Integritätsprüfungsanforderungen über HTTP oder HTTPS gesendet?

Bei App Service für Windows und Linux werden die Anforderungen der Integritätsprüfung über HTTPS gesendet, wenn auf der Website Nur HTTPS aktiviert ist. Andernfalls werden sie über HTTP gesendet.

Folgt die Integritätsprüfung den im Anwendungscode konfigurierten Weiterleitungen zwischen der Standarddomäne und der benutzerdefinierten Domäne?

Nein, das Feature „Integritätsprüfung“ pingt den Pfad der Standarddomäne der Webanwendung. Wenn es eine Umleitung von der Standarddomäne zu einer benutzerdefinierten Domäne gibt, ist der Statuscode, den die Integritätsprüfung zurückgibt, nicht 200. Es wird eine Umleitung (301) sein, was den Worker als fehlerhaft kennzeichnet.

Was geschieht, wenn ich mehrere Apps im selben App Service-Plan habe?

Fehlerhafte Instanzen werden immer aus der Lastenausgleichsrotation entfernt, unabhängig von anderen Apps im App Service-Plan (bis zu dem in WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT angegebenen Prozentsatz). Wenn eine App auf einer Instanz für mehr als eine Stunde fehlerhaft bleibt, wird die Instanz nur ersetzt, wenn alle anderen Apps, bei denen die Integritätsprüfung aktiviert ist, ebenfalls fehlerhaft sind. Apps, für die die Integritätsprüfung nicht aktiviert ist, werden nicht berücksichtigt.

Beispiel

Stellen Sie sich vor, Sie haben zwei Anwendungen (oder eine App mit einem Slot) mit aktivierter Integritätsprüfung. Sie werden App A und App B genannt. Sie befinden sich im gleichen App Service-Plan, und der Plan wird auf vier Instanzen skaliert. Wenn App A auf zwei Instanzen fehlerhaft wird, sendet der Lastenausgleich auf diesen beiden Instanzen keine Anforderungen an App A mehr. Anforderungen auf diesen Instanzen werden weiterhin an App B weitergeleitet, vorausgesetzt, App B ist fehlerfrei. Wenn App A auf diesen beiden Instanzen für mehr als eine Stunde fehlerhaft bleibt, werden diese Instanzen nur ersetzt, wenn App B auf diesen Instanzen ebenfalls fehlerhaft ist. Wenn App B fehlerfrei ist, werden die Instanzen nicht ersetzt.

Hinweis

Wenn ein anderer Standort oder Slot im Plan (App C) ohne aktivierte Integritätsprüfung vorhanden wäre, würde dieser beim Ersetzen von Instanzen nicht berücksichtigt.

Was ist, wenn alle meine Instanzen fehlerhaft sind?

Wenn alle Instanzen Ihrer Anwendung fehlerhaft sind, entfernt App Service keine Instanzen aus dem Lastenausgleich. In diesem Szenario würde das Entfernen aller fehlerhaften App-Instanzen aus der Lastenausgleichsrotation effektiv zu einem Ausfall Ihrer Anwendung führen. Die Instanz wird jedoch weiterhin ersetzt.

Funktioniert die Integritätsprüfung in App Service-Umgebungen?

Ja, die Integritätsprüfung ist für App Service-Umgebung v3 verfügbar, aber nicht für Versionen 1 oder 2. Wenn Sie die älteren Versionen von App Service-Umgebung verwenden, können Sie das Migrationsfeature verwenden, um Ihre App Service-Umgebung zu Version 3 zu migrieren.

Nächste Schritte

• Erstellen einer Aktivitätsprotokollwarnung, um alle Vorgänge der Engine für die automatische Skalierung für Ihr Abonnement zu überwachen
• Erstellen Sie eine Aktivitätsprotokollwarnung, um alle Autoskalierungs-Vorgänge zum horizontalen Herunterskalieren und horizontalen Hochskalieren in Ihrem Abonnement, bei denen Fehler aufgetreten sind, zu überwachen.
• Referenz zu Umgebungsvariablen und App-Einstellungen