Project Flash – Verwenden von Azure Resource Health zum Überwachen der Verfügbarkeit virtueller Azure-Computer

2025-05-09

Azure Resource Health ist eine Lösung, die von Flash angeboten wird. Flash ist der interne Name für ein Projekt, das für die Erstellung eines robusten, zuverlässigen und schnellen Mechanismus für Kunden zur Überwachung der VM-Integrität dient.

In diesem Artikel wird die Verwendung von Azure Resource Health behandelt, um die Verfügbarkeit des virtuellen Azure-Computers zu überwachen. Eine allgemeine Übersicht über Flash-Lösungen finden Sie in der Übersicht über Flash.

Für Dokumentation spezifisch für die anderen Lösungen von Flash, wählen Sie aus den folgenden Artikeln aus:

Azure-Ressourcengesundheit

Es bietet sofortige und benutzerfreundliche Gesundheitschecks für einzelne Ressourcen über das Portal. Kunden können schnell auf den Bereich "Ressourcengesundheit" im Portal zugreifen und auch ein 30-tägiges Protokoll der Gesundheitsprüfungen einsehen, was es zu einem hervorragenden Tool für schnelle und einfache Problemlösungen macht. Mit der vorhandenen Azure Resource Health-Funktion können Sie Dienstprobleme diagnostizieren und Unterstützung erhalten, die sich auf Ihre Azure-Ressourcen auswirken. Sie meldet den aktuellen und früheren Status Ihrer Ressourcen und zeigt alle Zeitbereiche an, die für jede Ihrer Ressourcen nicht verfügbar sind.

Aber wir wissen, dass unsere Kunden und Partner daran interessiert sind, zu verstehen, was zugrunde liegende technische Probleme verursacht, und wie sie die Kommunikation über etwaige Probleme verbessern können – um in Überwachungsprozesse einzuspeisen, Probleme anderen Stakeholdern zu erklären und letztendlich Geschäftsentscheidungen zu informieren.

Ursachen für VM-Probleme in Azure Resource Health

Wir haben kürzlich eine Verbesserung der Ressourcengesundheitserfahrung eingeführt, die die Informationen verbessert, die wir mit Kunden über Fehler bei virtuellen Maschinen teilen, und zusätzlichen Kontext zur Ursache des Problems bietet. Zusätzlich zum Abrufen einer schnellen Benachrichtigung, wenn die Verfügbarkeit eines virtuellen Computers beeinträchtigt wird, können Kunden zu einem späteren Zeitpunkt erwarten, dass eine Grundursache hinzugefügt wird, sobald unser automatisiertes System zur Ursachenanalyse (Root Cause Analysis, RCA) die fehlerhafte Azure-Plattformkomponente identifiziert, die zum VM-Fehler geführt hat. Sehen wir uns ein Beispiel an, um zu sehen, wie dieser Prozess in der Praxis funktioniert:

Zum Zeitpunkt von T1 geht ein Servergestell aufgrund eines Netzwerkproblems offline, was dazu führt, dass VMs auf dem Rack die Konnektivität verlieren. Aktuelle Zuverlässigkeitsverbesserungen im Zusammenhang mit der Netzwerkarchitektur werden in einem zukünftigen Blogbeitrag von Advancing Reliability geteilt – bleiben Sie dran!

Zum Zeitpunkt T2 erkennt die interne Überwachung von Azure, dass sie keine VMs im Rack erreichen kann. Daraufhin initiiert sie eine Risikominderung, bei der die betroffenen VMs in einem neuen Rack erneut bereitgestellt werden. Während dieser Zeit wird eine Anmerkung an den Ressourcenstatus gesendet, um Kunden darüber zu informieren, dass ihre VM aktuell betroffen und nicht verfügbar ist.

Zum Zeitpunkt T3 korrelieren die Plattformtelemetriedaten im Top-of-Rack-Switch, die Hostcomputer und die internen Überwachungssysteme in der RCA-Engine miteinander, um die Grundursache des Fehlers zu ermitteln. Nach der Berechnung wird die RCA anschließend wieder in der Ressourcenintegrität zusammen mit relevanten Empfehlungen zur Architekturresilienz veröffentlicht, die Kunden implementieren können, um die Wahrscheinlichkeit von Auswirkungen künftig zu minimieren.

