Freigeben über

Fehlermodusanalyse für Azure-Anwendungen

  • Artikel

Die Fehlermodusanalyse (Failure Mode Analysis, FMA) ist ein Prozess zum Erzielen von Resilienz in einem System durch das Identifizieren möglicher Schwachstellen im System. Die Fehlermodusanalyse sollte in die Planungs- und Designphasen eingebunden werden, damit Sie die Wiederherstellung nach einem Fehler von Anfang an in das System integrieren können.

Hier folgt der allgemeine Prozess zum Durchführen einer Fehlermodusanalyse:

  1. Identifizieren Sie alle Komponenten im System. Beziehen Sie externe Abhängigkeiten ein, z.B. Identitätsanbieter, Drittanbieterdienste usw.

  2. Identifizieren Sie für jede Komponente potenzielle Fehler, die auftreten können. Eine einzelne Komponente kann mehrere Fehlermodi aufweisen. Beispielsweise sollten Sie Lese- und Schreibfehler getrennt betrachten, da deren Auswirkungen und die möglichen Schritte zur Entschärfung unterschiedlich ausfallen werden.

  3. Bewerten Sie die einzelnen Fehlermodi nach ihrem Gesamtrisiko. Beachten Sie folgende Faktoren:

    • Wie hoch ist die Fehlerwahrscheinlichkeit? Tritt der Fehler relativ häufig auf? Äußerst selten? Sie brauchen keine exakten Zahlen. Der Zweck besteht darin, der Priorität einen Rang zuzuweisen.
    • Welche Auswirkungen hat dies auf die Anwendung in Bezug auf Verfügbarkeit, Datenverlust, Kosten und Geschäftsunterbrechung?

  4. Legen Sie für jeden Fehlermodus fest, wie die Anwendung reagieren und wiederhergestellt werden soll. Berücksichtigen Sie Kompromisse in Bezug auf Kosten und Anwendungskomplexität.

Dieser Artikel enthält als Ausgangspunkt für den FMA-Prozess einen Katalog mit möglichen Fehlerzuständen und den entsprechenden Schritten zur Entschärfung. Der Katalog ist nach Technologie oder Azure-Dienst sowie einer zusätzlichen allgemeinen Kategorie für das Design auf Anwendungsebene gegliedert. Der Katalog ist nicht komplett, deckt aber viele der wichtigsten Azure-Dienste ab.

Hinweis

Störungen sollten von Fehlern unterschieden werden. Eine Störung ist ein unerwartetes Ereignis innerhalb eines Systems, das verhindert, dass es normal funktioniert. Eine Hardwarefehler, der eine Netzwerkpartition verursacht, ist z. B. eine Störung. In der Regel erfordern Störungen Interventionen oder ein spezifisches Design für diese Störungsklasse. Im Gegensatz dazu sind Fehler ein erwarteter Teil des normalen Betriebs, werden sofort behoben und das System arbeitet nach einem Fehler mit derselben Kapazität weiter. Beispielsweise können Fehler, die während der Eingabeüberprüfung erkannt werden, über Geschäftslogik behandelt werden.

App Service

Die App Service-App wird heruntergefahren.

Erkennung: Mögliche Ursachen:

  • Erwartetes Herunterfahren

    • Ein Operator fährt die Anwendung herunter, z. B. über das Azure-Portal.
    • Die App wurde aufgrund von Inaktivität entladen. (Nur, wenn die Einstellung Always On deaktiviert ist.)

  • Unerwartetes Herunterfahren

    • Die App stürzt ab.
    • Eine App Service-VM-Instanz steht nicht mehr zur Verfügung.

Die „Application_End“-Protokollierung fängt das Herunterfahren der Anwendungsdomäne ab (sanfter Prozessabsturz). Dies ist die einzige Möglichkeit, das Herunterfahren der Anwendungsdomäne abzufangen.

Wiederherstellung:

  • Wenn das Herunterfahren erwartet wurde, verwenden Sie das Herunterfahrereignis der Anwendung, um das Programm ordnungsgemäß herunterzufahren. Verwenden Sie z. B. in ASP.NET die Methode Application_End.
  • Wenn die Anwendung bei Inaktivität entladen wurde, wird sie bei der nächsten Anforderung automatisch neu gestartet. Allerdings fallen für Sie die Kosten für den „Kaltstart“ an.
  • Um zu verhindern, dass die Anwendung bei Inaktivität entladen wird, aktivieren Sie die Einstellung Always On in der Web-App. Weitere Informationen finden Sie unter Konfigurieren von Web-Apps in Azure App Service.
  • Um zu verhindern, dass ein Operator die Anwendung herunterfährt, legen Sie eine Ressourcensperre mit ReadOnly-Ebene fest. Weitere Informationen finden Sie unter Sperren von Ressourcen mit Azure Resource Manager.
  • Wenn die App abstürzt oder eine App Service-VM ist nicht mehr verfügbar ist, startet App Service die App automatisch neu.

