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

In diesem Artikel wird die Integritätsprüfung im Azure-Portal verwendet, um App Service-Instanzen zu überwachen. Die Integritätsprüfung erhöht die Verfügbarkeit Ihrer Anwendung, indem Anforderungen von fehlerhaften Instanzen weg umgeleitet und Instanzen ersetzt werden, wenn sie fehlerhaft bleiben. 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. Auch wenn der Pfad innerhalb von 1 Minute keine Antwort zurückgibt, wird die Integritätsprüfung als fehlerhaft betrachtet.

Verwendung von Integritätsprüfungen durch App Service

• Wenn Sie einen Pfad Ihrer App an die Integritätsprüfung übergeben, pingt diese den Pfad bei allen Instanzen Ihrer App Service-App in Intervallen von 1 Minute.
• Wenn eine Instanz nach zehn Anforderungen nicht mit einem Statuscode zwischen 200 und 299 (einschließlich) antwortet, stellt App Service fest, dass sie fehlerhaft ist, und entfernt sie. (Die erforderliche Anzahl fehlerhafter Anforderungen, damit eine Instanz als fehlerhaft eingestuft wird, kann auf ein Minimum von zwei Anforderungen konfiguriert werden.)
• Nach der Entfernung wird die fehlerhafte Instanz von der Integritätsprüfung weiterhin gepingt. Wenn die Instanz mit einem gesunden Statuscode (200-299) zu antworten beginnt, wird die Instanz an den Load Balancer zurückgegeben.
• Wenn eine Instanz für eine Stunde fehlerhaft bleibt, wird sie durch eine neue Instanz 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 ausgibt, liegt dabei wahrscheinlich ein Fehler aufgrund eines HTTP-Statuscodes 307 vor. Dies kann passieren, wenn Sie die HTTPS-Umleitung aktiviert, aber HTTPS Only deaktiviert haben.

Aktivieren der Integritätsprüfung

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

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 die Einstellung beispielsweise auf 2 festgelegt wird, werden Ihre Instanzen nach 2 fehlgeschlagenen Pings entfernt. (Standardwert: 10)
WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT	1–100	Standardmäßig wird nicht mehr als die Hälfte der Instanzen gleichzeitig aus dem Lastenausgleich ausgeschlossen, um zu vermeiden, dass die verbleibenden fehlerfreien Instanzen überlastet werden. 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. Im ungünstigsten Fall, in dem alle Instanzen fehlerhaft sind, wird keine ausgeschlossen. Um dieses Verhalten außer Kraft zu setzen, legen Sie die App-Einstellung auf einen Wert zwischen 1 und 100 fest. Ein höherer Wert führt dazu, dass mehr fehlerhafte Instanzen entfernt werden (Standardwert: 50).

Authentifizierung und Sicherheit

Die Integritätsprüfung integriert sich in die Authentifizierungs- und Autorisierungsfunktionen von App Service. Es sind keine zusätzlichen 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 den Endpunkt der Integritätsprüfung zu sichern, 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 die Kopfzeile x-ms-auth-internal-token überprüfen und validieren, ob sie 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.

.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.io.Console;
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 == 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

Die Kopfzeile x-ms-auth-internal-token ist nur in Windows App Service 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. Die Registerkarte „Instanzen“ zeigt den Namen Ihrer Instanz und den Status dieser Instanz an und gibt Ihnen die Option, die Anwendungsinstanz manuell neu zu starten.

Wenn der Status Ihrer Instanz fehlerhaft ist, können Sie die Instanz manuell über die Schaltfläche „Neustart“ in der Tabelle 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 dieselbe App Service-Plan wie die -Instanz verwenden, werden diese auf dem sich öffnenden Blatt der Schaltfläche „Neustart“ aufgeführt.

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

Windows-Anwendungen haben auch die Möglichkeit, Prozesse über den Prozess-Explorer anzuzeigen. Dadurch erhalten Sie weitere Erkenntnisse in die Prozesse der Instanz, einschließlich Threadanzahl, privatem Arbeitsspeicher und gesamter CPU-Zeit.

Sammlung von Diagnoseinformationen

