Freigeben über

Verwenden der Application Health-Erweiterung mit Virtual Machine Scale Sets

  • Artikel

Überwachung der Integrität Ihrer Anwendung ist ein wichtiges Signal für das Verwalten und Aktualisieren Ihrer Bereitstellung. Azure-VM-Skalierungsgruppen bieten Unterstützung für Parallele Upgrades einschließlich Automatischen Betriebssystemimage-Upgrades und Automatischen VM-Gastpatches, die von der Überwachung der Integrität der einzelnen Instanzen beim Upgrade Ihrer Bereitstellung abhängig sind. Sie können die Anwendungsintegritätserweiterung auch verwenden, um die Anwendungsintegrität jeder Instanz in Ihrer Skalierungsgruppe zu überwachen und Instanzreparaturen mit Automatischen Instanzreparaturen durchzuführen.

In diesem Artikel erfahren Sie, wie Sie mit den beiden Typen Binary Health States oder Rich Health States der Application Health-Erweiterung die Integrität Ihrer Anwendungen überwachen, die in VM-Skalierungsgruppen bereitgestellt werden.

Voraussetzungen

In diesem Artikel wird davon ausgegangen, dass Sie mit Folgendem vertraut sind:

Achtung

Die Application Health-Erweiterung erwartet, eine konsistente Testantwort am konfigurierten Port tcp oder Anforderungspfad http/https zu empfangen, um einen virtuellen Computer als Fehlerfrei zu bezeichnen. Wenn auf der VM keine Anwendung ausgeführt wird oder Sie keine Testantwort konfigurieren können, wird Ihre VM als Fehlerhaft (Binary Health States) oder Unbekannt (Rich Health States). angezeigt. Beispiele für das Ausgeben von Integritätstestantworten an einen lokalen Endpunkt finden Sie unter Beispiele für Anwendungsintegrität.

Hinweis

Für eine VM-Skalierungsgruppe kann nur eine Quelle der Integritätsüberwachung verwendet werden, entweder eine Anwendungsintegritätserweiterung oder ein Integritätstest. Wenn Sie beide Optionen aktiviert haben, müssen Sie eine entfernen, bevor Sie Orchestrierungsdienste wie Instanzreparaturen oder automatische Betriebssystemupgrades verwenden.

Anwendungsbereich der Application Health-Erweiterung

Die Application Health-Erweiterung wird in einer VM-Skalierungsgruppeninstanz bereitgestellt und berichtet aus der Skalierungsgruppeninstanz heraus über die Anwendungsintegrität. Die Erweiterung testet auf einem lokalen Anwendungsendpunkt und aktualisiert den Integritätsstatus basierend auf TCP/HTTP(S)-Antworten, die von der Anwendung empfangen wurden. Dieser Integritätsstatus wird von Azure verwendet, um Reparaturen fehlerhafter Instanzen zu initiieren und zu bestimmen, ob eine Instanz zu Upgradevorgängen berechtigt ist.

Die Erweiterung meldet die Integrität aus einer VM heraus und kann in Situationen verwendet werden, in denen ein externer Test wie die Azure Load Balancer-Integritätstests nicht verwendet werden kann.

Binary Health States und Rich Health States im Vergleich

Für Anwendungsintegritätserweiterungen stehen zwei Optionen zur Verfügung: Binary Health States und Rich Health States. In der folgenden Tabelle werden einige wichtige Unterschiede zwischen den beiden Optionen hervorgehoben. Allgemeine Empfehlungen finden Sie am Ende dieses Abschnitts.