Diagnose: Anwendungs- und Webserverprotokolle. Weitere Informationen finden Sie unter Aktivieren der Diagnoseprotokollierung für Web-Apps in Azure App Service.

Ein bestimmter Benutzer stellt wiederholt unzulässige Anforderungen oder überlastet das System.

Erkennung: Authentifizieren Sie Benutzer, und beziehen Sie die Benutzer-ID in die Anwendungsprotokolle ein.

Wiederherstellung:

Diagnose: Protokollieren Sie alle Authentifizierungsanforderungen.

Es wurde eine unzulässige Aktualisierung bereitgestellt.

Erkennung: Überwachen Sie die Anwendungsintegrität über das Azure-Portal (weitere Informationen finden Sie unter Überwachen der Azure Web App-Leistung), oder implementieren Sie das Überwachungsmuster für den Integritätsendpunkt.

Wiederherstellung: Verwenden Sie mehrere Bereitstellungsslots, und führen Sie ein Rollback auf die letzte bekannte geeignete Bereitstellung aus. Weitere Informationen finden Sie unter Einfache Webanwendung.

Microsoft Entra ID

Fehler bei der OpenID Connect-Authentifizierung.

Erkennung: Mögliche Fehlermodi:

  1. Microsoft Entra ID ist nicht verfügbar oder kann aufgrund eines Netzwerkproblems nicht erreicht werden. Bei der Umleitung zum Authentifizierungsendpunkt ist ein Fehler aufgetreten, und die OpenID Connect-Middleware löst eine Ausnahme aus.
  2. Der Microsoft Entra-Mandant ist nicht vorhanden. Bei der Umleitung zum Authentifizierungsendpunkt wird ein HTTP-Fehlercode zurückgegeben, und die OpenID Connect-Middleware löst eine Ausnahme aus.
  3. Der Benutzer kann nicht authentifiziert werden. Es ist keine Erkennungsstrategie erforderlich. Microsoft Entra ID behandelt Anmeldefehler.

Wiederherstellung:

  1. Fangen Sie nicht behandelte Ausnahmen von der Middleware ab.
  2. Behandeln Sie AuthenticationFailed-Ereignisse.
  3. Leiten Sie den Benutzer zu einer Fehlerseite um.
  4. Der Benutzer versucht den Vorgang erneut.

Beim Schreiben von Daten in Azure Search tritt ein Fehler auf.

Erkennung: Fangen Sie Microsoft.Rest.Azure.CloudException-Fehler ab.

Wiederherstellung:

Das Search .NET SDK versucht nach vorübergehenden Fehlern automatisch, den Vorgang erneut durchzuführen. Alle Ausnahmen, die vom Client-SDK ausgelöst werden, sollten als nicht vorübergehende Fehler behandelt werden.

Die standardmäßige Wiederholungsrichtlinie verwendet einen exponentiellen Backoff. Rufen Sie SetRetryPolicy für die Klasse SearchIndexClient oder SearchServiceClient auf, um eine andere Wiederholungsrichtlinie zu verwenden. Weitere Informationen finden Sie unter Automatische Wiederholungsversuche.

Diagnose: Verwenden Sie Datenverkehrsanalyse durchsuchen.

Beim Lesen von Daten aus Azure Search tritt ein Fehler auf.

Erkennung: Fangen Sie Microsoft.Rest.Azure.CloudException-Fehler ab.

Wiederherstellung:

Das Search .NET SDK versucht nach vorübergehenden Fehlern automatisch, den Vorgang erneut durchzuführen. Alle Ausnahmen, die vom Client-SDK ausgelöst werden, sollten als nicht vorübergehende Fehler behandelt werden.

Die standardmäßige Wiederholungsrichtlinie verwendet einen exponentiellen Backoff. Rufen Sie SetRetryPolicy für die Klasse SearchIndexClient oder SearchServiceClient auf, um eine andere Wiederholungsrichtlinie zu verwenden. Weitere Informationen finden Sie unter Automatische Wiederholungsversuche.

Diagnose: Verwenden Sie Datenverkehrsanalyse durchsuchen.

Cassandra

Beim Lesen aus einem Knoten oder beim Schreiben in einen Knoten ist ein Fehler aufgetreten.

Erkennung: Fangen Sie die Ausnahme ab. Für .NET-Clients ist dies normalerweise System.Web.HttpException. Andere Clients weisen möglicherweise andere Ausnahmetypen auf. Weitere Informationen finden Sie unter Cassandra error handling done right (Richtige Cassandra-Fehlerbehandlung).

