Behandeln von Clientanwendungsfehlern in Azure-Speicherkonten

In diesem Artikel erfahren Sie, wie Sie Clientanwendungsfehler mithilfe von Metriken, clientseitigen Protokollen und Ressourcenprotokollen in Azure Monitor untersuchen.

Diagnostizieren von Fehlern

Benutzer Ihrer Anwendung können Sie über Von der Clientanwendung gemeldete Fehler benachrichtigen. Azure Monitor zeichnet auch die Anzahl verschiedener Antworttypen (ResponseType-Dimensionen ) von Ihren Speicherdiensten auf, z. B. NetworkError, ClientTimeoutError oder AuthorizationError. Während Azure Monitor nur die Anzahl verschiedener Fehlertypen aufzeichnet, können Sie weitere Details zu einzelnen Anforderungen abrufen, indem Sie serverseitige, clientseitige und Netzwerkprotokolle untersuchen. In der Regel gibt der vom Speicherdienst zurückgegebene HTTP-status Code einen Hinweis darauf, warum die Anforderung fehlgeschlagen ist.

Die folgenden Ressourcen sind hilfreich, um speicherbezogene status und Fehlercodes zu verstehen:

• Häufige Rest-API-Fehlercodes
• Fehlercodes des Blobdiensts
• Warteschlangendienst-Fehlercodes
• Tabellendienstfehlercodes
• Fehlercodes des Dateidiensts

Der Client empfängt HTTP 403 (Verboten) Nachrichten.

Wenn Ihre Clientanwendung HTTP 403 (Verboten)-Fehler auslöst, ist eine wahrscheinliche Ursache, dass der Client eine abgelaufene Shared Access Signature (SAS) verwendet, wenn er eine Speicheranforderung sendet (obwohl andere mögliche Ursachen eine Uhrschiefe, ungültige Schlüssel und leere Header sind).

Mit der Speicherclientbibliothek für .NET können Sie clientseitige Protokolldaten sammeln, die sich auf Speichervorgänge beziehen, die von Ihrer Anwendung ausgeführt werden. Weitere Informationen finden Sie unter Clientseitige Protokollierung mit der .NET-Speicherclientbibliothek.

Die folgende Tabelle zeigt ein Beispiel aus dem clientseitigen Protokoll, das von der Speicherclientbibliothek generiert wurde und dieses Problem veranschaulicht:

In diesem Szenario sollten Sie untersuchen, warum das SAS-Token abläuft, bevor der Client das Token an den Server sendet:

• In der Regel sollten Sie keine Startzeit festlegen, wenn Sie eine SAS erstellen, die von einem Client sofort verwendet werden kann. Wenn es kleine Taktunterschiede zwischen dem Host, der die SAS mit der aktuellen Zeit generiert, und dem Speicherdienst gibt, kann der Speicherdienst eine sas empfangen, die noch nicht gültig ist.

• Legen Sie keine sehr kurze Ablaufzeit für eine SAS fest. Auch hier können kleine Taktunterschiede zwischen dem Host, der die SAS generiert, und dem Speicherdienst dazu führen, dass eine SAS früher als erwartet abläuft.

• Stimmt der Versionsparameter im SAS-Schlüssel (z. B sv. =2015-04-05) mit der Version der verwendeten Speicherclientbibliothek überein? Es wird empfohlen, immer die neueste Version der Speicherclientbibliothek zu verwenden.

• Wenn Sie Ihre Speicherzugriffsschlüssel erneut generieren, werden alle vorhandenen SAS-Token möglicherweise ungültig. Dieses Problem kann auftreten, wenn Sie SAS-Token mit einer langen Ablaufzeit für die Zwischenspeicherung von Clientanwendungen generieren.

Wenn Sie die Speicherclientbibliothek zum Generieren von SAS-Token verwenden, ist es einfach, ein gültiges Token zu erstellen. Wenn Sie jedoch die Storage-REST-API verwenden und die SAS-Token manuell erstellen, lesen Sie Delegating Access with a Shared Access Signature (Delegating Access with a Shared Access Signature).

