Share via

Problemen met clienttoepassingsfouten in Azure-opslagaccounts oplossen

  • Artikel

Dit artikel helpt u bij het onderzoeken van clienttoepassingsfouten met behulp van metrische gegevens, logboeken aan de clientzijde en resourcelogboeken in Azure Monitor.

Fouten diagnosticeren

Gebruikers van uw toepassing kunnen u op de hoogte stellen van fouten die zijn gerapporteerd door de clienttoepassing. Azure Monitor registreert ook aantallen van verschillende antwoordtypen (ResponseType-dimensies ) van uw opslagservices, zoals NetworkError, ClientTimeoutError of AuthorizationError. Hoewel Azure Monitor alleen aantallen verschillende fouttypen registreert, kunt u meer details over afzonderlijke aanvragen verkrijgen door logboeken aan de serverzijde, clientzijde en netwerklogboeken te onderzoeken. Normaal gesproken geeft de HTTP-statuscode die wordt geretourneerd door de opslagservice een indicatie van waarom de aanvraag is mislukt.

Opmerking

Houd er rekening mee dat u af en toe fouten moet zien. Bijvoorbeeld fouten als gevolg van tijdelijke netwerkomstandigheden of toepassingsfouten.

De volgende resources zijn handig voor meer informatie over de status en foutcodes van opslag:

De client ontvangt HTTP 403-berichten (verboden)

Als uw clienttoepassing HTTP 403-fouten (verboden) genereert, is een waarschijnlijke oorzaak dat de client een verlopen Shared Access Signature (SAS) gebruikt wanneer deze een opslagaanvraag verzendt (hoewel andere mogelijke oorzaken zijn: klokscheefheid, ongeldige sleutels en lege headers).

Met de Opslagclientbibliotheek voor .NET kunt u logboekgegevens aan de clientzijde verzamelen die betrekking hebben op opslagbewerkingen die door uw toepassing worden uitgevoerd. Zie Logboekregistratie aan clientzijde met de .NET Storage-clientbibliotheek voor meer informatie.

In de volgende tabel ziet u een voorbeeld van het logboek aan de clientzijde dat is gegenereerd door de Storage-clientbibliotheek, waarin dit probleem wordt geïllustreerd:

Source Uitgebreidheid Uitgebreidheid Clientaanvraag-id Bewerkingstekst
Microsoft.Azure.Storage Informatie 3 85d077ab-... Starting operation with location Primary per location mode PrimaryOnly.
Microsoft.Azure.Storage Informatie 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 Informatie 3 85d077ab -... Waiting for response.
Microsoft.Azure.Storage Waarschuwing 2 85d077ab -... Exception thrown while waiting for response: The remote server returned an error: (403) Forbidden.
Microsoft.Azure.Storage Informatie 3 85d077ab -... Response received. Status code = 403, Request ID = <Request ID>, Content-MD5 = , ETag = .
Microsoft.Azure.Storage Waarschuwing 2 85d077ab -... Exception thrown during the operation: The remote server returned an error: (403) Forbidden..
Microsoft.Azure.Storage Informatie 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 Informatie 3 85d077ab -... The next location has been set to Primary, based on the location mode.
Microsoft.Azure.Storage Error 1 85d077ab -... Retry policy did not allow for a retry. Failing with The remote server returned an error: (403) Forbidden.

In dit scenario moet u onderzoeken waarom het SAS-token verloopt voordat de client het token naar de server verzendt:

  • Normaal gesproken moet u geen begintijd instellen wanneer u een SAS maakt voor een client die onmiddellijk kan worden gebruikt. Als er kleine klokverschillen zijn tussen de host die de SAS genereert met behulp van de huidige tijd en de opslagservice, kan de opslagservice een SAS ontvangen die nog niet geldig is.

  • Stel geen zeer korte verlooptijd in voor een SAS. Nogmaals, kleine klokverschillen tussen de host die de SAS genereert en de opslagservice kunnen ertoe leiden dat een SAS eerder verloopt dan verwacht.

  • Komt de versieparameter in de SAS-sleutel (bijvoorbeeld sv=2015-04-05) overeen met de versie van de opslagclientbibliotheek die u gebruikt? U wordt aangeraden altijd de nieuwste versie van de opslagclientbibliotheek te gebruiken.

  • Als u uw opslagtoegangssleutels opnieuw genereert, kunnen bestaande SAS-tokens ongeldig worden gemaakt. Dit probleem kan zich voordoen als u SAS-tokens genereert met een lange verlooptijd voor clienttoepassingen in de cache.

Als u de Opslagclientbibliotheek gebruikt om SAS-tokens te genereren, kunt u eenvoudig een geldig token maken. Als u echter de Storage REST API gebruikt en de SAS-tokens handmatig maakt, raadpleegt u Toegang delegeren met een Shared Access Signature.

De client ontvangt HTTP 404-berichten (niet gevonden)