Wiederherstellung:

  • Jeder Cassandra-Client verfügt über eigene Wiederholungsrichtlinien und -funktionen. Weitere Informationen finden Sie unter Cassandra error handling done right (Richtige Cassandra-Fehlerbehandlung).
  • Verwenden Sie eine rackfähige Bereitstellung mit Datenknoten, die über die Fehlerdomänen verteilt sind.
  • Nehmen Sie die Bereitstellung in mehreren Regionen mit lokaler Quorumkonsistenz vor. Wenn ein nicht vorübergehender Fehler auftritt, führen Sie einen Failover in eine andere Region aus.

Diagnose: Anwendungsprotokolle

Clouddienst

Web- oder Workerrollen werden unerwartet heruntergefahren.

Erkennung: Das Ereignis RoleEnvironment.Stopping wird ausgelöst.

Wiederherstellen. Setzen Sie die Methode RoleEntryPoint.OnStop für eine ordnungsgemäße Bereinigung außer Kraft. Weitere Informationen finden Sie im Blogbeitrag The Right Way to Handle Azure OnStop Events (Der richtige Weg zum Behandeln von Azure OnStop-Ereignissen).

Azure Cosmos DB

Beim Lesen von Daten tritt ein Fehler auf.

Erkennung: Fangen Sie System.Net.Http.HttpRequestException oder Microsoft.Azure.Documents.DocumentClientException ab.

Wiederherstellung:

  • Das SDK führt bei Fehlversuchen automatisch Wiederholungsversuche durch. Konfigurieren Sie zum Festlegen der Anzahl von Wiederholungsversuchen und der maximalen Wartezeit ConnectionPolicy.RetryOptions. Ausnahmen, die vom Client ausgelöst werden, unterliegen entweder nicht der Wiederholungsrichtlinie oder sind keine vorübergehenden Fehler.
  • Wenn Azure Cosmos DB den Client drosselt, wird der HTTP-Fehler 429 zurückgegeben. Überprüfen Sie den Statuscode unter DocumentClientException. Wenn Sie ständig den Fehler 429 erhalten, sollten Sie in Erwägung ziehen, den Durchsatzwert der Sammlung zu erhöhen.
    • Wenn Sie die MongoDB-API verwenden, gibt der Dienst bei der Einschränkung den Fehlercode 16500 zurück.
  • Aktivieren Sie die Zonenredundanz, wenn Sie mit einer Region arbeiten, die Verfügbarkeitszonen unterstützt. Wenn Sie Zonenredundanz nutzen, führt Azure Cosmos DB bei einem Zonenausfall automatisch ein Failover durch. Weitere Informationen finden Sie unter Erzielen von Hochverfügbarkeit mit Azure Cosmos DB.
  • Wenn Sie eine Lösung mit mehreren Regionen entwerfen, replizieren Sie die Azure Cosmos DB-Datenbank in zwei oder mehr Regionen. Alle Replikate können gelesen werden. Geben Sie den Parameter PreferredLocations mithilfe des Client-SDKs an. Dies ist eine sortierte Liste von Azure-Regionen. Alle Lesevorgänge werden an die erste verfügbare Region in der Liste gesendet. Wenn bei der Anforderung ein Fehler auftritt, versucht der Client die anderen Regionen in der Liste in der entsprechenden Reihenfolge. Weitere Informationen finden Sie unter Einrichten der globalen Verteilung in Azure Cosmos DB for NoSQL.

Diagnose: Protokollieren Sie alle Fehler auf der Clientseite.

Beim Schreiben von Daten tritt ein Fehler auf.

Erkennung: Fangen Sie System.Net.Http.HttpRequestException oder Microsoft.Azure.Documents.DocumentClientException ab.

Wiederherstellung:

  • Das SDK führt bei Fehlversuchen automatisch Wiederholungsversuche durch. Konfigurieren Sie zum Festlegen der Anzahl von Wiederholungsversuchen und der maximalen Wartezeit ConnectionPolicy.RetryOptions. Ausnahmen, die vom Client ausgelöst werden, unterliegen entweder nicht der Wiederholungsrichtlinie oder sind keine vorübergehenden Fehler.
  • Wenn Azure Cosmos DB den Client drosselt, wird der HTTP-Fehler 429 zurückgegeben. Überprüfen Sie den Statuscode unter DocumentClientException. Wenn Sie ständig den Fehler 429 erhalten, sollten Sie in Erwägung ziehen, den Durchsatzwert der Sammlung zu erhöhen.
  • Aktivieren Sie die Zonenredundanz, wenn Sie mit einer Region arbeiten, die Verfügbarkeitszonen unterstützt. Wenn Sie Zonenredundanz nutzen, repliziert Azure Cosmos DB alle Schreibvorgänge synchron über Verfügbarkeitszonen hinweg. Weitere Informationen finden Sie unter Erzielen von Hochverfügbarkeit mit Azure Cosmos DB.
  • Wenn Sie eine Lösung mit mehreren Regionen entwerfen, replizieren Sie die Azure Cosmos DB-Datenbank in zwei oder mehr Regionen. Tritt bei der primären Region ein Fehler auf, wird eine andere Region für den Schreibvorgang höher gestuft. Sie können einen Failover auch manuell auslösen. Das SDK führt die automatische Erkennung und das automatische Routing durch, sodass der Anwendungscode auch nach einem Failover weiterhin funktioniert. Während der Failoverperiode (normalerweise Minuten) weisen Schreibvorgänge eine höhere Wartezeit auf, da das SDK die neue Schreibregion sucht. Weitere Informationen finden Sie unter Einrichten der globalen Verteilung in Azure Cosmos DB for NoSQL.
  • Als Fallback wird das Dokument in eine Sicherungswarteschlange gestellt und die Warteschlange später verarbeitet.