Der Client empfängt HTTP 404(Nicht gefunden)-Nachrichten.

Wenn die Clientanwendung eine HTTP 404 (Nicht gefunden)-Nachricht vom Server empfängt, bedeutet dies, dass das Objekt, das der Client zu verwenden versucht (z. B. eine Entität, tabelle, ein Blob, ein Container oder eine Warteschlange), im Speicherdienst nicht vorhanden ist. Hierfür gibt es eine Reihe möglicher Gründe, z. B.:

• Der Client oder ein anderer Prozess hat das Objekt zuvor gelöscht.

• Ein Sas-Autorisierungsproblem (Shared Access Signature).

• Clientseitiger JavaScript-Code verfügt nicht über die Berechtigung für den Zugriff auf das Objekt.

• Netzwerkfehler.

Der Client oder ein anderer Prozess hat das Objekt zuvor gelöscht.

In Szenarien, in denen der Client versucht, Daten in einem Speicherdienst zu lesen, zu aktualisieren oder zu löschen, ist es einfach, in den Speicherressourcenprotokollen einen vorherigen Vorgang zu identifizieren, durch den das betreffende Objekt aus dem Speicherdienst gelöscht wurde. Häufig zeigen die Protokolldaten, dass ein anderer Benutzer oder Prozess das Objekt gelöscht hat. Die Azure Monitor-Protokolle (serverseitig) zeigen an, wann ein Client ein Objekt gelöscht hat.

In dem Szenario, in dem ein Client versucht, ein Objekt einzufügen, ist es möglicherweise nicht sofort offensichtlich, warum dies zu einer HTTP 404 (Nicht gefunden)-Antwort führt, da der Client ein neues Objekt erstellt. Wenn der Client jedoch ein Blob erstellt, muss er den Blobcontainer finden können. Wenn der Client eine Nachricht erstellt, muss er in der Lage sein, eine Warteschlange zu finden. Und wenn der Client eine Zeile hinzufügt, muss er in der Lage sein, die Tabelle zu finden.

Sie können das clientseitige Protokoll aus der Speicherclientbibliothek verwenden, um besser zu verstehen, wann der Client bestimmte Anforderungen an den Speicherdienst sendet.

Das folgende clientseitige Protokoll, das von der Speicherclientbibliothek generiert wird, veranschaulicht das Problem, wenn der Client den Container für das blob, das er erstellt, nicht finden kann. Dieses Protokoll enthält Details zu den folgenden Speichervorgängen:

Protokolleinträge:

In diesem Beispiel zeigt das Protokoll, dass der Client Anforderungen der CreateIfNotExists -Methode (Anforderungs-ID e2d06d78...) mit den Anforderungen der UploadFromStream -Methode (de8b1c3c-...) übergibt. Diese Verschachtelung erfolgt, weil die Clientanwendung diese Methoden asynchron aufruft. Ändern Sie den asynchronen Code im Client, um sicherzustellen, dass der Container erstellt wird, bevor Versucht wird, Daten in ein Blob in diesem Container hochzuladen. Im Idealfall sollten Sie alle Ihre Container im Voraus erstellen.

Ein Sas-Autorisierungsproblem (Shared Access Signature)

Wenn die Clientanwendung versucht, einen SAS-Schlüssel zu verwenden, der nicht die erforderlichen Berechtigungen für den Vorgang enthält, gibt der Speicherdienst eine HTTP 404 (Nicht gefunden)-Nachricht an den Client zurück. Gleichzeitig wird in Azure Monitor-Metriken auch ein AuthorizationError für die ResponseType-Dimension angezeigt.

Untersuchen Sie, warum Ihre Clientanwendung versucht, einen Vorgang auszuführen, für den ihr keine Berechtigungen erteilt wurden.