Features Binary Health States Rich Health States
Verfügbare Integritätsstatus Zwei verfügbare Status: Fehlerfrei, Fehlerhaft Vier verfügbare Zustände: Fehlerfrei, Fehlerhaft, Initialisierung, Unbekannt1
Senden von Integritätssignalen Integritätssignale werden über HTTP/HTTPS-Antwortcodes oder TCP-Verbindungen gesendet. Integritätssignale werden im HTTP/HTTPS-Protokoll über den Testantwortcode und den Antworttext gesendet. Integritätssignale über das TCP-Protokoll werden von Binary Health States nicht verändert.
Identifizieren von Fehlerhaft-Instanzen Instanzen werden automatisch in den Zustand Fehlerhaft versetzt, wenn von der Anwendung kein Fehlerfrei-Signal empfangen wird. Eine Fehlerhaft-Instanz kann auf ein Problem mit der Erweiterungskonfiguration (z. B. einen nicht erreichbaren Endpunkt) oder ein Problem mit der Anwendung (z. B. Nicht-200-Statuscode) hinweisen. Instanzen werden nur dann in den Zustand Fehlerhaft versetzt, wenn die Anwendung eine Fehlerhaft-Testantwort ausgibt. Benutzer sind für die Implementierung benutzerdefinierter Logik verantwortlich, um Instanzen mit Fehlerhaft-Anwendungen zu identifizieren und zu kennzeichnen2. Instanzen mit falschen Erweiterungseinstellungen (z. B. nicht erreichbarer Endpunkt) oder ungültigen Integritätstestantworten fallen unter den Status Unbekannt2.
Zustand Initialisierung für neu erstellte Instanzen Der Zustand Initialisierung ist nicht verfügbar. Es kann einige Zeit dauern, bevor neu erstellte Instanzen einen stabilen Zustand erreichen. Der Zustand Initialisierung ermöglicht, neu erstellte Instanzen in einen stabilen Integritätszustand zu versetzen, bevor die Instanz für parallele Upgrades oder Instanzreparaturen infrage kommt.
HTTP/HTTPS-Protokoll Unterstützt Unterstützt
TCP-Protokoll Unterstützt Eingeschränkte Unterstützung: Der Zustand Unbekannt ist im TCP-Protokoll nicht verfügbar. Informationen zum Integritätszustandsverhalten in TCP finden Sie in der Protokolltabelle zu Rich Health States.

1 Der Zustand Unbekannt ist im TCP-Protokoll nicht verfügbar. 2 Nur anwendbar für das HTTP/HTTPS-Protokoll. Das TCP-Protokoll führt dasselbe Verfahren zur Identifizierung von Fehlerhaft-Instanzen durch wie bei Binary Health States.

Im Allgemeinen sollten Sie Binary Health States verwenden, wenn:

  • Sie möchten keine benutzerdefinierte Logik konfigurieren, um eine fehlerhafte Instanz zu identifizieren und zu kennzeichnen.
  • Sie benötigen keine Initialisierung-Toleranzperiode für neu erstellte Instanzen.

In folgenden Fällen sollten Sie Rich Health States verwenden:

  • Sie senden Integritätssignale über das HTTP/HTTPS-Protokoll und können Integritätsinformationen über den Testantworttext übermitteln.
  • Sie möchten benutzerdefinierte Logik verwenden, um fehlerhafte Instanzen zu identifizieren und zu markieren.
  • Sie möchten eine Initialisierung-Toleranzperiode für neu erstellte Instanzen festlegen, damit sie in einen stabilen Integritätszustand versetzt werden, bevor die Instanz für parallele Upgrades oder Instanzreparaturen infrage kommt.

Binary Health States

Binary Health States-Berichte enthalten zwei Integritätszustände: Fehlerfrei und Fehlerhaft. Die folgenden Tabellen enthalten eine kurze Beschreibung der Konfiguration der Integritätszustände.

HTTP/HTTPS-Protokoll

Protocol Integritätsstatus BESCHREIBUNG
http/https Healthy Um ein Fehlerfrei-Signal zu senden, muss die Anwendung einen 200-Antwortcode zurückgeben.
http/https Fehlerhaft Die Instanz wird als Fehlerhaft markiert, wenn kein 200-Antwortcode von der Anwendung empfangen wird.

TCP-Protokoll

Protocol Integritätsstatus BESCHREIBUNG
TCP Healthy Um ein Fehlerfrei-Signal zu senden, muss ein erfolgreicher Handshake mit dem bereitgestellten Anwendungsendpunkt durchgeführt werden.
TCP Fehlerhaft Die Instanz wird als Fehlerhaft markiert, wenn ein fehlerhafter oder unvollständiger Handshake mit dem angegebenen Anwendungsendpunkt aufgetreten ist.