Diagnose: Protokollieren Sie alle Fehler auf der Clientseite.

Queue Storage

Beim Schreiben einer Nachricht in Azure Queue Storage tritt fortlaufend ein Fehler auf.

Erkennung: Nach N Wiederholungsversuchen tritt weiterhin ein Fehler beim Schreibvorgang auf.

Wiederherstellung:

  • Speichern Sie die Daten in einem lokalen Cache, und leiten Sie die Schreibvorgänge zu einem späteren Zeitpunkt, wenn der Dienst verfügbar ist, an den Speicher weiter.
  • Erstellen Sie eine sekundäre Warteschlange, und schreiben Sie in diese Warteschlange, wenn die primäre Warteschlange nicht verfügbar ist.

Diagnose: Verwenden Sie die Speichermetriken.

Die Anwendung kann eine bestimmte Nachricht aus der Warteschlange nicht verarbeiten.

Erkennung: Dies ist anwendungsspezifisch. Die Nachricht enthält z. B. ungültige Daten oder bei der Geschäftslogik ist ein Fehler aufgetreten.

Wiederherstellung:

Verschieben Sie die Nachricht in eine separate Warteschlange. Führen Sie einen separaten Prozess aus, um die Nachrichten in der Warteschlange zu untersuchen.

Erwägen Sie die Verwendung von Azure Service Bus Messaging-Warteschlangen, die zu diesem Zweck über eine Warteschlange für unzustellbare Nachrichten verfügen.

Hinweis

Wenn Sie Storage-Warteschlangen mit WebJobs verwenden, stellt das WebJobs SDK eine integrierte Behandlung von nicht verarbeiteten Nachrichten bereit. Weitere Informationen finden Sie unter Verwenden von Azure Queue Storage mit dem Webaufträge-SDK.

Diagnose: Verwenden Sie die Anwendungsprotokollierung.

Azure Cache for Redis

Beim Lesen aus dem Cache tritt ein Fehler aus.

Erkennung: Fangen Sie StackExchange.Redis.RedisConnectionException ab.

Wiederherstellung:

  1. Wiederholen Sie den Vorgang bei vorübergehenden Fehlern. Azure Cache for Redis unterstützt integrierte Wiederholungsfunktionen. Weitere Informationen finden Sie unter Azure Cache for Redis – Wiederholungsrichtlinien.
  2. Behandeln Sie nicht vorübergehende Fehler als Cachefehler, und führen Sie einen Fallback auf die ursprüngliche Datenquelle aus.

Diagnose: Verwenden Sie die Azure Cache for Redis-Diagnose.

Beim Schreiben in den Cache tritt ein Fehler auf.

Erkennung: Fangen Sie StackExchange.Redis.RedisConnectionException ab.

Wiederherstellung:

  1. Wiederholen Sie den Vorgang bei vorübergehenden Fehlern. Azure Cache for Redis unterstützt integrierte Wiederholungsfunktionen. Weitere Informationen finden Sie unter Azure Cache for Redis – Wiederholungsrichtlinien.
  2. Wenn der Fehler nicht vorübergehend ist, ignorieren Sie ihn und lassen andere Transaktionen später in den Cache schreiben.

Diagnose: Verwenden Sie die Azure Cache for Redis-Diagnose.

SQL-Datenbank

Es kann keine Verbindung zur Datenbank in der primären Region hergestellt werden.

Erkennung: Beim Herstellen der Verbindung ist ein Fehler aufgetreten.