Als de clienttoepassing een HTTP 404-bericht (niet gevonden) van de server ontvangt, betekent dit dat het object dat de client probeerde te gebruiken (zoals een entiteit, tabel, blob, container of wachtrij) niet bestaat in de opslagservice. Er zijn een aantal mogelijke redenen hiervoor, zoals:

  • De client of een ander proces heeft het object eerder verwijderd.

  • Een sas-autorisatieprobleem (Shared Access Signature).

  • JavaScript-code aan de clientzijde heeft geen machtiging voor toegang tot het object.

  • Netwerkfout.

De client of een ander proces heeft het object eerder verwijderd

In scenario's waarin de client probeert gegevens in een opslagservice te lezen, bij te werken of te verwijderen, is het gemakkelijk om in de logboeken van de opslagresource een eerdere bewerking te identificeren die het betreffende object uit de opslagservice heeft verwijderd. Vaak wordt in de logboekgegevens aangegeven dat een andere gebruiker of een ander proces het object heeft verwijderd. De Azure Monitor-logboeken (serverzijde) worden weergegeven wanneer een client een object heeft verwijderd.

In het scenario waarin een client een object probeert in te voegen, is het mogelijk niet direct duidelijk waarom dit resulteert in een HTTP 404-antwoord (niet gevonden), aangezien de client een nieuw object maakt. Als de client echter een blob maakt, moet deze de blobcontainer kunnen vinden. Als de client een bericht maakt, moet deze een wachtrij kunnen vinden. En als de client een rij toevoegt, moet deze de tabel kunnen vinden.

U kunt het logboek aan de clientzijde van de opslagclientbibliotheek gebruiken om beter te begrijpen wanneer de client specifieke aanvragen naar de opslagservice verzendt.

In het volgende logboek aan de clientzijde dat wordt gegenereerd door de opslagclientbibliotheek, wordt het probleem geïllustreerd wanneer de client de container voor de blob die wordt gemaakt, niet kan vinden. Dit logboek bevat details van de volgende opslagbewerkingen:

Aanvraag-ID Bewerking
07b26a5d-... DeleteIfExists om de blobcontainer te verwijderen. Deze bewerking omvat een HEAD-aanvraag om te controleren of de container bestaat.
e2d06d78... CreateIfNotExists om de blobcontainer te maken. Deze bewerking omvat een HEAD aanvraag waarmee wordt gecontroleerd op het bestaan van de container. De HEAD retourneert een 404-bericht, maar gaat door.
de8b1c3c-... UploadFromStream methode om de blob te maken. De PUT aanvraag mislukt met een 404-bericht

Logboekvermeldingen:

Aanvraag-ID Bewerkingstekst
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 = &quot;0x8D14D2DC63D059B&quot;.
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 dit voorbeeld ziet u in het logboek dat de client aanvragen van de CreateIfNotExists methode (aanvraag-id e2d06d78...) koppelt aan de aanvragen van de UploadFromStream methode (de8b1c3c-...). Deze interleaving treedt op omdat de clienttoepassing deze methoden asynchroon aanroept. Wijzig de asynchrone code in de client om ervoor te zorgen dat de container wordt gemaakt voordat u gegevens uploadt naar een blob in die container. In het ideale geval moet u al uw containers van tevoren maken.

Een probleem met sas-autorisatie (Shared Access Signature)

Als de clienttoepassing probeert een SAS-sleutel te gebruiken die niet de benodigde machtigingen voor de bewerking bevat, retourneert de opslagservice een HTTP 404-bericht (Niet gevonden) naar de client. Tegelijkertijd ziet u in metrische gegevens van Azure Monitor ook een AuthorizationError voor de dimensie ResponseType .

Onderzoek waarom uw clienttoepassing probeert een bewerking uit te voeren waarvoor geen machtigingen zijn verleend.

JavaScript-code aan de clientzijde heeft geen machtiging voor toegang tot het object

Als u een JavaScript-client gebruikt en de opslagservice HTTP 404-berichten retourneert, controleert u op de volgende JavaScript-fouten in de browser:

SEC7120: Oorsprong http://localhost:56309 niet gevonden in de header Access-Control-Allow-Origin.
SCRIPT7002: XMLHttpRequest: Netwerkfout 0x80070005, toegang wordt geweigerd.

Opmerking

U kunt de F12-ontwikkelhulpprogramma's in Internet Explorer gebruiken om de berichten te traceren die worden uitgewisseld tussen de browser en de opslagservice wanneer u JavaScript-problemen aan de clientzijde wilt oplossen.

Deze fouten treden op omdat de webbrowser dezelfde beveiligingsbeperking voor het oorsprongsbeleid implementeert die voorkomt dat een webpagina een API aanroept in een ander domein dan het domein waarvan de pagina afkomstig is.

Als u het JavaScript-probleem wilt omzeilen, kunt u CORS (Cross-Origin Resource Sharing) configureren voor de opslagservice die de client gebruikt. Zie Cross-Origin Resource Sharing (CORS)-ondersteuning voor Azure Storage Services voor meer informatie.

In het volgende codevoorbeeld ziet u hoe u uw blobservice configureert om JavaScript die wordt uitgevoerd in het Contoso-domein toegang te geven tot een blob in uw blob-opslagservice:

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);

