Felsöka tillgänglighetsproblem i Azure Storage-konton

Den här artikeln hjälper dig att undersöka ändringar i tillgängligheten (till exempel antalet misslyckade begäranden). Dessa ändringar i tillgängligheten kan ofta identifieras genom övervakning av lagringsmått i Azure Monitor. Allmän information om hur du använder mått och loggar i Azure Monitor finns i följande artiklar:

• Övervaka Azure Blob Storage
• Övervaka Azure Files
• Övervaka Azure Queue Storage
• Övervaka Azure Table Storage

Övervaka tillgänglighet

Du bör övervaka tillgängligheten för lagringstjänsterna i ditt lagringskonto genom att övervaka värdet för måttet Tillgänglighet . Tillgänglighetsmåttet innehåller ett procentvärde. Den beräknas genom att ta det totala värdet för fakturerbara begäranden och dividera det med antalet tillämpliga begäranden, inklusive de begäranden som orsakade oväntade fel.

Alla värden som är mindre än 100 % anger att vissa lagringsbegäranden misslyckas. Du kan se varför de misslyckas genom att undersöka ResponseType-dimensionen för feltyper som ServerTimeoutError. Du bör förvänta dig att tillgängligheten tillfälligt understiger 100 % av orsaker som tillfälliga tidsgränser för servern medan tjänsten flyttar partitioner till bättre belastningsutjämningsbegäranden. Logiken för återförsök i klientprogrammet bör hantera sådana tillfälliga villkor. Tillgänglighetsmåttet kommer endast att vara tillgängligt för tidsperioder då transaktioner också sker på kontot.

Du kan använda funktioner i Azure Monitor för att varna dig om tillgängligheten för en tjänst understiger ett tröskelvärde som du anger.

Mått visar en ökning av begränsningsfel

Begränsningsfel uppstår om du överskrider skalbarhetsmålen för en lagringstjänst. Lagringstjänsten begränsar för att säkerställa att ingen enskild klient eller klient kan använda tjänsten på bekostnad av andra. Mer information finns i Skalbarhets- och prestandamål för standardlagringskonton för information om skalbarhetsmål för lagringskonton och prestandamål för partitioner i lagringskonton.

Om värdet ClientThrottlingError eller ServerBusyError för ResponseType-dimensionen visar en ökning av procentandelen begäranden som misslyckas med ett begränsningsfel, måste du undersöka något av två scenarier:

• Tillfällig ökning i PercentThrottlingError
• Permanent ökning av PercentThrottlingError-fel

En ökning av begränsningsfel sker ofta samtidigt som antalet lagringsbegäranden ökar eller när du först läser in testningen av programmet. Detta kan också visa sig i klienten som "503 Server Upptagen" eller "500 Åtgärd timeout" HTTP-statusmeddelanden från lagringsåtgärder.

Tillfällig ökning av begränsningsfel

Om du ser toppar i begränsningsfel som sammanfaller med perioder med hög aktivitet för programmet implementerar du en exponentiell (inte linjär) back-off-strategi för återförsök i klienten. Back-off-återförsök minskar den omedelbara belastningen på partitionen och hjälper ditt program att jämna ut toppar i trafiken. Mer information om hur du implementerar återförsöksprinciper med hjälp av lagringsklientbiblioteket finns i egenskapen RetryOptions.MaxRetries .

Permanent ökning av begränsningsfel

Om du ser ett konsekvent högt värde för begränsningsfel efter en permanent ökning av dina transaktionsvolymer eller när du utför dina första belastningstester i ditt program, måste du utvärdera hur ditt program använder lagringspartitioner och om det närmar sig skalbarhetsmålen för ett lagringskonto. Om du till exempel ser begränsningsfel i en kö (som räknas som en enda partition) kan du överväga att använda ytterligare köer för att sprida transaktionerna över flera partitioner. Om du ser begränsningsfel i en tabell kan du överväga att använda ett annat partitioneringsschema för att sprida dina transaktioner över flera partitioner med hjälp av ett bredare intervall med partitionsnyckelvärden. En vanlig orsak till det här problemet är prepend/append anti-pattern, där du väljer datumet som partitionsnyckel, och sedan skrivs alla data på en viss dag till en partition (under belastning kan detta resultera i en flaskhals för skrivning). Överväg en annan partitioneringsdesign eller utvärdera om det kan vara en bättre lösning att använda bloblagring. Kontrollera också om begränsningen sker på grund av toppar i trafiken och undersöka sätt att jämna ut mönstret för begäranden.