Wiederherstellung:

  • Aktivieren Sie Zonenredundanz. Durch die Aktivierung von Zonenredundanz repliziert Azure SQL-Datenbank Ihre Schreibvorgänge automatisch in mehrere Azure-Verfügbarkeitszonen innerhalb der unterstützten Regionen. Weitere Informationen finden Sie unter Zonenredundante Verfügbarkeit.

  • Aktivieren Sie die Georeplikation. Wenn Sie eine Lösung mit mehreren Regionen entwerfen, ziehen Sie eine Aktivierung der aktiven Georeplikation für die SQL-Datenbank in Betracht.

    Voraussetzung: Die Datenbank muss für die aktive Georeplikation konfiguriert sein. Weitere Informationen finden Sie unter Aktive Georeplikation in Azure SQL-Datenbank.

    Das Replikat verwendet eine andere Verbindungszeichenfolge, sodass Sie die Verbindungszeichenfolge in Ihrer Anwendung aktualisieren müssen.

Die Verbindungen im Verbindungspool gehen für den Client zur Neige.

Erkennung: Fangen Sie System.InvalidOperationException-Fehler ab.

Wiederherstellung:

  • Wiederholen Sie den Vorgang.
  • Isolieren Sie als vorbeugende Maßnahme die Verbindungspools für jeden Anwendungsfall, sodass ein Anwendungsfall nicht alle Verbindungen kontrollieren kann.
  • Erhöhen Sie die maximale Anzahl von Verbindungspools.

Diagnose: Anwendungsprotokolle.

Der Grenzwert für Datenbankverbindungen wurde erreicht.

Erkennung: Azure SQL-Datenbank begrenzt die Anzahl der gleichzeitigen Worker, Anmeldungen und Sitzungen. Die Grenzwerte hängen von der Dienstebene ab. Weitere Informationen finden Sie unter Ressourceneinschränkungen für Azure SQL-Datenbank.

Um diese Fehler zu erkennen, fangen Sie System.Data.SqlClient.SqlException ab, und überprüfen Sie den Wert von SqlException.Number für den SQL-Fehlercode. Eine Liste mit relevanten Fehlercodes finden Sie unter SQL-Fehlercodes für SQL-Datenbank-Clientanwendungen: Datenbankverbindungsfehler und andere Probleme.

Wiederherstellen. Diese Fehler werden als vorübergehend betrachtet, sodass ein erneuter Versuch das Problem beheben kann. Wenn Sie diese Fehler immer wieder feststellen, sollten Sie eine Skalierung der Datenbank in Betracht ziehen.

Diagnose: Die sys.event_log-Abfrage gibt erfolgreiche Datenbankverbindungen, Verbindungsfehler und Deadlocks zurück.

Service Bus Messaging

Beim Lesen einer Nachricht aus einer Service Bus-Warteschlange ist ein Fehler aufgetreten.

Erkennung: Fangen Sie vom Client-SDK stammende Ausnahmen ab. Die Basisklasse für Service Bus-Ausnahmen ist MessagingException. Wenn es sich um einen vorübergehenden Fehler handelt, ist die IsTransient-Eigenschaft „true“.

Weitere Informationen finden Sie unter Service Bus-Messagingausnahmen.

Wiederherstellung:

  1. Wiederholen Sie den Vorgang bei vorübergehenden Fehlern. Weitere Informationen finden Sie unter Service Bus-Wiederholungsrichtlinien.
  2. Nachrichten, die keinem Empfänger übermittelt werden können, befinden sich in einer Warteschlange für unzustellbare Nachrichten. Verwenden Sie diese Warteschlange, um zu prüfen, welche Nachrichten nicht empfangen werden konnten. Es erfolgt keine automatische Bereinigung der Warteschlange für unzustellbare Nachrichten. Nachrichten verbleiben dort, bis Sie sie explizit abrufen. Weitere Informationen finden Sie unter Übersicht über Service Bus-Warteschlangen für unzustellbare Nachrichten.

Beim Schreiben einer Nachricht in eine Service Bus-Warteschlange ist ein Fehler aufgetreten.

Erkennung: Fangen Sie vom Client-SDK stammende Ausnahmen ab. Die Basisklasse für Service Bus-Ausnahmen ist MessagingException. Wenn es sich um einen vorübergehenden Fehler handelt, ist die IsTransient-Eigenschaft „true“.

Weitere Informationen finden Sie unter Service Bus-Messagingausnahmen.