Unter anderem können folgende Szenarien zu einem Fehlerhaft-Zustand führen:

  • Der Anwendungsendpunkt gibt einen Nicht-200-Statuscode zurück
  • Wenn kein Anwendungsendpunkt innerhalb der VM-Instanzen konfiguriert ist, um den Integritätsstatus der Anwendung bereitzustellen
  • Wenn der Anwendungsendpunkt nicht ordnungsgemäß konfiguriert ist.
  • Wenn der Anwendungsendpunkt nicht erreichbar ist

Rich Health States

Rich Health States-Berichte enthalten vier Integritätszustände: Initialisierung, Fehlerfrei, Fehlerhaft und Unbekannt. Die folgenden Tabellen enthalten eine kurze Beschreibung der Konfiguration des jeweiligen Integritätszustands.

HTTP/HTTPS-Protokoll

Protocol Integritätsstatus BESCHREIBUNG
http/https Healthy Um das Signal Fehlerfrei zu senden, wird von der Anwendung eine Testantwort erwartet, die Folgendes enthält: Testantwortcode: Status 2xx, Testantworttext: {"ApplicationHealthState": "Healthy"}
http/https Fehlerhaft Um das Signal Fehlerhaft zu senden, wird von der Anwendung eine Testantwort erwartet, die Folgendes enthält: Testantwortcode: Status 2xx, Testantworttext: {"ApplicationHealthState": "Unhealthy"}
http/https Wird initialisiert... Die Instanz wechselt zur Startzeit der Erweiterung automatisch in den Zustand Initialisierung. Weitere Informationen finden Sie unter Zustand „Initialisierung“.
http/https Unbekannt Ein Zustand Unbekannt kann in den folgenden Szenarien auftreten: ein Nicht-2xx-Statuscode wird von der Anwendung zurückgegeben, bei der Testanforderung tritt ein Timeout auf, der Anwendungsendpunkt ist nicht erreichbar oder falsch konfiguriert, ein fehlender oder ungültiger Wert wird im Antworttext für ApplicationHealthState angegeben, oder die Toleranzperiode läuft ab. Weitere Informationen finden Sie unter Zustand „Unbekannt“.

TCP-Protokoll

Protocol Integritätsstatus BESCHREIBUNG
TCP Healthy Um ein Fehlerfrei-Signal zu senden, muss ein erfolgreicher Handshake mit dem bereitgestellten Anwendungsendpunkt durchgeführt werden.
TCP Fehlerhaft Die Instanz wird als Fehlerhaft markiert, wenn ein fehlerhafter oder unvollständiger Handshake mit dem angegebenen Anwendungsendpunkt aufgetreten ist.
TCP Wird initialisiert... Die Instanz wechselt zur Startzeit der Erweiterung automatisch in den Zustand Initialisierung. Weitere Informationen finden Sie unter Zustand „Initialisierung“.

Zustand „Initialisierung“

Dieser Zustand gilt nur für Rich Health States. Der Zustand Initialisierung tritt nur einmal zur Startzeit der Erweiterung auf und kann durch die Erweiterungseinstellungen gracePeriod und numberOfProbes konfiguriert werden.

Beim Start der Erweiterung verbleibt die Anwendungsintegrität im Zustand Initialisierung, bis eines von zwei Szenarien auftritt:

  • Derselbe Integritätsstatus (Fehlerfrei oder Fehlerhaft) wird mehrmals gemeldet, wie über numberOfProbes konfiguriert.
  • Die gracePeriod läuft ab

Wenn derselbe Integritätsstatus (Fehlerfrei oder Fehlerhaft) in Folge gemeldet wird, wechselt die Anwendungsintegrität aus dem Zustand Initialisierung in den gemeldeten Integritätszustand (Fehlerfrei oder Fehlerhaft).

Beispiel

Wenn numberOfProbes = 3, bedeutet dies:

  • Um vom Zustand Initialisierung zum Zustand Fehlerfrei zu wechseln: Die Anwendungsintegritätserweiterung muss drei aufeinanderfolgende Fehlerfrei-Signale über HTTP/HTTPS oder das TCP-Protokoll empfangen.
  • Um vom Zustand Initialisierung zum Zustand Fehlerhaft zu wechseln: Die Anwendungsintegritätserweiterung muss drei aufeinanderfolgende Fehlerhaft-Signale über HTTP/HTTPS oder das TCP-Protokoll empfangen.