Während die anfängliche Benachrichtigung über Ausfallzeiten mehrere Jahre alt ist, ist die Veröffentlichung einer Ursachenanalyse eine neue Funktion. Nun wollen wir uns mit den Details befassen, wie wir diese Ursachen ableiten.

Analyse-Engine für Hauptursachen

Sehen wir uns das vorherige Beispiel genauer an und gehen wir durch die Details der Funktionsweise des RCA-Engines und der dahinter stehenden Technologie. Kern unseres RCA-Moduls für VMs ist Azure Data Explorer (ADX), ein Big Data-Dienst, der für die Telemetrieanalyse mit hohem Volumen optimiert ist. Azure Data Explorer ermöglicht die einfache Analyse von Terabytes der Protokolltelemetrie von Geräten und Diensten, die die Azure-Plattform umfassen, sie miteinander verbinden und die korrelierten Informationsströme interpretieren, um eine Grundursache für verschiedene Fehlerszenarien abzuleiten. Dies ist ein mehrstufiger Data Engineering-Prozess:

Phase 1: Erkennen von Ausfallzeiten

Die erste Phase der Ursachenanalyse besteht darin, den Trigger zu definieren, unter dem die Analyse ausgeführt wird. Bei virtuellen Computern möchten wir die Ursachen ermitteln, wenn ein virtueller Computer unerwartet neu gestartet wird, sodass der Auslöser ein virtueller Computer ist, der von einem Aufwärtszustand zu einem Abwärtszustand wechselt. Die Identifizierung dieser Übergänge von der Plattformtelemetrie ist in den meisten Szenarien einfach, aber komplizierter bei bestimmten Arten von Infrastrukturfehlern, bei denen die Plattform-Telemetrie aufgrund eines Geräteausfalls oder Stromausfalls verloren gehen kann. Um diese Klassen von Fehlern zu behandeln, sind andere Techniken erforderlich , z. B. das Nachverfolgen von Datenverlust als mögliche Hinweise auf einen Vm-Verfügbarkeitsübergang. Azure Data Explorer ist besonders gut geeignet für die Analyse von Zeitreihen und eine detailliertere Betrachtung der Techniken in diesem Prozess finden Sie in der Microsoft Tech Community: Berechnen von Ausfallzeiten mithilfe von Fensterfunktionen und Zeitreihenfunktionen im Azure Data Explorer.

Phase 2: Korrelationsanalyse

Sobald ein Triggerereignis definiert ist (in diesem Fall wechselt ein virtueller Computer in einen fehlerhaften Zustand), ist die nächste Phase die Korrelationsanalyse. In diesem Schritt verwenden wir das Vorhandensein des Triggerereignisses, um Telemetrie von Punkten auf der Azure-Plattform zu korrelieren, z. B.:

Azure-Host: der physische Blade-Server, der VMs hostet.
TOR: der Top-of-Rack-Netzwerkswitch.
Azure Storage: Der Dienst, der virtuelle Datenträger für virtuelle Azure-Computer hostet.

Jedes dieser Systeme verfügt über eigene Telemetriefeeds, die analysiert und mit dem Ereignis zum Auslösen von VM-Ausfallzeiten korreliert werden müssen. Dieser Vorgang erfolgt durch das Verständnis des Abhängigkeitsdiagramms einer VM und der zugrunde liegenden Systeme, die dazu führen können, dass eine VM fehlschlägt. Anschließend wird die Integritäts-Telemetrie aller abhängigen Systeme zusammengeführt, wobei diese anhand von Ereignissen gefiltert wird, die in zeitlicher Nähe zum Übergang der VM aufgetreten sind. Die intuitive und leistungsstarke Abfragesprache von Azure Data Explorer hilft ihnen, dokumentierte Muster wie Zeitfenster-Verknüpfungen zum Korrelieren zeitlicher Telemetriedatenströme anzubieten. Am Ende dieses Korrelationsprozesses verfügen wir über ein Dataset, das die Übergänge von VM-Ausfallzeiten mit korrelierter Plattform-Telemetrie von allen abhängigen Systemen darstellt, die entweder zu einem solchen Ausfall führen könnten oder Informationen enthalten könnten, die nützlich sind, um zu bestimmen, was zum VM-Ausfall geführt hat.