Wiederherstellung:

  • Der Service Bus-Client wiederholt den Versuch nach einem vorübergehenden Fehler automatisch. Standardmäßig wird ein exponentieller Backoff verwendet. Nach der maximalen Anzahl der Wiederholungsversuche oder der maximalen Timeoutperiode löst der Client eine Ausnahme aus. Weitere Informationen finden Sie unter Service Bus-Wiederholungsrichtlinien.

  • Wenn das Warteschlangenkontingent überschritten wird, löst der Client QuotaExceededException aus. Weitere Details finden Sie in der Ausnahmemeldung. Entfernen Sie einige Nachrichten aus der Warteschlange, bevor Sie den Versuch wiederholen, und ziehen Sie in Betracht, das Trennschalter-Muster zu verwenden, um weitere Wiederholungsversuche zu vermeiden, während das Kontingent überschritten wurde. Stellen Sie darüber hinaus sicher, dass für die BrokeredMessage.TimeToLive-Eigenschaft kein zu hoher Wert festgelegt ist.

  • Innerhalb einer Region kann die Resilienz mithilfe von partitionierten Warteschlangen oder Themen verbessert werden. Eine nicht partitionierte Warteschlange bzw. ein Thema ist einem Nachrichtenspeicher zugewiesen. Wenn dieser Nachrichtenspeicher nicht verfügbar ist, treten für alle Vorgänge der Warteschlange oder des Themas Fehler auf. Eine partitionierte Warteschlange bzw. ein Thema ist über mehrere Nachrichtenspeicher hinweg partitioniert.

  • Verwenden Sie Zonenredundanz, um Änderungen automatisch zwischen mehreren Verfügbarkeitszonen zu replizieren. Wenn eine Verfügbarkeitszone ausfällt, wird automatisch ein Failover durchgeführt. Weitere Informationen finden Sie unter Best Practices zum Schützen von Anwendungen vor Service Bus-Ausfällen und Notfällen.

  • Wenn Sie eine Lösung mit mehreren Regionen entwerfen, erstellen Sie zwei Service Bus-Namespaces in verschiedenen Regionen, und replizieren Sie die Nachrichten. Sie können entweder die aktive oder die passive Replikation verwenden.

    • Aktive Replikation: Der Client sendet alle Nachrichten an beide Warteschlangen. Der Empfänger lauscht an beiden Warteschlangen. Kennzeichnen Sie Nachrichten mit einem eindeutigen Bezeichner, damit der Client doppelte Nachrichten verwerfen kann.
    • Passive Replikation: Der Client sendet die Nachricht an eine Warteschlange. Wenn ein Fehler aufgetreten ist, führt der Client einen Fallback zur anderen Warteschlange aus. Der Empfänger lauscht an beiden Warteschlangen. Dieser Ansatz reduziert die Anzahl doppelter Nachrichten, die gesendet werden. Der Empfänger muss jedoch weiterhin doppelte Nachrichten verarbeiten.

    Weitere Informationen finden Sie unter GeoReplication-Beispiel und Bewährte Methoden zum Schützen von Anwendungen vor Service Bus-Ausfällen und Notfällen.

Doppelt vorhandene Nachricht.

Erkennung: Überprüfen Sie die Eigenschaften MessageId und DeliveryCount der Nachricht.

Wiederherstellung:

  • Gestalten Sie Ihre Verarbeitungsvorgänge für Nachrichten nach Möglichkeit idempotent. Andernfalls speichern Sie Nachrichten-IDs von bereits verarbeiteten Nachrichten, und überprüfen Sie die ID vor der Verarbeitung einer Nachricht.

  • Aktivieren Sie die Duplikaterkennung, indem Sie beim Erstellen der Warteschlange RequiresDuplicateDetection auf „true“ festlegen. Mit dieser Einstellung löscht Service Bus automatisch alle Nachrichten, die mit derselben MessageId wie eine vorherige Nachricht gesendet werden. Beachten Sie Folgendes:

    • Diese Einstellung verhindert, dass doppelte Nachrichten in die Warteschlange gestellt werden. Sie hindert einen Empfänger nicht daran, dieselbe Nachricht mehrmals zu verarbeiten.
    • Die Duplikaterkennung verfügt über ein Zeitfenster. Wenn dieses Zeitfenster beim Senden eines Duplikats überschritten wird, kann das Duplikat nicht erkannt werden.

Diagnose: Protokollieren Sie doppelte Nachrichten.

Die Anwendung kann eine bestimmte Nachricht aus der Warteschlange nicht verarbeiten.

Erkennung: Dies ist anwendungsspezifisch. Die Nachricht enthält z. B. ungültige Daten oder bei der Geschäftslogik ist ein Fehler aufgetreten.

Wiederherstellung:

Zwei Fehlermodi müssen berücksichtigt werden.

  • Der Empfänger erkennt den Fehler. In diesem Fall verschieben Sie die Nachricht in die Warteschlange für unzustellbare Nachrichten. Führen Sie später einen separaten Prozess aus, um die Nachrichten in der Warteschlange für unzustellbare Nachrichten zu untersuchen.
  • Beim Empfänger tritt während der Verarbeitung der Nachricht ein Fehler auf, z. B. ein Ausnahmefehler. Verwenden Sie den Modus PeekLock, um diesen Fall zu behandeln. Wenn in diesem Modus die Sperre abläuft, wird die Nachricht für andere Empfänger verfügbar. Wenn die Nachricht die maximale Anzahl der Zustellungen oder die Gültigkeitsdauer überschreitet, wird die Nachricht automatisch in die Warteschlange für unzustellbare Nachrichten verschoben.