Om du distribuerar dina transaktioner över flera partitioner måste du fortfarande vara medveten om de skalbarhetsgränser som angetts för lagringskontot. Om du till exempel använde 10 köer, där var och en bearbetar högst 2 000 1 KB-meddelanden per sekund, kommer du att ha den totala gränsen på 20 000 meddelanden per sekund för lagringskontot. Om du behöver bearbeta fler än 20 000 entiteter per sekund bör du överväga att använda flera lagringskonton. Tänk också på att storleken på dina begäranden och entiteter påverkar när lagringstjänsten begränsar dina klienter. Om du har större begäranden och entiteter kan du begränsas tidigare.

Ineffektiv frågedesign kan också leda till att du når skalbarhetsgränserna för tabellpartitioner. Till exempel måste en fråga med ett filter som bara väljer en procent av entiteterna i en partition, men som genomsöker alla entiteter i en partition komma åt varje entitet. Varje entitetsläsning räknas mot det totala antalet transaktioner i partitionen. Därför kan du enkelt nå skalbarhetsmålen.

Mått visar en ökning av tidsgränsfel

Tidsgränsfel uppstår när ResponseType-dimensionen är lika med ServerTimeoutError eller ClientTimeout.

Dina mått visar en ökning av tidsgränsfel för någon av dina lagringstjänster. Samtidigt får klienten http-statusmeddelanden med http-statusen "500 åtgärdstimeout" från lagringsåtgärder.

Tidsgränsen för servern (ServerTimeOutError) orsakas av ett fel på servern. Tidsgränsen för klienten (ClientTimeout) inträffar eftersom en åtgärd på servern har överskridit tidsgränsen som angetts av klienten. En klient som använder lagringsklientbiblioteket kan till exempel ange en tidsgräns för en åtgärd.

Tidsgränser för servern indikerar ett problem med lagringstjänsten som kräver ytterligare undersökning. Du kan använda mått för att se om du når skalbarhetsgränserna för tjänsten och för att identifiera eventuella trafiktoppar som kan orsaka det här problemet. Om problemet är tillfälligt kan det bero på belastningsutjämningsaktiviteten i tjänsten. Om problemet är beständigt och inte orsakas av att ditt program når tjänstens skalbarhetsgränser bör du skapa ett supportproblem. För tidsgränser för klienten måste du bestämma om tidsgränsen är inställd på ett lämpligt värde i klienten och antingen ändra det timeout-värde som angetts i klienten eller undersöka hur du kan förbättra prestandan för åtgärderna i lagringstjänsten, till exempel genom att optimera dina tabellfrågor eller minska storleken på dina meddelanden.

Mått visar en ökning av nätverksfel

Nätverksfel uppstår när ResponseType-dimensionen är lika med NetworkError. Dessa inträffar när en lagringstjänst identifierar ett nätverksfel när klienten gör en lagringsbegäran.

Den vanligaste orsaken till det här felet är att en klient kopplar från innan en timeout upphör att gälla i lagringstjänsten. Undersök koden i klienten för att förstå varför och när klienten kopplas från lagringstjänsten. Du kan också använda verktyg för nätverksanalys från tredje part för att undersöka problem med nätverksanslutningen från klienten.

Se även

• Felsöka klientprogramfel
• Felsöka prestandaproblem
• Övervaka, diagnostisera och felsöka Azure Storage

Kontakta oss om du behöver hjälp

Om du har frågor eller behöver hjälp skapar du en supportbegäran eller frågar Azure Community-support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.