Project Flash: Verwenden von Azure Resource Health zum Überwachen der Verfügbarkeit von Azure-VMs

Artikel
02/20/2024

Azure Resource Health ist eine Lösung, die von Flash angeboten wird. Flash ist der interne Name eines Projekts, das der Erstellung eines stabilen, zuverlässigen und schnellen Mechanismus dient, der Kunden das Überwachen der VM-Integrität ermöglicht.

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

Wählen Sie einen der folgenden Artikel aus, um zur Dokumentation zu gelangen, die spezifisch für die anderen von Flash angebotenen Lösungen ist:

Azure Resource Health

Das Feature bietet sofortige und benutzerfreundliche Integritätsprüfungen für einzelne Ressourcen über das Portal. Kunden können im Portal schnell auf das Blatt Ressourcenintegrität zugreifen und außerdem den Verlaufsdatensatz der Integritätsprüfungen der letzten 30 Tage überprüfen. Das zeichnet Azure Resource Health als hervorragendes Tool für eine schnelle und einfache Problembehandlung aus. Mit dem vorhandenen Azure Resource Health-Feature können Sie Dienstprobleme diagnostizieren, die sich auf Ihre Azure-Ressourcen auswirken, und Support für diese Probleme erhalten. Es meldet den aktuellen und früheren Status Ihrer Ressourcen und zeigt alle Zeitbereiche an, in denen Ihrer Ressourcen nicht verfügbar waren.

Dennoch ist uns bewusst, dass unsere Kunden und Partner an der Ursache zugrunde liegender technischer Probleme und daran interessiert sind, wie der Kommunikationskanal zu Problemen verbessert werden kann. Diese sollen in Überwachungsprozesse eingespeist werden, um anderen Beteiligten kleinere Probleme zu erläutern und letztendlich fundierte Geschäftsentscheidungen zu ermöglichen.

Grundursachen für VM-Probleme in Azure Resource Health

Kürzlich wurde eine Verbesserung des Resource Health-Features bereitgestellt, die die Informationen verbessert, die in Bezug auf VM-Fehler mit Kunden geteilt werden, und weiteren Kontext zu der Grundursache des Problems bereitstellt. Zusätzlich zum Erhalten schneller Benachrichtigungen bei der Beeinträchtigung der Verfügbarkeit einer VM können Kunden nun zu einem späteren Zeitpunkt erwarten, dass eine Grundursache hinzugefügt wird, sobald das automatisierte System zur Grundursachenanalyse (Root Cause Analysis, RCA) die Komponente der Azure-Plattform identifiziert, die zum VM-Fehler geführt hat. Im folgenden Beispiel wird veranschaulicht, wie dieser Prozess in der Praxis funktioniert:

Zum Zeitpunkt T1 geht ein Serverrack aufgrund eines Netzwerkproblems offline, was zu einem Konnektivitätsverlust der VMs im Rack führt. Aktuelle Verbesserungen der Zuverlässigkeit im Zusammenhang mit der Netzwerkarchitektur können Sie in einem künftigen Blogbeitrag zur Weiterentwicklung der Zuverlässigkeit finden.

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ährenddessen wird eine Anmerkung zur Ressourcenintegrität an Kunden gesendet, um diese darüber zu informieren, dass ihre VM momentan 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 ursprüngliche Funktionalität für Benachrichtigungen über Downtimes mehrere Jahre alt ist, stellt die Veröffentlichung eines Berichts zur Grundursache eine neue Ergänzung dar. Als Nächstes werden die Details zur Ermittlung dieser Grundursachen behandelt.

Engine für die Grundursachenanalyse

In diesem Abschnitt wird das vorherige Beispiel genauer betrachtet. Außerdem werden die Details zur Funktionsweise der RCA-Engine und die Technologie dahinter erläutert. Den Kern der RCA-Engine für VMs bildet Azure Data Explorer (ADX), ein Big-Data-Dienst, der für die Analyse von Protokolltelemetriedaten in großen Mengen optimiert ist. Azure Data Explorer ermöglicht es Ihnen, Terabytes an Protokolltelemetriedaten von Geräten und Diensten zu parsen, die die Azure-Plattform umfassen, diese miteinander zu verknüpfen und die korrelierten Informationsdatenströme zu interpretieren, um die Grundursache für verschiedene Fehlerszenarios zu ermitteln. Das ist ein mehrstufiger Prozess der Datentechnik:

Phase 1: Erkennen der Downtime

Die erste Phase der Ursachenanalyse besteht darin, den Trigger zu definieren, unter dem die Analyse ausgeführt wird. Bei VMs soll die Grundursache festgelegt werden, wenn eine VM unerwartet neu gestartet wird. Der Trigger ist folglich der Übergang einer VM vom Online- in den Offlinestatus. Die Identifizierung dieser Übergänge anhand der Plattformtelemetriedaten ist in den meisten Szenarios einfach. Bei bestimmten Arten von Infrastrukturfehlern ist sie jedoch komplizierter, wenn Plattformtelemetriedaten aufgrund eines Gerätefehlers oder Stromausfalls verloren gehen können. Um diese Fehlerklassen zu behandeln, sind andere Techniken wie das Nachverfolgen von Datenverlusten als möglicher Hinweis auf einen Übergang der VM-Verfügbarkeit erforderlich. Azure Data Explorer ist hervorragend für diese Time Series-Analyse geeignet. Eine nähere Betrachtung der Techniken dieses Prozesses finden Sie in der Microsoft Tech Community: Berechnen von Downtimes mithilfe von Fensterfunktionen und Time Series-Funktionen in Azure Data Explorer.

