Felsöka klientprogramfel i Azure Storage-konton

Den här artikeln hjälper dig att undersöka klientprogramfel med hjälp av mått, loggar på klientsidan och resursloggar i Azure Monitor.

Diagnostisera fel

Användare av ditt program kan meddela dig om fel som rapporterats av klientprogrammet. Azure Monitor registrerar även antalet olika svarstyper (ResponseType-dimensioner ) från dina lagringstjänster, till exempel NetworkError, ClientTimeoutError eller AuthorizationError. Även om Azure Monitor endast registrerar antal olika feltyper kan du få mer information om enskilda begäranden genom att undersöka loggar på serversidan, klientsidan och nätverket. Vanligtvis ger HTTP-statuskoden som returneras av lagringstjänsten en indikation på varför begäran misslyckades.

Följande resurser är användbara för att förstå lagringsrelaterad status och felkoder:

• Vanliga felkoder för REST API
• Felkoder för Blob Service
• Kötjänstfelkoder
• Felkoder för Table Service
• Felkoder för Filtjänst

Klienten tar emot HTTP 403-meddelanden (förbjudet)

Om klientprogrammet genererar HTTP 403-fel (förbjudet) är en trolig orsak att klienten använder en sas (signatur för delad åtkomst) som upphört att gälla när den skickar en lagringsbegäran (även om andra möjliga orsaker är klocksnedställning, ogiltiga nycklar och tomma rubriker).

Med lagringsklientbiblioteket för .NET kan du samla in loggdata på klientsidan som relaterar till lagringsåtgärder som utförs av ditt program. Mer information finns i Loggning på klientsidan med .NET Storage-klientbiblioteket.

I följande tabell visas ett exempel från loggen på klientsidan som genereras av lagringsklientbiblioteket som illustrerar det här problemet:

I det här scenariot bör du undersöka varför SAS-token upphör att gälla innan klienten skickar token till servern:

• Normalt bör du inte ange en starttid när du skapar en SAS för en klient som ska användas omedelbart. Om det finns små klockskillnader mellan värden som genererar SAS med den aktuella tiden och lagringstjänsten är det möjligt för lagringstjänsten att ta emot en SAS som ännu inte är giltig.

• Ange inte en mycket kort förfallotid för en SAS. Återigen kan små klockskillnader mellan värden som genererar SAS och lagringstjänsten leda till att en SAS upphör att gälla tidigare än förväntat.

• Matchar versionsparametern i SAS-nyckeln (till exempel sv=2015-04-05) den version av lagringsklientbiblioteket som du använder? Vi rekommenderar att du alltid använder den senaste versionen av lagringsklientbiblioteket.

• Om du återskapar dina lagringsåtkomstnycklar kan eventuella befintliga SAS-token ogiltigförklaras. Det här problemet kan uppstå om du genererar SAS-token med lång förfallotid för klientprogram att cachelagras.

Om du använder Storage-klientbiblioteket för att generera SAS-token är det enkelt att skapa en giltig token. Men om du använder REST-API:et för lagring och skapar SAS-token för hand kan du läsa Delegera åtkomst med en signatur för delad åtkomst.

Klienten tar emot HTTP 404-meddelanden (hittades inte)

Om klientprogrammet tar emot ett HTTP 404-meddelande (hittades inte) från servern innebär det att objektet som klienten försökte använda (till exempel en entitet, tabell, blob, container eller kö) inte finns i lagringstjänsten. Det finns ett antal möjliga orsaker till detta, till exempel:

• Klienten eller en annan process har tidigare tagit bort objektet.

• Ett auktoriseringsproblem med signatur för delad åtkomst (SAS).

• JavaScript-kod på klientsidan har inte behörighet att komma åt objektet.

• Nätverksfel.

Klienten eller en annan process har tidigare tagit bort objektet

I scenarier där klienten försöker läsa, uppdatera eller ta bort data i en lagringstjänst är det enkelt att i lagringsresursloggarna identifiera en tidigare åtgärd som tog bort objektet i fråga från lagringstjänsten. Loggdata visar ofta att en annan användare eller process har tagit bort objektet. Azure Monitor-loggarna (på serversidan) visas när en klient har tagit bort ett objekt.

I scenariot där en klient försöker infoga ett objekt är det kanske inte omedelbart uppenbart varför detta resulterar i ett HTTP 404-svar (hittades inte), eftersom klienten skapar ett nytt objekt. Men om klienten skapar en blob måste den kunna hitta blobcontainern. Om klienten skapar ett meddelande måste den kunna hitta en kö. Och om klienten lägger till en rad måste den kunna hitta tabellen.

Du kan använda loggen på klientsidan från Storage-klientbiblioteket för att bättre förstå när klienten skickar specifika begäranden till lagringstjänsten.

Följande logg på klientsidan som genereras av storage-klientbiblioteket illustrerar problemet när klienten inte kan hitta containern för den blob som den skapar. Den här loggen innehåller information om följande lagringsåtgärder:

Loggposter:

I det här exemplet visar loggen att klienten mellanlagrar begäranden från CreateIfNotExists metoden (begärande-ID e2d06d78...) med begäranden från UploadFromStream metoden (de8b1c3c-...). Den här interfolieringen sker eftersom klientprogrammet anropar dessa metoder asynkront. Ändra den asynkrona koden i klienten så att den skapar containern innan du försöker ladda upp data till en blob i containern. Vi rekommenderar att du skapar alla containrar i förväg.

Auktoriseringsproblem med signatur för delad åtkomst (SAS)

Om klientprogrammet försöker använda en SAS-nyckel som inte innehåller nödvändiga behörigheter för åtgärden returnerar lagringstjänsten ett HTTP 404-meddelande (hittades inte) till klienten. I Azure Monitor-mått ser du samtidigt även en AuthorizationError för ResponseType-dimensionen .

