Beheben von Clientanwendungsfehlern in Azure-Speicherkonten
In diesem Artikel erfahren Sie, wie Sie Clientanwendungsfehler mithilfe von Metriken, clientseitigen Protokollen und Ressourcenprotokollen in Azure Monitor untersuchen.
Fehlerdiagnose
Benutzer Ihrer Anwendung können Sie über Fehler informieren, die von der Clientanwendung gemeldet werden. Azure Monitor zeichnet auch die Anzahl verschiedener Antworttypen (ResponseType-Dimensionen) aus Ihren Speicherdiensten auf, z. B. NetworkError, ClientTimeoutError oder AuthorizationError. Während Azure Monitor nur die Anzahl der verschiedenen Fehlerarten erfasst, können Sie durch die Untersuchung von serverseitigen, clientseitigen und Netzwerkprotokollen weitere Informationen zu einzelnen Anforderungen erhalten. In der Regel liefert der vom Speicherdienst zurückgegebene HTTP-Statuscode einen Hinweis auf den Grund für das Scheitern der Anfrage.
Notiz
Denken Sie daran, dass Sie erwarten sollten, dass einige zeitweilige Fehler angezeigt werden. Fehler beispielsweise aufgrund vorübergehender Netzwerkbedingungen oder Anwendungsfehler.
Die folgenden Ressourcen sind nützlich für das Verständnis von speicherbezogenem Status und Fehlercodes:
- Allgemeine REST-API-Fehlercodes
- Blob-Dienst-Fehlercodes
- Fehlercodes für den Warteschlangendienst
- Fehlercodes für den Tabellendienst
- Fehlercodes für den Dateidienst
Der Client empfängt HTTP 403 (Verboten)-Meldungen
Wenn Ihre Clientanwendung einen HTTP 403 (Verboten)-Fehler ausgibt, ist eine wahrscheinliche Ursache, dass der Client eine abgelaufene Shared Access Signature (SAS) verwendet, wenn er eine Speicheranfrage versendet. (Weitere mögliche Ursachen sind Zeitverzögerung, ungültige Schlüssel und leere Header).
Mit der Speicher-Clientbibliothek für .NET können Sie clientseitige Protokollierungsdaten sammeln, die sich auf Speicheroperationen in Ihrer Anwendung beziehen. Weitere Informationen finden Sie unter Clientseitige Protokollierung mit der .NET Storage Client Library.
Die folgende Tabelle zeigt ein Beispiel für eine von der Speicher-Clientbibliothek generierte Clientprotokollierung, die folgende Problemstellung veranschaulicht:
| `Source` | Ausführlichkeit | Ausführlichkeit | Clientanfrage-ID | Operation Text |
|---|---|---|---|---|
| Microsoft.Azure.Storage | Information | 3 | 85d077ab-… | Starting operation with location Primary per location mode PrimaryOnly. |
| Microsoft.Azure.Storage | Information | 3 | 85d077ab-… | Starting synchronous request to <https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests#Synchronous_request> |
| Microsoft.Azure.Storage | Information | 3 | 85d077ab-… | Waiting for response. |
| Microsoft.Azure.Storage | Warnung | 2 | 85d077ab-… | Exception thrown while waiting for response: The remote server returned an error: (403) Forbidden. |
| Microsoft.Azure.Storage | Information | 3 | 85d077ab-… | Response received. Status code = 403, Request ID = <Request ID>, Content-MD5 = , ETag = . |
| Microsoft.Azure.Storage | Warnung | 2 | 85d077ab-… | Exception thrown during the operation: The remote server returned an error: (403) Forbidden.. |
| Microsoft.Azure.Storage | Information | 3 | 85d077ab-… | Checking if the operation should be retried. Retry count = 0, HTTP status code = 403, Exception = The remote server returned an error: (403) Forbidden.. |
| Microsoft.Azure.Storage | Information | 3 | 85d077ab-… | The next location has been set to Primary, based on the location mode. |
| Microsoft.Azure.Storage | Fehler | 1 | 85d077ab-… | Retry policy did not allow for a retry. Failing with The remote server returned an error: (403) Forbidden. |
In diesem Szenario sollten Sie untersuchen, warum der SAS-Token abläuft, bevor der Client den Token an den Server sendet:
In der Regel sollten Sie keine Startzeit festlegen, wenn Sie ein SAS für einen Client erstellen, der sofort verwendet werden soll. Wenn es kleine Zeitunterschiede zwischen dem die SAS generierenden Host und dem Speicherdienst gibt, kann der Speicherdienst eine noch nicht gültige SAS empfangen.
Legen Sie keine sehr kurze Ablaufzeit für eine SAS fest. Auch hier gilt: Kleine Zeitunterschiede zwischen dem Host, der die SAS generiert, und dem Speicherdienst können dazu führen, dass eine SAS früher als erwartet abläuft.
Stimmt der Versionsparameter im SAS-Schlüssel (z
sv. B. =2015-04-05) mit der Version der verwendeten Speicherclientbibliothek überein? Sie sollten immer die neueste Version der Storage-Clientbibliothek verwenden.Wenn Sie Ihren Speicherzugriffsschlüssel neu erstellen, können dadurch vorhandene SAS-Token ungültig werden. Dieses Problem kann auftreten, wenn Sie SAS-Token mit einer langen Ablaufzeit zum Cachen von Clientanwendungen generieren.
Wenn Sie die Speicherclientbibliothek verwenden, um SAS-Token zu erstellen, ist es einfach, einen gültigen Token anzulegen. Wenn Sie allerdings die Speicher-REST-API verwenden und die SAS-Token manuell anlegen, hilft Ihnen das Thema Delegieren des Zugriffs mit einer Shared Access Signature weiter.
Der Client empfängt HTTP 404 (Nicht gefunden)-Meldungen
Wenn die Clientanwendung eine HTTP 404 (Nicht gefunden)-Meldung vom Server empfängt, bedeutet dies, dass das Objekt, das der Client verwenden will (z. B. eine Entität, Tabelle, Blob, Container oder Warteschlange) nicht im Speicherdienst vorhanden ist. Hierfür gibt es eine Reihe möglicher Gründe, beispielsweise:
Das Objekt wurde vom Client oder einem anderen Prozess vorher gelöscht.
Ein SAS-Autorisierungsproblem (Shared Access Signature).
Clientseitiger JavaScript-Code verfügt nicht über die Zugriffsberechtigung für das Objekt.
Netzwerkfehler.
Das Objekt wurde vom Client oder einem anderen Prozess vorher 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, der das betreffende Objekt aus dem Speicherdienst gelöscht hat. Häufig ergeben die Protokollierungsdaten, dass ein anderer Benutzer oder Prozess das Objekt gelöscht hat. Die Azure Monitor-Protokolle (serverseitig) werden angezeigt, wenn 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 -Antwort (Nicht gefunden) führt, da der Client ein neues Objekt erstellt. Wenn der Client jedoch ein Blob erstellt, muss er in der Lage sein, den BLOB-Container zu finden. 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 erstellte Blob nicht finden kann. Die Protokollierung enthält Details zu den folgenden Speicheroperationen:
| Anfrage-ID | Vorgang |
|---|---|
| 07b26a5d-... | DeleteIfExists methode zum Löschen des BLOB-Containers. Dieser Vorgang enthält eine HEAD-Anforderung , um das Vorhandensein des Containers zu überprüfen. |
| e2d06d78… | CreateIfNotExists -Methode zum Erstellen des BLOB-Containers. Dieser Vorgang enthält eine HEAD Anforderung, die das Vorhandensein des Containers überprüft. Die HEAD 404-Nachricht wird zurückgegeben, wird jedoch fortgesetzt. |
| de8b1c3c-... | UploadFromStream -Methode zum Erstellen des Blobs. Die PUT Anforderung schlägt mit einer 404-Nachricht fehl. |
Protokollierungseinträge:
| Anfrage-ID | Operation Text |
|---|---|
| 07b26a5d-... | Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer. |
| 07b26a5d-... | StringToSign = HEAD............x-ms-client-request-id:07b26a5d-....x-ms-date:Tue, 03 Jun 2014 10:33:11 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container. |
| 07b26a5d-... | Waiting for response. |
| 07b26a5d-... | Response received. Status code = 200, Request ID = eeead849-...Content-MD5 = , ETag = "0x8D14D2DC63D059B". |
| 07b26a5d-... | Response headers were processed successfully, proceeding with the rest of the operation. |
| 07b26a5d-... | Downloading response body. |
| 07b26a5d-... | Operation completed successfully. |
| 07b26a5d-... | Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer. |
| 07b26a5d-... | StringToSign = DELETE............x-ms-client-request-id:07b26a5d-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container. |
| 07b26a5d-... | Waiting for response. |
| 07b26a5d-... | Response received. Status code = 202, Request ID = 6ab2a4cf-..., Content-MD5 = , ETag = . |
| 07b26a5d-... | Response headers were processed successfully, proceeding with the rest of the operation. |
| 07b26a5d-... | Downloading response body. |
| 07b26a5d-... | Operation completed successfully. |
| e2d06d78-... | Starting asynchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer. |
| e2d06d78-... | StringToSign = HEAD............x-ms-client-request-id:e2d06d78-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container. |
| e2d06d78-... | Waiting for response. |
| de8b1c3c-... | Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer/blobCreated.txt. |
| de8b1c3c-... | StringToSign = PUT...64.qCmF+TQLPhq/YYK50mP9ZQ==........x-ms-blob-type:BlockBlob.x-ms-client-request-id:de8b1c3c-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer/blobCreated.txt. |
| de8b1c3c-... | Preparing to write request data. |
| e2d06d78-... | Exception thrown while waiting for response: The remote server returned an error: (404) Not Found.. |
| e2d06d78-... | Response received. Status code = 404, Request ID = 353ae3bc-..., Content-MD5 = , ETag = . |
| e2d06d78-... | Response headers were processed successfully, proceeding with the rest of the operation. |
| e2d06d78-... | Downloading response body. |
| e2d06d78-... | Operation completed successfully. |
| e2d06d78-... | Starting asynchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer. |
| e2d06d78-... | StringToSign = PUT...0.........x-ms-client-request-id:e2d06d78-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container. |
| e2d06d78-... | Waiting for response. |
| de8b1c3c-... | Writing request data. |
| de8b1c3c-... | Waiting for response. |
| e2d06d78-... | Exception thrown while waiting for response: The remote server returned an error: (409) Conflict.. |
| e2d06d78-... | Response received. Status code = 409, Request ID = c27da20e-..., Content-MD5 = , ETag = . |
| e2d06d78-... | Downloading error response body. |
| de8b1c3c-... | Exception thrown while waiting for response: The remote server returned an error: (404) Not Found.. |
| de8b1c3c-... | Response received. Status code = 404, Request ID = 0eaeab3e-..., Content-MD5 = , ETag = . |
| de8b1c3c-... | Exception thrown during the operation: The remote server returned an error: (404) Not Found.. |
| de8b1c3c-... | Retry policy did not allow for a retry. Failing with The remote server returned an error: (404) Not Found.. |
| e2d06d78-... | Retry policy did not allow for a retry. Failing with The remote server returned an error: (409) Conflict.. |
In diesem Beispiel zeigt das Protokoll, dass der Client Anforderungen aus der CreateIfNotExists Methode interleaviert (Anforderungs-ID e2d06d78...) mit den Anforderungen aus der UploadFromStream Methode (de8b1c3c-...). Diese Interleaving geschieht, da die Clientanwendung diese Methoden asynchron aufruft. Ändern Sie den asynchronen Code im Client, um sicherzustellen, dass er die Container erstellt, bevor er versucht, Daten an ein Blob in diesem Container hochzuladen. Idealerweise sollten Sie alle Ihre Container im Voraus erstellen.
Ein Problem mit der Shared Access Signature (SAS)-Authentifizierung
Wenn die Clientanwendung versucht, einen SAS-Schlüssel ohne die notwendigen Genehmigungen für den Vorgang zu verwenden, liefert der Speicherdienst eine HTTP 404-Meldung (Nicht gefunden) an den Client zurück. Gleichzeitig sehen Sie in Azure Monitor-Metriken auch einen AuthorizationError für die ResponseType-Dimension .
Untersuchen Sie, warum Ihre Clientanwendung versucht, einen Vorgang auszuführen, für den sie keine Berechtigungen erteilt hat.
Clientseitiger JavaScript-Code verfügt nicht über die Zugriffsberechtigung für das Objekt
Wenn Sie einen JavaScript-Client verwenden und der Speicherdienst HTTP 404-Nachrichten zurückgibt, überprüfen Sie die folgenden JavaScript-Fehler im Browser:
SEC7120: Der Ursprung http://localhost:56309 wurde im Access-Control-Allow-Origin-Header nicht gefunden.
SCRIPT7002: XMLHttpRequest: Netzwerkfehler 0x80070005, Access wird verweigert.
Notiz
Sie können die F12-Entwicklertools im Internet Explorer verwenden, um die zwischen Browser und Speicherdienst ausgetauschten Meldungen zu verfolgen, wenn Sie clientseitige JavaScript-Probleme behandeln.
Diese Fehler treten auf, weil im Webbrowser die Same Origin Policy als Sicherheitsbeschränkung implementiert ist, welche die Webseite daran hindert, eine API aus einer anderen Domäne aufzurufen.
Um das JavaScript-Problem zu umgehen, können Sie cross-Origin Resource Sharing (CORS) für den Speicherdienst konfigurieren, auf den der Client zugreift. Weitere Informationen finden Sie unter Cross-Origin Resource Sharing (CORS)-Support für die Azure-Speicherdienste.
Das folgende Codebeispiel zeigt, wie Sie Ihren Blob-Dienst so konfigurieren, dass JavaScript in der Contoso-Domäne ausgeführt wird, um auf ein Blob in Ihrem Blob-Speicherdienst zuzugreifen:
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.
In einigen Fällen können verlorene Netzwerkpakete dazu führen, dass der Speicherdienst HTTP 404-Nachrichten an den Client zurückliefert. Wenn Ihre Clientanwendung beispielsweise eine Entität aus dem Tabellendienst löscht, wird vom Client eine Speicher ausnahme ausgelöst, die eine Statusmeldung "HTTP 404 (Nicht gefunden)" aus dem Tabellendienst meldet. Wenn Sie die Tabelle im Tabellenspeicherdienst untersuchen, sehen Sie, dass der Dienst die Entität wie gefordert gelöscht hat.
Zu den Ausnahmedetails im Client gehört die vom Tabellenspeicherdienst zugewiesene Anforderungs-ID (7e84f12d...) für die Anforderung. Anhand dieser Informationen können Sie die Anforderungsdetails in den Storage-Ressourcenprotokollen in Azure Monitor ermitteln, indem Sie in den Protokolleinträgen in Feldern suchen, in denen die Authentifizierung des Vorgangs beschrieben wird. Sie könnten die Metriken auch verwenden, um zu identifizieren, wann solche Fehler auftreten, und anschließend die Protokollierungsdateien durchsuchen, ausgehend vom Zeitpunkt, an dem die Metriken diesen Fehler aufgezeichnet haben. Dieser Protokolleintrag zeigt, dass das Löschen mit einer HTTP 404-Status-Meldung "Client Other Error" fehlgeschlagen ist. Derselbe Protokolleintrag enthält auch die vom Client generierte Anforderungs-ID in der client-request-id Spalte (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 von demselben Client. Dieser erfolgreiche Löschvorgang erfolgte kurz vor der fehlgeschlagenen Löschanforderung.
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 den Vorgang automatisch erneut ausgeführt (unter Verwendung desselben 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 aus dem Tabellendienst erhält. Wenn das Problem intermittierend ist, sollten Sie den Fehler "HTTP (404) Nicht gefunden" eingrenzen und im Client protokollieren, aber dem Client die Fortführung erlauben.
Der Client empfängt HTTP 409 (Konflikt)-Meldungen
Wenn ein Client Blobcontainer, Tabellen oder Warteschlangen löscht, gibt es einen kurzen Zeitraum, bevor der Name wieder verfügbar wird. Wenn der Code in Ihrer Clientanwendung löscht und dann sofort einen BLOB-Container unter demselben Namen neu erstellt, schlägt die CreateIfNotExists Methode schließlich mit dem HTTP 409 (Conflict)-Fehler fehl.
Beim Erstellen neuer Container sollte die Clientanwendung eindeutige Containernamen verwenden, wenn das Lösch-/Wiedererstellungsmuster übereinstimmt.
Metriken zeigen niedrigen PercentSuccess an, oder Analyse-Protokollierungseinträge enthalten Operationen mit Transaktionsstatus "ClientOtherErrors"
Eine ResponseType-Dimension mit dem Wert Success erfasst den Prozentsatz der Vorgänge, die basierend auf ihrem HTTP-Statuscode erfolgreich waren. Vorgänge mit Statuscodes von 2XX zählen als erfolgreich, während Vorgänge mit Statuscodes in den Bereichen 3XX, 4XX und 5XX als erfolglos gezählt werden und den Erfolgsmetrikwert senken. In den Storage-Ressourcenprotokollen werden diese Vorgänge mit dem Transaktionsstatus ClientOtherError erfasst.
Diese Vorgänge wurden erfolgreich abgeschlossen und wirken sich daher nicht auf andere Metriken aus, z. B. verfügbarkeit. Hier sind einige Beispiele für Vorgänge, die erfolgreich ausgeführt werden, aber zu erfolglosen HTTP-Statuscodes führen:
- ResourceNotFound (Not Found 404), z. B. von einer GET-Anforderung an ein BLOB, das nicht vorhanden ist.
- ResourceAlreadyExists (Conflict 409), z. B. aus einem
CreateIfNotExistVorgang, in dem die Ressource bereits vorhanden ist. - ConditionNotMet (Not Modified 304), z. B. aus einem bedingten Vorgang, z. B. wenn ein Client einen Wert und einen
ETagHTTP-HeaderIf-None-Matchsendet, um ein Image nur anzufordern, wenn es seit dem letzten Vorgang aktualisiert wurde.
Eine Liste bekannter REST API-Fehlercodes, die von den Speicherdiensten zurückgegeben werden, finden Sie auf der Seite Bekannte REST API-Fehlercodes.
Weitere Informationen
- Überwachen von Azure Blob Storage
- Überwachen von Azure Files
- Überwachen von Azure Queue Storage
- Überwachen von Azure-Tabellenspeicher
- Behandeln von Leistungsproblemen
- Behandeln von Verfügbarkeitsproblemen
- Überwachung, Diagnose und Problembehandlung in 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.