Wenn die gracePeriod abläuft, bevor die Anwendung einen aufeinanderfolgenden Integritätsstatus meldet, wird die Instanzintegrität wie folgt bestimmt:

  • HTTP/HTTPS-Protokoll: Die Anwendungsintegrität wechselt von Initialisierung zu Unbekannt.
  • TCP-Protokoll: Die Anwendungsintegrität wechselt von Initialisierung zu Fehlerhaft.

Unbekannter Status

Dieser Zustand gilt nur für Rich Health States. Der Zustand Unbekannt wird nur für „http“- oder „https“-Tests gemeldet und tritt in den folgenden Szenarien auf:

  • Ein Nicht-2xx-Statuscode wird von der Anwendung zurückgegeben.
  • Für die Testanforderung tritt ein Timeout ein.
  • Der Anwendungsendpunkt ist nicht erreichbar oder falsch konfiguriert.
  • Im Antworttext fehlt ein Wert für ApplicationHealthState, oder er wird falsch angegeben.
  • Die Toleranzperiode läuft ab.

Eine Instanz im Zustand Unbekannt wird ähnlich wie eine Fehlerhaft-Instanz behandelt. Wenn diese Option aktiviert ist, werden Instanzreparaturen für eine Unbekannt-Instanz ausgeführt, während parallele Upgrades angehalten werden, bis die Instanz wieder in den Fehlerfrei-Zustand zurückfällt.

Die folgende Tabelle zeigt die Integritätsstatusinterpretation für Parallele Upgrades und Instanzreparaturen:

Integritätsstatus Interpretation für paralleles Upgrade Auslöser für Instanzreparaturen
Wird initialisiert... Warten Sie, bis der Zustand Fehlerfrei, Fehlerhaft oder Unbekannt eintritt. Nein
Healthy Healthy Nein
Fehlerhaft Fehlerhaft Ja
Unbekannt Fehlerhaft Ja

Erweiterungsschema für Binary Health States

Der folgende JSON-Code zeigt das Schema für die Application Health-Erweiterung. Die Erweiterung erfordert mindestens eine „Tcp“-, „http“- oder „https“-Anforderung mit einem zugeordneten Port bzw. Anforderungspfad.

{
  "extensionProfile" : {
     "extensions" : [
      {
        "name": "HealthExtension",
        "properties": {
          "publisher": "Microsoft.ManagedServices",
          "type": "<ApplicationHealthLinux or ApplicationHealthWindows>",
          "autoUpgradeMinorVersion": true,
          "typeHandlerVersion": "1.0",
          "settings": {
            "protocol": "<protocol>",
            "port": <port>,
            "requestPath": "</requestPath>",
            "intervalInSeconds": 5,
            "numberOfProbes": 1
          }
        }
      }
    ]
  }
}

Eigenschaftswerte

Name Wert/Beispiel Datentyp
apiVersion 2018-10-01 date
publisher Microsoft.ManagedServices Zeichenfolge
type ApplicationHealthLinux (Linux), ApplicationHealthWindows (Windows) Zeichenfolge
typeHandlerVersion 1.0 Zeichenfolge

Einstellungen

Name Wert/Beispiel Datentyp
Protokoll http oder https oder tcp Zeichenfolge
port Optional, wenn das Protokoll http oder https ist, obligatorisch, wenn das Protokoll tcp ist. INT
requestPath Obligatorisch, wenn das Protokoll http oder https ist, nicht zulässig, wenn das Protokoll tcp ist. Zeichenfolge
intervalInSeconds Optional, der Standardwert ist 5 Sekunden. Dies ist das Intervall zwischen den einzelnen Integritätstests. Wenn beispielsweise intervalInSeconds == 5 ist, wird ein Test einmal alle 5 Sekunden an den lokalen Anwendungsendpunkt gesendet. INT
numberOfProbes Optional, der Standardwert ist 1. Dies ist die Anzahl der aufeinanderfolgenden Tests, die für die Änderung des Integritätsstatus erforderlich sind. Wenn beispielsweise numberOfProbles == 3 ist, benötigen Sie 3 aufeinander folgende „Fehlerfrei“-Signale, um den Integritätsstatus von „Fehlerhaft“ in den Zustand „Fehlerfrei“ zu ändern. Die gleiche Anforderung gilt für die Änderung des Integritätsstatus in den Zustand „Fehlerhaft“. INT