Undersök varför klientprogrammet försöker utföra en åtgärd som det inte har beviljats behörighet för.

JavaScript-kod på klientsidan har inte behörighet att komma åt objektet

Om du använder en JavaScript-klient och lagringstjänsten returnerar HTTP 404-meddelanden kontrollerar du följande JavaScript-fel i webbläsaren:

SEC7120: Ursprunget http://localhost:56309 hittades inte i rubriken Access-Control-Allow-Origin.
SCRIPT7002: XMLHttpRequest: Nätverksfel 0x80070005, åtkomst nekas.

Dessa fel uppstår eftersom webbläsaren implementerar samma säkerhetsbegränsning för ursprungsprincipen som förhindrar att en webbsida anropar ett API i en annan domän än den domän som sidan kommer från.

Om du vill kringgå JavaScript-problemet kan du konfigurera resursdelning för korsande ursprung (CORS) för den lagringstjänst som klienten har åtkomst till. Mer information finns i Stöd för resursdelning för korsande ursprung (CORS) för Azure Storage-tjänster.

Följande kodexempel visar hur du konfigurerar blobtjänsten så att JavaScript körs i Contoso-domänen för åtkomst till en blob i bloblagringstjänsten:

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

Nätverksfel

I vissa fall kan förlorade nätverkspaket leda till att lagringstjänsten returnerar HTTP 404-meddelanden till klienten. När klientprogrammet till exempel tar bort en entitet från tabelltjänsten ser du att klienten genererar ett lagringsfel som rapporterar statusmeddelandet "HTTP 404 (hittades inte)" från tabelltjänsten. När du undersöker tabellen i tabelllagringstjänsten ser du att tjänsten har tagit bort entiteten på begäran.

Undantagsinformationen i klienten inkluderar det begärande-ID (7e84f12d...) som tilldelats av tabelltjänsten för begäran: du kan använda den här informationen för att hitta information om begäran i lagringsresursloggarna i Azure Monitor genom att söka i Fält som beskriver hur åtgärden autentiserades för loggposter. Du kan också använda måtten för att identifiera när sådana här fel inträffar och sedan söka i loggfilerna baserat på den tid då måtten registrerade det här felet. Den här loggposten visar att borttagningen misslyckades med statusmeddelandet "HTTP (404) Client Other Error". Samma loggpost innehåller även det begärande-ID som genereras av klienten i client-request-id kolumnen (813ea74f...).

Loggen på serversidan innehåller också en annan post med samma client-request-id värde (813ea74f...) för en lyckad borttagningsåtgärd för samma entitet och från samma klient. Den här lyckade borttagningsåtgärden ägde rum strax före den misslyckade borttagningsbegäran.

Den troligaste orsaken till det här scenariot är att klienten skickade en borttagningsbegäran för entiteten till tabelltjänsten, som lyckades men inte fick någon bekräftelse från servern (kanske på grund av ett tillfälligt nätverksproblem). Klienten har sedan automatiskt gjort ett nytt försök med åtgärden (med samma client-request-id) och det här återförsöket misslyckades eftersom entiteten redan hade tagits bort.

Om det här problemet uppstår ofta bör du undersöka varför klienten inte kan ta emot bekräftelser från tabelltjänsten. Om problemet är tillfälligt bör du fånga felet "HTTP (404) Hittades inte" och logga det i klienten, men tillåta att klienten fortsätter.

Klienten tar emot HTTP 409-meddelanden (konflikt)

När en klient tar bort blobcontainrar, tabeller eller köer finns det en kort period innan namnet blir tillgängligt igen. Om koden i klientprogrammet tas bort och sedan omedelbart återskapar en blobcontainer med samma namn misslyckas CreateIfNotExists metoden till slut med FELET HTTP 409 (konflikt).

Klientprogrammet bör använda unika containernamn när det skapar nya containrar om mönstret för borttagning/återskapande är vanligt.

Mått visar att låga PercentSuccess- eller analysloggposter har åtgärder med transaktionsstatusen ClientOtherErrors

En ResponseType-dimension som är lika med värdet Lyckades samlar in procentandelen åtgärder som lyckades baserat på deras HTTP-statuskod. Åtgärder med statuskoderna 2XX räknas som lyckade, medan åtgärder med statuskoder i intervallen 3XX, 4XX och 5XX räknas som misslyckade och sänker måttvärdet Lyckades. I lagringsresursloggar registreras dessa åtgärder med transaktionsstatusen ClientOtherError.

Dessa åtgärder har slutförts och påverkar därför inte andra mått, till exempel tillgänglighet. Några exempel på åtgärder som körs men som kan resultera i misslyckade HTTP-statuskoder är:

• ResourceNotFound (hittades inte 404), till exempel från en GET-begäran till en blob som inte finns.
• ResourceAlreadyExists (konflikt 409), till exempel från en CreateIfNotExist åtgärd där resursen redan finns.
• ConditionNotMet (inte ändrad 304), till exempel från en villkorsstyrd åtgärd, till exempel när en klient skickar ett ETag värde och ett HTTP-huvud If-None-Match för att begära en avbildning endast om den har uppdaterats sedan den senaste åtgärden.

Du hittar en lista över vanliga REST API-felkoder som lagringstjänsterna returnerar på sidan Vanliga REST API-felkoder.

Se även

• Övervaka Azure Blob Storage
• Övervaka Azure Files
• Övervaka Azure Queue Storage
• Övervaka Azure Table Storage
• Felsöka prestandaproblem
• Felsöka tillgänglighetsproblem
• Övervaka, diagnostisera och felsöka Azure Storage

Kontakta oss för att få hjälp

Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.