Clientseitiger JavaScript-Code verfügt nicht über die Berechtigung für den Zugriff auf das Objekt.

Wenn Sie einen JavaScript-Client verwenden und der Speicherdienst HTTP 404-Nachrichten zurückgibt, überprüfen Sie, ob die folgenden JavaScript-Fehler im Browser vorliegen:

SEC7120: Der Ursprung http://localhost:56309 wurde im Access-Control-Allow-Origin-Header nicht gefunden.
SCRIPT7002: XMLHttpRequest: Netzwerkfehler 0x80070005, Zugriff verweigert.

Diese Fehler treten auf, weil der Webbrowser die gleiche Ursprungsrichtlinie-Sicherheitseinschränkung implementiert, die verhindert, dass eine Webseite eine API in einer anderen Domäne als der Domäne aufruft, aus der die Seite stammt.

Um das JavaScript-Problem zu umgehen, können Sie CORS (Cross-Origin Resource Sharing) für den Speicherdienst konfigurieren, auf den der Client zugreift. Weitere Informationen finden Sie unter CorS-Unterstützung (Cross-Origin Resource Sharing) für Azure Storage-Dienste.

Im folgenden Codebeispiel wird gezeigt, wie Sie Ihren Blobdienst so konfigurieren, dass JavaScript, das in der Contoso-Domäne ausgeführt wird, auf ein Blob in Ihrem Blobspeicherdienst zugreifen kann:

var connectionString = Constants.connectionString;

 BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);

 BlobServiceProperties sp = blobServiceClient.GetProperties();

 // Set the service properties.
 sp.DefaultServiceVersion = "2013-08-15";
 BlobCorsRule bcr = new BlobCorsRule();
 bcr.AllowedHeaders = "*";

 bcr.AllowedMethods = "GET,POST";
 bcr.AllowedOrigins = "http://www.contoso.com";
 bcr.ExposedHeaders = "x-ms-*";
 bcr.MaxAgeInSeconds = 5;
 sp.Cors.Clear();
 sp.Cors.Add(bcr);
 blobServiceClient.SetProperties(sp);

Netzwerkfehler

Unter bestimmten Umständen können verlorene Netzwerkpakete dazu führen, dass der Speicherdienst HTTP 404-Nachrichten an den Client zurückgibt. Wenn Ihre Clientanwendung beispielsweise eine Entität aus dem Tabellendienst löscht, sehen Sie, dass der Client eine Speicher-Ausnahme auslöst, die eine "HTTP 404 (Nicht gefunden)"-status Meldung vom Tabellendienst meldet. Wenn Sie die Tabelle im Tabellenspeicherdienst untersuchen, sehen Sie, dass der Dienst die Entität wie angefordert gelöscht hat.

Die Ausnahmedetails im Client enthalten die Anforderungs-ID (7e84f12d...), die vom Tabellendienst für die Anforderung zugewiesen wurde. Sie können diese Informationen verwenden, um die Anforderungsdetails in den Speicherressourcenprotokollen in Azure Monitor zu suchen, indem Sie in Feldern suchen, die beschreiben, wie der Vorgang von Protokolleinträgen authentifiziert wurde. Sie können die Metriken auch verwenden, um zu ermitteln, wann Fehler wie dieser auftreten, und dann die Protokolldateien basierend auf dem Zeitpunkt durchsuchen, zu dem die Metriken diesen Fehler aufgezeichnet haben. Dieser Protokolleintrag zeigt, dass beim Löschen die Meldung "HTTP (404) Client Other Error" status fehlgeschlagen ist. Derselbe Protokolleintrag enthält auch die vom Client in der client-request-id Spalte generierte Anforderungs-ID (813ea74f...).

Das serverseitige Protokoll enthält auch einen weiteren Eintrag mit demselben client-request-id Wert (813ea74f...) für einen erfolgreichen Löschvorgang für dieselbe Entität und vom gleichen Client. Dieser erfolgreiche Löschvorgang fand kurz vor der fehlgeschlagenen Löschanforderung statt.