Phase 3: Zuordnung von Ursachenursachen

Der nächste Schritt im Prozess ist die Zuordnung. Nachdem wir nun alle relevanten Daten in einem einzigen Datensatz gesammelt haben, werden Zuordnungsregeln angewendet, um die Informationen zu interpretieren und in eine kundenorientierte Ursachenerklärung zu übersetzen. Wenn Sie zu unserem ursprünglichen Beispiel für einen TOR-Fehler zurückkehren, haben wir nach unserer Korrelationsanalyse möglicherweise viele interessante Informationen zu interpretieren. Beispielsweise können Systeme, die die Azure-Hosts überwachen, Protokolle enthalten, die angeben, dass sie während dieser Zeit die Verbindung mit den Hosts verloren haben. Möglicherweise haben wir auch Signale im Zusammenhang mit Problemen mit der Konnektivität virtueller Datenträger sowie explizite Signale vom TOR-Gerät über den Fehler. Alle diese Informationen werden nun überprüft, und das explizite TOR-Fehlersignal wird über die anderen Signale als Ursache priorisiert. Dieser Priorisierungsprozess und die dahinter gehenden Regeln werden mit Domänenexperten erstellt und geändert, während sich die Azure-Plattform weiterentwickelt. Maschinelles Lernen und Anomalieerkennungsmechanismen bauen auf diesen zugeordneten Ursachen auf, um Gelegenheiten zur Verbesserung dieser Klassifizierungsregeln zu identifizieren und Musteränderungen in der Häufigkeit dieser Fehler zu erkennen, damit sie wieder in sichere Bereitstellungspipelines einfließen können.

Phase 4: RCA-Veröffentlichung

Der letzte Schritt ist die Veröffentlichung der Stammursachen für Azure Resource Health, wo sie für Kunden sichtbar werden. Die Veröffentlichung erfolgt durch eine einfache Azure Functions-Anwendung , die regelmäßig die verarbeiteten Ursachendaten im Azure-Daten-Explorer abfragt und die Ergebnisse an das Ressourcenintegritäts-Back-End sendet. Da Informationsströme mit verschiedenen Datenverzögerungen auftreten können, können RCAs gelegentlich in diesem Prozess aktualisiert werden, um bessere Informationsquellen widerzuspiegeln, die eingetroffen sind und zu einer genaueren Ursache führen, als das, was ursprünglich veröffentlicht wurde.

Von jetzt an

Die Identifizierung und Kommunikation der Ursache von Problemen für unsere Kunden und Partner ist nur der Anfang. Kundinnen und Kunden müssen diese RCAs möglicherweise mit ihren Kunden und Kollegen teilen. Wir wollen hier auf die Arbeit aufbauen, um ressourcen-RCAs leichter zu identifizieren und nachzuverfolgen und einfach zu teilen. Dazu arbeiten wir an Back-End-Änderungen, um eindeutige Ressourcen- und Ausfallzeit-Tracking-IDs zu generieren, die wir Ihnen zur Verfügung stellen können, sodass Sie Ausfallzeiten problemlos mit ihren RCAs abgleichen können. Außerdem arbeiten wir an neuen Funktionen, um RCAs einfacher per E-Mail zu versenden und schließlich RCAs für Ihre virtuellen Computer zu abonnieren. Diese Funktion ermöglicht es Ihnen, sich direkt in Ihrem Posteingang für RCAs anzumelden, nachdem ein Ereignis der Nichtverfügbarkeit aufgetreten ist, ohne dass Ihrerseits weitere Maßnahmen erforderlich sind.

Nächste Schritte

Um mehr über die angebotenen Lösungen zu erfahren, fahren Sie mit dem entsprechenden Lösungsartikel fort:

Eine allgemeine Übersicht über das Überwachen von Azure-VMs finden Sie unter Überwachen von Azure-VMs und Überwachen von Azure VM-Referenzen.