Erweiterungsschema für Rich Health States

Der folgende JSON-Code zeigt das Schema für die Rich Health States-Erweiterung. Die Erweiterung erfordert mindestens eine „http“- oder „https“-Anforderung mit einem zugeordneten Port bzw. Anforderungspfad. TCP-Tests werden ebenfalls unterstützt, können aber nicht den ApplicationHealthState über den Testantworttext festlegen und haben keinen Zugriff auf den Zustand Unbekannt.

{
  "extensionProfile" : {
     "extensions" : [
      {
        "name": "HealthExtension",
        "properties": {
          "publisher": "Microsoft.ManagedServices",
          "type": "<ApplicationHealthLinux or ApplicationHealthWindows>",
          "autoUpgradeMinorVersion": true,
          "typeHandlerVersion": "2.0",
          "settings": {
            "protocol": "<protocol>",
            "port": <port>,
            "requestPath": "</requestPath>",
            "intervalInSeconds": 5,
            "numberOfProbes": 1,
            "gracePeriod": 600
          }
        }
      }
    ]
  }
}

Eigenschaftswerte

Name Wert/Beispiel Datentyp
apiVersion 2018-10-01 date
publisher Microsoft.ManagedServices Zeichenfolge
type ApplicationHealthLinux (Linux), ApplicationHealthWindows (Windows) Zeichenfolge
typeHandlerVersion 2.0 Zeichenfolge

Einstellungen

Name Wert/Beispiel Datentyp
Protokoll http oder https oder tcp Zeichenfolge
port Optional, wenn das Protokoll http oder https ist, obligatorisch, wenn das Protokoll tcp ist. INT
requestPath Obligatorisch, wenn das Protokoll http oder https ist, nicht zulässig, wenn das Protokoll tcp ist. Zeichenfolge
intervalInSeconds Optional, der Standardwert ist 5 Sekunden. Dies ist das Intervall zwischen den einzelnen Integritätstests. Wenn beispielsweise intervalInSeconds == 5 ist, wird ein Test einmal alle 5 Sekunden an den lokalen Anwendungsendpunkt gesendet. INT
numberOfProbes Optional, der Standardwert ist 1. Dies ist die Anzahl der aufeinanderfolgenden Tests, die für die Änderung des Integritätsstatus erforderlich sind. Wenn beispielsweise numberOfProbles == 3 ist, benötigen Sie 3 aufeinander folgende „Fehlerfrei“-Signale, um den Integritätsstatus von „Fehlerhaft“/„Unbekannt“ in den Zustand „Fehlerfrei“ zu ändern. Die gleiche Anforderung gilt für die Änderung des Integritätsstatus in den Zustand „Fehlerhaft“ oder „Unbekannt“. INT
gracePeriod Optional, Standard = intervalInSeconds * numberOfProbes; die maximale Toleranzperiode beträgt 7.200 Sekunden INT

Bereitstellen der Application Health-Erweiterung

Es gibt mehrere Möglichkeiten, die Application Health-Erweiterung für Ihre Skalierungsgruppen bereitzustellen, wie in den folgenden Beispielen beschrieben.

Binary Health States

Im folgenden Beispiel wird die Application Health-Erweiterung (mit dem Namen „myHealthExtension“) dem „extensionProfile“ im Skalierungsgruppenmodell einer Windows-basierten Skalierungsgruppe hinzugefügt.

Sie können dieses Beispiel auch verwenden, um eine vorhandene Erweiterung von Rich Health State in Binary Health zu ändern, indem Sie anstelle eines PUT einen PATCH-Aufruf ausführen.