Weitere Informationen finden Sie unter Übersicht über Service Bus-Warteschlangen für unzustellbare Nachrichten.

Diagnose: Sobald die Anwendung eine Nachricht in die Warteschlange für unzustellbare Nachrichten verschiebt, schreiben Sie ein Ereignis in die Anwendungsprotokolle.

Storage

Beim Schreiben von Daten in Azure Storage ist ein Fehler aufgetreten.

Erkennung: Der Client erhält beim Schreiben entsprechende Fehlermeldungen.

Wiederherstellung:

  1. Versuchen Sie den Vorgang erneut, um die Wiederherstellung nach vorübergehenden Fehlern zu erreichen. Die Wiederholungsrichtlinie im Client-SDK verarbeitet dies automatisch.

  2. Implementieren Sie das Trennschalter-Muster, um eine Überlastung des Speichers zu vermeiden.

  3. Wenn bei N Wiederholungsversuchen Fehler auftreten, führen Sie einen ordnungsgemäßen Fallback aus. Beispiel:

    • Speichern Sie die Daten in einem lokalen Cache, und leiten Sie die Schreibvorgänge zu einem späteren Zeitpunkt, wenn der Dienst verfügbar ist, an den Speicher weiter.
    • Wenn der Schreibvorgang in einem Transaktionsbereich erfolgt ist, kompensieren Sie die Transaktion.

Diagnose: Verwenden Sie die Speichermetriken.

Beim Lesen von Daten aus Azure Storage tritt ein Fehler auf.

Erkennung: Der Client erhält beim Lesen entsprechende Fehlermeldungen.

Wiederherstellung:

  1. Versuchen Sie den Vorgang erneut, um die Wiederherstellung nach vorübergehenden Fehlern zu erreichen. Die Wiederholungsrichtlinie im Client-SDK verarbeitet dies automatisch.
  2. Wenn für RA-GRS-Speicher beim Lesen aus dem primären Endpunkt ein Fehler auftritt, versuchen Sie den Lesevorgang mit einem sekundären Endpunkt. Das Client-SDK kann dies automatisch verarbeiten. Informationen finden Sie unter Azure Storage-Replikation.
  3. Wenn bei N Wiederholungsversuchen Fehler auftreten, führen Sie eine Fallbackaktion zum ordnungsgemäßen Herabstufen durch. Wenn z. B. ein Produktbild nicht aus dem Speicher abgerufen werden kann, zeigen Sie ein allgemeines Platzhalterbild an.

Diagnose: Verwenden Sie die Speichermetriken.

Virtueller Computer

Beim Herstellen der Verbindung mit einer Back-End-VM ist ein Fehler aufgetreten.

Erkennung: Netzwerkverbindungsfehler.

Wiederherstellung:

  • Stellen Sie mindestens zwei Back-End-VMs in einer Verfügbarkeitsgruppe hinter einem Lastenausgleich bereit.
  • Wenn der Verbindungsfehler vorübergehend ist, wird TCP manchmal erfolgreich versuchen, die Nachricht erneut zu senden.
  • Implementieren Sie eine Wiederholungsrichtlinie in der Anwendung.
  • Für persistente oder nicht vorübergehende Fehler implementieren Sie das Trennschalter-Muster.
  • Überschreitet die aufrufende VM den Ausgangsgrenzwert für das Netzwerk, wird die ausgehende Warteschlange gefüllt. Wenn die ausgehende Warteschlange beständig voll ist, sollten Sie eine horizontale Skalierung in Betracht ziehen.

Diagnose: Protokollieren Sie Ereignisse an den Dienstgrenzen.

Eine VM-Instanz steht nicht mehr zur Verfügung oder ist fehlerhaft.

Erkennung: Konfigurieren Sie einen Load Balancer-Integritätstest, der angibt, ob die VM-Instanz fehlerfrei ist. Der Test sollte überprüfen, ob wichtige Funktionen ordnungsgemäß reagieren.

Wiederherstellen. Stellen Sie für jede Anwendungsschicht mehrere VM-Instanzen in dieselbe Verfügbarkeitsgruppe, und platzieren Sie einen Lastenausgleich vor den virtuellen Computern. Wenn beim Integritätstest ein Fehler auftritt, beendet der Load Balancer das Senden neuer Verbindungen an die fehlerhafte Instanz.

Diagnose: Verwenden Sie die Load Balancer-Protokollanalysen.

  • Konfigurieren Sie Ihr Überwachungssystem so, dass es alle Endpunkte der Integritätsüberwachung überwacht.

Der Operator fährt versehentlich einen virtuellen Computer herunter.

Erkennung: –

