Fouten in clienttoepassingen in Azure-opslagaccounts oplossen
Dit artikel helpt u bij het onderzoeken van fouten in clienttoepassingen 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 het aantal verschillende antwoordtypen (ResponseType-dimensies) van uw opslagservices, zoals NetworkError, ClientTimeoutError of AuthorizationError. Azure Monitor registreert alleen het aantal verschillende fouttypen, maar u kunt meer details over afzonderlijke aanvragen verkrijgen door server-, client- en netwerklogboeken te onderzoeken. Normaal gesproken geeft de HTTP-statuscode die door de opslagservice wordt geretourneerd, een indicatie van waarom de aanvraag is mislukt.
Notitie
Houd er rekening mee dat u verwacht dat er af en toe fouten optreden. Bijvoorbeeld fouten als gevolg van tijdelijke netwerkomstandigheden of toepassingsfouten.
De volgende resources kunnen worden gebruikt voor een overzicht van status- en foutcodes in verband met de opslag:
- Veelvoorkomende REST API-foutcodes
- Blob Service-foutcodes
- Foutcodes voor wachtrijservice
- Foutcodes voor Table Service
- Foutcodes voor bestandsservice
De client ontvangt HTTP 403-meldingen (verboden)
Als de clienttoepassing een HTTP 403-fout (verboden) weergeeft, is een vermoedelijke oorzaak dat de client gebruikmaakt van een verlopen Shared Access Signature (SAS) bij het verzenden van een opslagaanvraag (hoewel andere mogelijke oorzaken een tijdverschil, ongeldige sleutels of lege headers kunnen zijn).
Met de Storage-clientbibliotheek voor .NET kunt u logboekgegevens aan de clientzijde verzamelen die betrekking hebben op opslagbewerkingen die door uw toepassing worden uitgevoerd. Zie Logboekregistratie op de client inschakelen met de .NET-opslagclientbibliotheek voor meer informatie.
In de volgende tabel ziet u een voorbeeld uit het logboek aan de clientzijde dat is gegenereerd door de Opslagclientbibliotheek waarin dit probleem wordt geïllustreerd:
Bron | Uitgebreidheid | Uitgebreidheid | Clientaanvraag-id | Bewerkingstekst |
---|---|---|---|---|
Microsoft.Azure.Storage | Gegevens | 3 | 85d077ab-... | Starting operation with location Primary per location mode PrimaryOnly. |
Microsoft.Azure.Storage | Gegevens | 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 | Gegevens | 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 | Gegevens | 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 | Gegevens | 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 | Gegevens | 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 moet worden gebruikt. Als er kleine klokverschillen zijn tussen de host die de SAS genereert met behulp van de huidige tijd en de opslagservice, is het mogelijk dat de opslagservice een SAS ontvangt die nog niet geldig is.
Stel geen zeer korte verlooptijd in voor een SAS. Kleine tijdverschillen tussen de host die de SAS genereert en de opslagservice kunnen er ook toe 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 eventuele SAS-tokens ongeldig worden. Dit probleem doet zich voor als u SAS-tokens genereert met een lange verlooptijd voor clienttoepassingen die in de cache worden opgeslagen.
Als u de Storage-clientbibliotheek 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 samenwerkt, raadpleegt u Het delegeren van Access met een Shared Access Signature.
De client ontvangt HTTP 404-meldingen (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. Hiervoor zijn een aantal mogelijke redenen, bijvoorbeeld:
Het object is eerder door de client of een ander proces verwijderd.
Een sas-autorisatieprobleem (Shared Access Signature).
De JavaScript-code aan de clientzijde heeft geen toestemming voor toegang tot het object.
Netwerkfout.
Het object is eerder door de client of een ander proces 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 opslagresource een vorige bewerking te identificeren waarmee het betreffende object uit de opslagservice is verwijderd. Vaak blijkt uit de logboekgegevens dat een andere gebruiker of 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 probeert een object in te voegen, is het mogelijk niet direct duidelijk waarom dit resulteert in een HTTP 404-antwoord (niet gevonden), gezien het feit dat 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 het 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.
Het volgende logboek aan de clientzijde dat door de Opslagclientbibliotheek wordt gegenereerd, illustreert het probleem wanneer de client de container voor de blob die wordt gemaakt, niet kan vinden. Dit logboek bevat details van de volgende opslagbewerkingen:
Aanvraag-id | Operation |
---|---|
07b26a5d-... | DeleteIfExists methode om de blobcontainer te verwijderen. Deze bewerking bevat een HEAD-aanvraag om te controleren of de container bestaat. |
e2d06d78... | CreateIfNotExists methode voor het maken van de blobcontainer. Deze bewerking bevat een HEAD aanvraag die controleert op het bestaan van de container. Het HEAD retourneert een 404-bericht, maar gaat door. |
de8b1c3c-... | UploadFromStream methode voor het maken van de blob. 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 = "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 dit voorbeeld ziet u in het logboek dat de client aanvragen uit de CreateIfNotExists
methode (aanvraag-id e2d06d78...) met de aanvragen van de UploadFromStream
methode (de8b1c3c-...) interleaving uitvoert. 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 probeert gegevens te uploaden naar een blob in die container. In het ideale geval moet u al uw containers vooraf maken.
Een probleem met de verificatie van een SAS (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 deze geen machtigingen heeft gekregen.
JavaScript-code aan de clientzijde heeft geen 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, wordt de toegang geweigerd.
Notitie
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 problemen met JavaScript aan de clientzijde wilt oplossen.
Deze fouten treden op omdat de webbrowser dezelfde beveiligingsbeperking voor 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 opent. Zie CorS-ondersteuning (Cross-Origin Resource Sharing) voor Azure Storage Services voor meer informatie.
In het volgende codevoorbeeld ziet u hoe u uw blobservice configureert om JavaScript in het Contoso-domein toegang te geven tot een blob in uw blobopslagservice:
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 retourneert naar de client. Wanneer uw clienttoepassing bijvoorbeeld een entiteit uit de tabelservice verwijdert, ziet u dat de client een opslaguitzondering genereert die een http 404-statusbericht (niet gevonden) van de tabelservice rapporteert. 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 bevatten de aanvraag-id (7e84f12d...) die is toegewezen door de tabelservice voor de aanvraag: u kunt deze informatie gebruiken om de aanvraaggegevens te vinden in de opslagresourcelogboeken in Azure Monitor door te zoeken in Velden waarin wordt beschreven hoe de bewerking is geverifieerd van logboekvermeldingen. U kunt ook de metrische gegevens gebruiken om te bepalen wanneer fouten zoals deze optreden en vervolgens de logboekbestanden doorzoeken op basis van het tijdstip waarop de metrische gegevens deze fout hebben vastgelegd. Deze logboekvermelding laat zien dat het verwijderen is mislukt met het statusbericht HTTP (404) Client Other Error. Dezelfde logboekvermelding bevat ook de aanvraag-id die is gegenereerd door de client 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 verwijderbewerking voor dezelfde entiteit en van dezelfde client. Deze geslaagde verwijderingsbewerking vond kort voor de mislukte verwijderingsaanvraag plaats.
De meest waarschijnlijke oorzaak van dit scenario is dat de client een verwijderaanvraag 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 dezelfde client-request-id
bewerking) en deze nieuwe poging is mislukt omdat de entiteit al is verwijderd.
Als dit probleem vaak 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 onderschekken en aanmelden bij de client, maar de client toestaan om door te gaan.
De client ontvangt HTTP 409-meldingen (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 maakt met dezelfde naam, mislukt de CreateIfNotExists
methode uiteindelijk met de HTTP 409-fout (Conflict).
De clienttoepassing moet een unieke containernaam gebruiken wanneer er een nieuwe container wordt gemaakt als het patroon voor verwijderen/opnieuw maken algemeen is.
Metrische gegevens tonen lage percentsuccess of analyselogboekvermeldingen hebben bewerkingen met de transactiestatus van ClientOtherErrors
Een ResponseType-dimensie die gelijk is aan een waarde van Geslaagd , legt het percentage bewerkingen vast dat is geslaagd op basis van hun HTTP-statuscode. Bewerkingen met statuscodes van 2XX tellen als geslaagd, terwijl bewerkingen met statuscodes in 3XX-, 4XX- en 5XX-bereiken als mislukt worden geteld en de metrische waarde voor Geslaagd verlagen. In opslagresourcelogboeken worden deze bewerkingen vastgelegd met een transactiestatus van ClientOtherError.
Deze bewerkingen zijn voltooid en hebben dus geen invloed op andere metrische gegevens, zoals beschikbaarheid. Enkele voorbeelden van bewerkingen die succesvol 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 vanuit een
CreateIfNotExist
bewerking waarin de resource al bestaat. - ConditionNotMet (Niet gewijzigd 304), bijvoorbeeld vanaf een voorwaardelijke bewerking, zoals wanneer een client een
ETag
waarde en een HTTP-headerIf-None-Match
verzendt om een afbeelding alleen aan te vragen als deze sinds de laatste bewerking is bijgewerkt.
U vindt een lijst met veelvoorkomende REST API-foutcodes die door de opslagservices worden geretourneerd op de pagina Algemene REST API-foutcodes.
Zie ook
- Bewaking van Azure Blob Storage
- Bewaking van Azure Files
- Azure Queue Storage bewaken
- Azure Table Storage bewaken
- Prestatieproblemen oplossen
- Beschikbaarheidsproblemen oplossen
- Uw Azure Storage bewaken, diagnosticeren en problemen oplossen
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 Azure-feedbackcommunity.