Netwerkfout

In sommige gevallen kunnen verloren netwerkpakketten ertoe leiden dat de opslagservice HTTP 404-berichten naar de client retourneert. Wanneer uw clienttoepassing bijvoorbeeld een entiteit uit de tabelservice verwijdert, ziet u dat de client een opslaguitzondering genereert met het bericht 'HTTP 404 (Niet gevonden)' van de tabelservice. Wanneer u de tabel in de table storage-service onderzoekt, ziet u dat de service de entiteit heeft verwijderd zoals aangevraagd.

De uitzonderingsdetails in de client omvatten de aanvraag-id (7e84f12d...) die is toegewezen door de tabelservice voor de aanvraag: u kunt deze informatie gebruiken om de aanvraagdetails te vinden in de opslagresourcelogboeken in Azure Monitor door te zoeken in Velden die beschrijven hoe de bewerking is geverifieerd van logboekvermeldingen. U kunt de metrische gegevens ook gebruiken om te bepalen wanneer dergelijke fouten optreden en vervolgens de logboekbestanden doorzoeken op basis van het tijdstip waarop de metrische gegevens deze fout hebben vastgelegd. In dit logboek ziet u dat het verwijderen is mislukt met het statusbericht 'HTTP (404) Client Other Error'. Dezelfde logboekvermelding bevat ook de aanvraag-id die door de client is gegenereerd in de client-request-id kolom (813ea74f...).

Het logboek aan de serverzijde bevat ook een andere vermelding met dezelfde client-request-id waarde (813ea74f...) voor een geslaagde verwijderingsbewerking voor dezelfde entiteit en van dezelfde client. Deze geslaagde verwijderingsbewerking vond plaats kort voor de mislukte verwijderingsaanvraag.

De meest waarschijnlijke oorzaak van dit scenario is dat de client een verwijderingsaanvraag voor de entiteit heeft verzonden naar de tabelservice, die is geslaagd, maar geen bevestiging van de server heeft ontvangen (mogelijk vanwege een tijdelijk netwerkprobleem). De client heeft de bewerking vervolgens automatisch opnieuw geprobeerd (met behulp van dezelfde client-request-id), en deze nieuwe poging is mislukt omdat de entiteit al was verwijderd.

Als dit probleem regelmatig optreedt, moet u onderzoeken waarom de client geen bevestigingen van de tabelservice ontvangt. Als het probleem af en toe optreedt, moet u de fout 'HTTP (404) Niet gevonden' oversluiten en deze in de client registreren, maar de client toestaan om door te gaan.

De client ontvangt HTTP 409-berichten (conflict)

Wanneer een client blobcontainers, tabellen of wachtrijen verwijdert, is er een korte periode voordat de naam weer beschikbaar is. Als de code in uw clienttoepassing wordt verwijderd en vervolgens onmiddellijk een blobcontainer opnieuw wordt gemaakt met dezelfde naam, mislukt de CreateIfNotExists methode uiteindelijk met de HTTP 409-fout (conflict).

De clienttoepassing moet unieke containernamen gebruiken wanneer er nieuwe containers worden gemaakt als het patroon verwijderen/opnieuw maken gebruikelijk is.

Metrische gegevens tonen een laag percentageSuccess of analytische logboekvermeldingen hebben bewerkingen met de transactiestatus ClientOtherErrors

Een ResponseType-dimensie die gelijk is aan de waarde Geslaagd legt het percentage bewerkingen vast dat is geslaagd op basis van hun HTTP-statuscode. Bewerkingen met statuscodes van 2XX worden als geslaagd geteld, terwijl bewerkingen met statuscodes in 3XX-, 4XX- en 5XX-bereiken worden geteld als mislukt en de metrische waarde voor succes verlagen. In opslagresourcelogboeken worden deze bewerkingen vastgelegd met de transactiestatus ClientOtherError.

Deze bewerkingen zijn voltooid en hebben daarom geen invloed op andere metrische gegevens, zoals beschikbaarheid. Enkele voorbeelden van bewerkingen die met succes worden uitgevoerd, maar die kunnen leiden tot mislukte HTTP-statuscodes zijn:

  • ResourceNotFound (Niet gevonden 404), bijvoorbeeld van een GET-aanvraag naar een blob die niet bestaat.
  • ResourceAlreadyExists (Conflict 409), bijvoorbeeld van een CreateIfNotExist bewerking waarbij de resource al bestaat.
  • ConditionNotMet (Niet gewijzigd 304), bijvoorbeeld van een voorwaardelijke bewerking, zoals wanneer een client een ETag waarde en een HTTP-header If-None-Match verzendt om een afbeelding op te vragen, alleen als deze is bijgewerkt sinds de laatste bewerking.

U vindt een lijst met veelvoorkomende REST API-foutcodes die de opslagservices retourneren op de pagina Algemene REST API-foutcodes.

Zie ook

Contacteer ons voor hulp

Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Feedback-community van Azure.