Bei Windows-Anwendungen haben Sie die Möglichkeit, auf der Registerkarte „Integritätsprüfung“ Diagnoseinformationen zu sammeln. Wenn Sie die Diagnosesammlung aktivieren, wird eine Regel zur automatischen Reparatur hinzugefügt, die Speicherabbilder für fehlerhafte Instanzen erstellt und in einem bestimmten 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 für Ihre Dateien erstellen oder ein vorhandenes Konto auswählen. Sie können nur Speicherkonten auswählen, die sich in derselben Region wie Ihre Anwendung befinden. Beachten Sie, 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. Klicken Sie im Portal auf dem Blatt Integrität überprüfen auf der oberen Symbolleiste auf Metriken. Daraufhin wird ein neues Blatt geöffnet, auf dem Sie den Verlauf des Integritätsstatus der Site und eine Option zum Erstellen einer neuen Warnungsregel sehen. Integritätsprüfungsmetriken aggregieren die erfolgreichen Pings & Anzeigefehler nur dann, wenn die Instanz basierend auf der Konfiguration der Integritätsprüfung als fehlerhaft eingestuft wurde. Weitere Informationen zum Überwachen Ihrer Standorte finden Sie im Handbuch zu Azure Monitor.

Einschränkungen

• Die Integritätsprüfung kann für Free (kostenlos) und Shared (freigegeben) App Service-Pläne aktiviert werden, sodass Sie über Metriken zur Integrität des Standorts verfügen und Warnungen einrichten können. Da Free und Shared Standorte aber nicht aufskaliert werden können, werden keine fehlerhaften Instanzen ersetzt. Sie sollten auf den Basic-Tarif oder höher hochskalieren, damit Sie auf zwei oder mehr Instanzen aufskalieren 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.

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 Überwachungsfeature 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. Dies bedeutet außerdem, dass die Anforderung den Ursprung 127.0.0.1 hat, da sie intern gesendet 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 die Integritätsprüfungsanforderungen über HTTP oder HTTPS gesendet?

Bei Windows App Service werden die Health Check-Anfragen über HTTPS gesendet, wenn Nur HTTPS auf der Site aktiviert ist. Andernfalls werden sie über HTTP gesendet. Unter Linux App Service werden die Health Check-Anfragen nur über HTTP gesendet und können derzeit nicht über HTTPS gesendet werden.

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 eine Weiterleitung von der Standarddomäne zu einer benutzerdefinierten Domäne vorhanden ist, wird von der Integritätsprüfung kein 200-Statuscode zurückgegeben, sondern eine Umleitung (301), die den Worker als fehlerhaft markiert.

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 länger als eine Stunde fehlerhaft bleibt, wird die Instanz nur ersetzt, wenn alle anderen Apps mit aktivierter Integritätsprüfung ebenfalls fehlerhaft sind. Apps, für die die Integritätsprüfung nicht aktiviert ist, werden nicht berücksichtigt.

Beispiel

Angenommen, Sie verfügen über zwei Anwendungen (oder eine App mit einem Slot) mit aktivierter Integritätsprüfung namens „App A“ und „App B“. Sie befinden sich im selben App Service-Plan, und der Plan ist auf vier Instanzen aufskaliert. Wenn App A auf zwei Instanzen fehlerhaft wird, hört der Lastenausgleich auf diesen beiden Instanzen auf, Anforderungen an App A zu senden. Anforderungen werden weiterhin an App B auf diesen Instanzen weitergeleitet, vorausgesetzt, App B ist fehlerfrei. Wenn App A auf diesen beiden Instanzen länger als eine Stunde fehlerhaft bleibt, werden diese Instanzen nur ersetzt, wenn App B auf diesen Instanzen ebenfalls fehlerhaft ist. Wenn App B fehlerfrei ist, wird die Instanz nicht ersetzt.

Hinweis

Wenn ein anderer Standort oder Slot im Plan (Standort 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?

In dem Szenario, in dem alle Instanzen Ihrer Anwendung fehlerhaft sind, entfernt App Service Instanzen aus dem Lastenausgleich bis zu dem in WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT angegebenen Prozentsatz. In diesem Szenario würde das Entfernen aller fehlerhaften App-Instanzen aus der Lastenausgleichsrotation effektiv zu einem Ausfall Ihrer Anwendung führen.

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

Ja, die Integritätsprüfung ist für die App Service-Umgebung v3 verfügbar, aber nicht für Versionen 1 oder 2. Wenn Sie die älteren Versionen der 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