Phase 2: Korrelationsanalyse

Sobald ein Triggerereignis definiert ist (in diesem Fall der Übergang einer VM in einen fehlerhaften Zustand), stellt die Korrelationsanalyse die nächste Phase dar. Bei diesem Schritt wird das Vorhandensein des Triggerereignisses dazu verwendet, Telemetriedaten von Punkten wie den folgenden auf der Azure-Plattform zu korrelieren:

Azure-Host: das physische Blatt, das VMs hostet
TOR: der Top-of-Rack-Netzwerkswitch
Azure Storage: der Dienst, der virtuelle Datenträger für Azure-VMs hostet

Jedes dieser Systeme verfügt über eigene Telemetriefeeds, die geparst und mit dem Triggerereignis für die VM-Downtime korreliert werden müssen. Dieser Prozess erfolgt über das Verständnis des Abhängigkeitsdiagramms einer VM und der zugrunde liegenden Systeme, die zum Fehlschlagen einer VM führen können. Anschließend werden die Integritätstelemetriedaten aller abhängigen Systeme miteinander verknüpft und nach Ereignissen gefiltert, die zeitnah zum Übergang der VM aufgetreten sind. Die intuitive und leistungsstarke Abfragesprache von Azure Data Explorer hilft durch das Bereitstellen dokumentierter Muster wie der Zeitfensterverknüpfung beim Korrelieren zeitlicher Telemetriedatenströme. Das Ergebnis dieses Korrelationsprozesses ist ein Dataset, das die Übergänge von VM-Downtimes mit den korrelierten Plattformtelemetriedaten von allen abhängigen Systemen darstellt, die zu einem VM-Fehler geführt haben könnten oder die Informationen enthalten könnten, die für die Ermittlung der Fehlerursache hilfreich sind.

Phase 3: Zuordnung der Grundursache

Der nächste Schritt des Prozesses ist die Zuordnung. Nachdem nun alle relevanten Daten in einem einzigen Dataset erfasst wurden, werden Zuordnungsregeln angewendet, um die Informationen zu interpretieren und in einen kundenorientierten Bericht zur Grundursache zu übertragen. Wenn Sie zum ursprünglichen Beispiel des TOR-Fehlers zurückkehren, verfügen Sie nach der Korrelationsanalyse möglicherweise über viele interessante Informationen für die Auswertung. Beispielsweise können Systeme, die die Azure-Hosts überwachen, Protokolle enthalten, die angeben, dass sie während dieses Zeitraums die Konnektivität mit den Hosts verloren haben. Möglicherweise treten zudem Signale im Zusammenhang mit Konnektivitätsproblemen bei virtuellen Datenträgern sowie explizite Signale des TOR-Geräts über den Fehler auf. Alle diese Informationen werden nun überprüft, und das explizite TOR-Fehlersignal wird über den anderen Signalen als Grundursache priorisiert. Dieser Priorisierungsprozess und die zugrunde liegenden Regeln werden mit Domänenexperten erstellt und im Entwicklungsverlauf der Azure-Plattform geändert. Maschinelles Lernen und der Mechanismus für die Anomalieerkennung bauen auf diesen zugeordneten Grundursachen auf, um Möglichkeiten zur Verbesserung dieser Klassifizierungsregeln zu identifizieren und Musteränderungen in der Fehlerrate zu erkennen, damit diese wiederum in sichere Bereitstellungspipelines einfließen können.

Phase 4: RCA-Veröffentlichung

Der letzte Schritt ist die Veröffentlichung der Grundursache in Azure Resource Health, wo sie für Kunden sichtbar werden. Die Veröffentlichung erfolgt durch eine einfache Azure Functions-Anwendung, die die verarbeiteten Grundursachedaten in Azure Data Explorer regelmäßig abfragt und die Ergebnisse an das Back-End für die Ressourcenintegrität ausgibt. Da Informationsdatenströme mit verschiedenen Datenverzögerungen auftreten können, können RCAs in diesem Prozess gelegentlich aktualisiert werden, um bessere Informationsquellen zu berücksichtigen, die im Vergleich zur ursprünglichen Veröffentlichung zu einer spezifischeren Grundursache führen.

Weitere Schritte

Die Identifizierung der Grundursache von Problemen sowie ihre Kommunikation an Kunden und Partner ist lediglich der Anfang. Kunden müssen diese RCAs möglicherweise mit ihren Kunden und Kollegen teilen. Um Ressourcen-RCAs leichter zu identifizieren und nachzuverfolgen und diese einfach zu teilen, möchten wir auf dieser Arbeit aufbauen. Dazu arbeiten wir an Änderungen am Back-End, um eindeutige Nachverfolgungs-IDs für einzelne Ressourcen und Downtimes zu generieren, die wir Ihnen zur Verfügung stellen können, wodurch Sie Downtimes problemlos mit den RCAs abgleichen können. Außerdem arbeiten wir an neuen Features, mit denen Sie RCAs einfacher per E-Mail senden und diese schließlich für Ihre VMs abonnieren können. Dieses Feature ermöglicht es Ihnen, sich nach einem Nichtverfügbarkeitsereignis ohne weitere erforderliche Aktion direkt in Ihrem Posteingang für RCAs zu registrieren.

Nächste Schritte

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

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

Freigeben über