PUT on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet/extensions/myHealthExtension?api-version=2018-10-01`

{
  "name": "myHealthExtension",
  "location": "<location>", 
  "properties": {
    "publisher": "Microsoft.ManagedServices",
    "type": "ApplicationHealthWindows",
    "autoUpgradeMinorVersion": true,
    "typeHandlerVersion": "1.0",
    "settings": {
      "protocol": "<protocol>",
      "port": <port>,
      "requestPath": "</requestPath>"
    }
  }
}

Verwenden Sie PATCH, um eine bereits bereitgestellte Erweiterung zu bearbeiten.

Führen Sie ein Upgrade für die VMs durch, um die Erweiterung zu installieren.

POST on `/subscriptions/<subscriptionId>/resourceGroups/<myResourceGroup>/providers/Microsoft.Compute/virtualMachineScaleSets/< myScaleSet >/manualupgrade?api-version=2022-08-01`

{
  "instanceIds": ["*"]
}

Rich Health States

Im folgenden Beispiel wird die Application Health – Rich States-Erweiterung (mit Namen myHealthExtension) in dem Skalierungsgruppenmodell einer Windows-basierten Skalierungsgruppe dem extensionProfile hinzugefügt.

Sie können dieses Beispiel auch verwenden, um eine vorhandene Erweiterung von Binary in Rich Health State zu ändern, indem Sie anstelle eines PUT einen PATCH-Aufruf ausführen.

PUT on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet/extensions/myHealthExtension?api-version=2018-10-01`

{
  "name": "myHealthExtension",
  "location": "<location>",
  "properties": {
    "publisher": "Microsoft.ManagedServices",
    "type": "ApplicationHealthWindows",
    "autoUpgradeMinorVersion": true,
    "typeHandlerVersion": "2.0",
    "settings": {
      "protocol": "<protocol>",
      "port": <port>,
      "requestPath": "</requestPath>",
      "intervalInSeconds": <intervalInSeconds>,
      "numberOfProbes": <numberOfProbes>,
      "gracePeriod": <gracePeriod>
    }
  }
}

Verwenden Sie PATCH, um eine bereits bereitgestellte Erweiterung zu bearbeiten.

Führen Sie ein Upgrade für die VMs durch, um die Erweiterung zu installieren.

POST on `/subscriptions/<subscriptionId>/resourceGroups/<myResourceGroup>/providers/Microsoft.Compute/virtualMachineScaleSets/< myScaleSet >/manualupgrade?api-version=2022-08-01`

{
  "instanceIds": ["*"]
}

Problembehandlung

Benötigen Sie Hilfe beim Konfigurieren einer Testantwort?

Beispiele für das Ausgeben von Integritätstestantworten an einen lokalen Endpunkt finden Sie unter Beispiele für Anwendungsintegrität.

Anzeigen von VMHealth – einzelne Instanz

Get-AzVmssVM 
  -InstanceView `
  -ResourceGroupName <rgName> `
  -VMScaleSetName <vmssName> `
  -InstanceId <instanceId>

Anzeigen von VMHealth – Batchaufruf

Dies ist nur für VM-Skalierungsgruppen mit einheitlicher Orchestrierung verfügbar.

GET on `/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.Compute/virtualMachineScaleSets/<vmssName>/virtualMachines/?api-version=2022-03-01&$expand=instanceview`

Integritätsstatus wird nicht angezeigt

Wenn der Integritätsstatus nicht im Azure-Portal oder per GET-Aufruf angezeigt wird, überprüfen Sie, ob die VM auf das neueste Modell aktualisiert wurde. Wenn die VM nicht dem neuesten Modell entspricht, aktualisieren Sie den virtuellen Computer, und der Integritätsstatus wird angezeigt.

Ausgabeprotokoll für die Erweiterungsausführung

Die Ausgabe der Erweiterungsausführung wird in Dateien in folgenden Verzeichnissen protokolliert:

C:\WindowsAzure\Logs\Plugins\Microsoft.ManagedServices.ApplicationHealthWindows\<version>\

/var/lib/waagent/Microsoft.ManagedServices.ApplicationHealthLinux-<extension_version>/status
/var/log/azure/applicationhealth-extension

Die Protokolle erfassen auch in regelmäßigen Abständen den Integritätsstatus der Anwendung.

Nächste Schritte

Informieren Sie sich über das Bereitstellen Ihrer Anwendung in Virtual Machine Scale Sets.