Die wahrscheinlichste Ursache für dieses Szenario ist, dass der Client eine Löschanforderung für die Entität an den Tabellendienst gesendet hat, die erfolgreich war, aber keine Bestätigung vom Server erhalten hat (möglicherweise aufgrund eines temporären Netzwerkproblems). Der Client hat dann automatisch den Vorgang wiederholt (mit demselben client-request-id), und dieser Wiederholungsversuch ist fehlgeschlagen, da die Entität bereits gelöscht wurde.

Wenn dieses Problem häufig auftritt, sollten Sie untersuchen, warum der Client keine Bestätigungen vom Tabellendienst empfangen kann. Wenn das Problem zeitweilig auftritt, sollten Sie den Fehler "HTTP (404) Nicht gefunden" abfangen und im Client protokollieren, aber dem Client erlauben, den Vorgang fortzusetzen.

Der Client empfängt HTTP 409-Nachrichten (Konflikt)

Wenn ein Client Blobcontainer, Tabellen oder Warteschlangen löscht, gibt es einen kurzen Zeitraum, bevor der Name wieder verfügbar ist. Wenn der Code in Ihrer Clientanwendung einen Blobcontainer mit demselben Namen löscht und dann sofort neu erstellt, schlägt die CreateIfNotExists Methode schließlich mit dem HTTP-Fehler 409 (Konflikt) fehl.

Die Clientanwendung sollte eindeutige Containernamen verwenden, wenn sie neue Container erstellt, wenn das Lösch-/Neuerstellungsmuster üblich ist.

Metriken zeigen niedrige PercentSuccess- oder Analyseprotokolleinträge weisen Vorgänge mit transaktionsbezogenen status von ClientOtherErrors auf.

Eine ResponseType-Dimension , die dem Wert Success entspricht, erfasst den Prozentsatz der erfolgreichen Vorgänge basierend auf ihrem HTTP-Statuscode. Vorgänge mit status Codes von 2XX gelten als erfolgreich, während Vorgänge mit status Codes in den Bereichen 3XX, 4XX und 5XX als nicht erfolgreich gezählt werden und den Metrikwert Erfolg verringern. In Speicherressourcenprotokollen werden diese Vorgänge mit einer Transaktion status ClientOtherError aufgezeichnet.

Diese Vorgänge wurden erfolgreich abgeschlossen und wirken sich daher nicht auf andere Metriken aus, z. B. die Verfügbarkeit. Beispiele für Vorgänge, die erfolgreich ausgeführt werden, aber zu nicht erfolgreichen HTTP-status Codes führen können:

• ResourceNotFound (Nicht gefunden 404), z. B. aus einer GET-Anforderung an ein Blob, das nicht vorhanden ist.
• ResourceAlreadyExists (Konflikt 409), z. B. aus einem CreateIfNotExist Vorgang, bei dem die Ressource bereits vorhanden ist.
• ConditionNotMet (Not Modified 304), z. B. aus einem bedingten Vorgang, z. B. wenn ein Client einen ETag Wert und einen HTTP-Header If-None-Match sendet, um ein Image nur anzufordern, wenn es seit dem letzten Vorgang aktualisiert wurde.

Eine Liste der allgemeinen REST-API-Fehlercodes, die von den Speicherdiensten zurückgegeben werden, finden Sie auf der Seite Allgemeine REST-API-Fehlercodes.

Siehe auch

• Überwachung Azure Blob Storage
• Überwachung Azure Files
• Überwachen von Azure Queue Storage
• Überwachen von Azure Table Storage
• Behandlung von Leistungsproblemen
• Behandeln von Verfügbarkeitsproblemen
• Überwachen, Diagnostizieren und Beheben von Problemen mit Azure Storage

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.