Wiederherstellen. Legen Sie eine Ressourcensperre mit der Stufe ReadOnly fest. Weitere Informationen finden Sie unter Sperren von Ressourcen mit Azure Resource Manager.

Diagnose: Verwenden Sie Azure-Aktivitätsprotokolle.

WebJobs

Wenn der SCM-Host im Leerlauf ist, wird der fortlaufende Auftrag abgebrochen.

Erkennung: Übergeben Sie ein Abbruchtoken an die WebJob-Funktion. Weitere Informationen finden Sie unter Ordnungsgemäßes Herunterfahren.

Wiederherstellen. Aktivieren Sie die Einstellung Always On in der Web-App. Weitere Informationen finden Sie unter Ausführen von Hintergrundaufgaben mit Webaufträgen.

Anwendungsentwurf

Die Anwendung kann nicht mit einer Steigerung der eingehenden Anforderungen zurechtkommen.

Erkennung: Dies hängt von der Anwendung ab. Typische Symptome:

  • Die Website beginnt mit der Rückgabe von „HTTP 5xx“-Fehlercodes.
  • Abhängige Dienste wie der Datenbank- oder Speicherdienst beginnen damit, Anforderungen zu beschränken. Suchen Sie in Abhängigkeit vom Dienst nach HTTP-Fehlern wie HTTP 429 (Zu viele Anforderungen).
  • Die Länge der HTTP-Warteschlange nimmt zu.

Wiederherstellung:

  • Führen Sie eine Aufskalierung durch, um die erhöhte Workload zu bewältigen.

  • Reduzieren Sie Fehler, um zu vermeiden, dass sich überlappende Fehler die gesamte Anwendung stören. Mögliche Lösungsstrategien:

    • Implementieren Sie das Drosselungsmuster, um eine Überlastung der Back-End-Systeme zu vermeiden.
    • Verwenden Sie den warteschlangenbasierten Lastenausgleich, um Anforderungen zu puffern und mit angemessener Geschwindigkeit zu verarbeiten.
    • Priorisieren Sie bestimmte Clients. Wenn die Anwendung z. B. über kostenlose und kostenpflichtige Tarife verfügt, beschränken Sie Kunden mit kostenlosen Tarifen, aber nicht Kunden mit kostenpflichtigen Tarifen. Weitere Informationen finden Sie unter Muster „Prioritätswarteschlange“.

Diagnose: Verwenden Sie die App Service-Diagnoseprotokollierung. Verwenden Sie einen Dienst wie Azure Log Analytics, Application Insights oder New Relic, um die Diagnoseprotokolle besser zu verstehen.

Ein Beispiel ist hier verfügbar. In diesem Beispiel wird Polly für die folgenden Ausnahmen verwendet:

  • 429 – Throttling (Drosselung)
  • 408 – Timeout (Zeitüberschreitung)
  • 401 – Unauthorized (Nicht autorisiert)
  • 503 oder 5xx – Service unavailable (Dienst nicht verfügbar)

Bei einem der Vorgänge in einem Workflow oder in einer verteilten Transaktion ist ein Fehler aufgetreten.

Erkennung: Nach N Wiederholungsversuchen tritt der Fehler weiterhin auf.

Wiederherstellung:

  • Implementieren Sie als vorbeugende Maßnahme das Muster Scheduler-Agent-Supervisor, um den gesamten Workflow zu verwalten.
  • Wiederholen Sie den Versuch nicht bei Timeouts. Die Erfolgsquote für diesen Fehler ist gering.
  • Verschieben Sie die Arbeit in eine Warteschlange, um es zu einem späteren erneut zu versuchen.

Diagnose: Protokollieren Sie alle Vorgänge (erfolgreiche und fehlerhafte), einschließlich der Ausgleichsmaßnahmen. Verwenden Sie Korrelations-IDs, damit Sie alle Vorgänge innerhalb einer Transaktion verfolgen können.

Beim Aufruf eines Remotediensts ist ein Fehler aufgetreten.

Erkennung: HTTP-Fehlercode.

Wiederherstellung:

  1. Wiederholen Sie den Vorgang bei vorübergehenden Fehlern.
  2. Wenn der Aufruf nach N Versuchen Fehler aufweist, führen Sie einen Fallback aus. (Dies ist anwendungsspezifisch.)
  3. Implementieren Sie das Trennschalter-Muster, um überlappende Fehler zu vermeiden.

Diagnose: Protokollieren Sie alle Fehler von Remoteaufrufen.

Nächste Schritte

Weitere Informationen finden Sie unter Resilienz und Abhängigkeiten im Azure Well-Architected Framework. Das Integrieren von Wiederherstellung nach Fehlern in das System sollte von Anfang an Teil der Architektur- und Entwurfsphasen sein, um das Risiko eines Ausfalls zu vermeiden.