Dela via

Övervaka, diagnostisera och felsöka Microsoft Azure Storage (klassisk)

  • Artikel

Den här guiden visar hur du använder funktioner som Azure Lagringsanalys, loggning på klientsidan i Azure Storage-klientbiblioteket och andra verktyg från tredje part för att identifiera, diagnostisera och felsöka Azure Storage-relaterade problem.

Diagram som visar informationsflödet mellan klientprogram och Azure Storage-tjänster.

Den här guiden är avsedd att läsas främst av utvecklare av onlinetjänster som använder Azure Storage Services och IT-proffs som ansvarar för att hantera sådana onlinetjänster. Målet med den här guiden är:

  • För att hjälpa dig att upprätthålla hälsotillståndet och prestandan för dina Azure Storage-konton.
  • För att ge dig de nödvändiga processerna och verktygen som hjälper dig att avgöra om ett problem eller problem i ett program är relaterat till Azure Storage.
  • För att ge dig användbar vägledning för att lösa problem som rör Azure Storage.

Kommentar

Den här artikeln baseras på användning av Lagringsanalys mått och loggar som kallas klassiska mått och loggar. Vi rekommenderar att du använder Azure Storage-mått och loggar i Azure Monitor i stället för Lagringsanalys loggar. Mer information finns i någon av följande artiklar:

Översikt

Det kan vara mer komplext att diagnostisera och felsöka problem i ett distribuerat program som finns i en molnmiljö än i traditionella miljöer. Program kan distribueras i en PaaS- eller IaaS-infrastruktur, lokalt, på en mobil enhet eller i någon kombination av dessa miljöer. Vanligtvis kan programmets nätverkstrafik passera offentliga och privata nätverk, och ditt program kan använda flera lagringstekniker, till exempel Microsoft Azure Storage-tabeller, blobbar, köer eller filer utöver andra datalager, till exempel relations- och dokumentdatabaser.

För att hantera sådana program korrekt bör du övervaka dem proaktivt och förstå hur du diagnostiserar och felsöker alla aspekter av dem och deras beroende tekniker. Som användare av Azure Storage-tjänster bör du kontinuerligt övervaka de Lagringstjänster som ditt program använder för oväntade ändringar i beteendet (till exempel långsammare svarstider än vanligt) och använda loggning för att samla in mer detaljerade data och analysera ett problem på djupet. Diagnostikinformationen som du får från övervakning och loggning hjälper dig att fastställa rotorsaken till problemet som programmet påträffade. Sedan kan du felsöka problemet och fastställa lämpliga steg för att åtgärda det. Azure Storage är en grundläggande Azure-tjänst och utgör en viktig del av de flesta lösningar som kunder distribuerar till Azure-infrastrukturen. Azure Storage innehåller funktioner för att förenkla övervakning, diagnostisering och felsökning av lagringsproblem i dina molnbaserade program.

Så här organiseras den här guiden

Avsnittet Övervaka din lagringstjänst beskriver hur du övervakar hälsotillståndet och prestandan för dina Azure Storage-tjänster med hjälp av Azure Lagringsanalys Metrics (Storage Metrics).

I avsnittet Diagnostisera lagringsproblem beskrivs hur du diagnostiserar problem med azure Lagringsanalys loggning (lagringsloggning). Den beskriver också hur du aktiverar loggning på klientsidan med hjälp av faciliteterna i ett av klientbiblioteken, till exempel lagringsklientbiblioteket för .NET eller Azure SDK för Java.

I avsnittet Slutpunkt till slutpunkt-spårning beskrivs hur du kan korrelera informationen i olika loggfiler och måttdata.

Avsnittet Felsökningsvägledning innehåller felsökningsvägledning för några av de vanliga lagringsrelaterade problem som du kan stöta på.

Avsnittet Tillägg innehåller information om hur du använder andra verktyg, till exempel Wireshark och Netmon för att analysera nätverkspaketdata, och Fiddler för att analysera HTTP/HTTPS-meddelanden.

Övervaka din lagringstjänst

Om du är bekant med Prestandaövervakning i Windows kan du betrakta Lagringsmått som en Azure Storage-motsvarighet till räknare för Windows Prestandaövervakare. I Storage Metrics hittar du en omfattande uppsättning mått (räknare i Windows Performance Monitor-terminologi), till exempel tjänsttillgänglighet, det totala antalet begäranden till tjänsten eller procentandelen lyckade begäranden till tjänsten. En fullständig lista över tillgängliga mått finns i Lagringsanalys Tabellschema för mått. Du kan ange om du vill att lagringstjänsten ska samla in och aggregera mått varje timme eller varje minut. Mer information om hur du aktiverar mått och övervakar dina lagringskonton finns i Aktivera lagringsmått och visa måttdata.

Du kan välja vilka mått per timme som du vill visa i Azure Portal och konfigurera regler som meddelar administratörer via e-post när ett mått per timme överskrider ett visst tröskelvärde. Mer information finns i Ta emot aviseringsaviseringar.

Vi rekommenderar att du granskar Azure Monitor for Storage (förhandsversion). Det är en funktion i Azure Monitor som erbjuder omfattande övervakning av dina Azure Storage-konton genom att leverera en enhetlig vy över prestanda, kapacitet och tillgänglighet för Dina Azure Storage-tjänster. Det kräver inte att du aktiverar eller konfigurerar något, och du kan omedelbart visa dessa mått från de fördefinierade interaktiva diagrammen och andra visualiseringar som ingår.

Lagringstjänsten gör sitt bästa för att samla in mått men kanske inte registrerar varje lagringsåtgärd.

I Azure Portal kan du visa mått som tillgänglighet, totalt antal begäranden och genomsnittliga svarstider för ett lagringskonto. En meddelanderegel har också konfigurerats för att varna en administratör om tillgängligheten sjunker under en viss nivå. När du visar dessa data är ett möjligt område för undersökning att andelen lyckade tabelltjänster understiger 100 % (mer information finns i Avsnittet Mått visar att låga PercentSuccess- eller analysloggposter har åtgärder med transaktionsstatus för avsnittet ClientOtherErrors ).

Du bör kontinuerligt övervaka dina Azure-program för att säkerställa att de är felfria och fungerar som förväntat genom att:

  • Genom att upprätta vissa baslinjemått för programmet kan du jämföra aktuella data och identifiera eventuella betydande ändringar i beteendet för Azure Storage och ditt program. Värdena för dina baslinjemått är i många fall programspecifika och du bör upprätta dem när du testar programmets prestanda.
  • Registrera minutmått och använda dem för att aktivt övervaka oväntade fel och avvikelser, till exempel toppar i antalet fel eller antalet begäranden.
  • Registrera mått per timme och använda dem för att övervaka genomsnittliga värden, till exempel genomsnittligt antal fel och begärandefrekvenser.
  • Undersöka potentiella problem med diagnostikverktyg som beskrivs senare i avsnittet Diagnostisera lagringsproblem .

Diagrammen i följande bild visar hur medelvärdet som inträffar för mått per timme kan dölja aktivitetstoppar. Måtten varje timme verkar visa en stadig frekvens av begäranden, medan minutmåtten visar de fluktuationer som verkligen äger rum.

Diagram som visar hur medelvärdet som inträffar för mått per timme kan dölja aktivitetstoppar.

Resten av det här avsnittet beskriver vilka mått du bör övervaka och varför.

Övervaka tjänstens hälsa

Du kan använda Azure Portal för att visa hälsotillståndet för lagringstjänsten (och andra Azure-tjänster) i alla Azure-regioner runt om i världen. Med övervakning kan du omedelbart se om ett problem utanför din kontroll påverkar lagringstjänsten i den region som du använder för ditt program.

Azure Portal kan också ge meddelanden om incidenter som påverkar de olika Azure-tjänsterna.

Kommentar

Den här informationen var tidigare tillgänglig, tillsammans med historiska data, på Instrumentpanelen för Azure-tjänsten. Mer information om Application Insights för Azure DevOps finns i Bilaga 5: Övervakning med Application Insights för Azure DevOps.

Övervakningskapacitet

Lagringsmått lagrar endast kapacitetsmått för blobtjänsten eftersom blobbar vanligtvis står för den största andelen lagrade data (i skrivande stund går det inte att använda lagringsmått för att övervaka kapaciteten för dina tabeller och köer). Du hittar dessa data i $MetricsCapacityBlob tabellen om du har aktiverat övervakning för Blob-tjänsten. Lagringsmått registrerar dessa data en gång per dag och du kan använda värdet RowKey för för att avgöra om raden innehåller en entitet som relaterar till användardata (värde data) eller analysdata (värde analytics). Varje lagrad entitet innehåller information om mängden lagringsutrymme som används (Capacity mätt i byte) och det aktuella antalet containrar (ContainerCount) och blobbar (ObjectCount) som används i lagringskontot. Mer information om de kapacitetsmått som lagras i tabellen finns i $MetricsCapacityBlob Lagringsanalys Tabellschema för mått.

Kommentar

Du bör övervaka dessa värden för en tidig varning om att du närmar dig kapacitetsgränserna för ditt lagringskonto. I Azure Portal kan du lägga till aviseringsregler för att meddela dig om den aggregerade lagringsanvändningen överskrider eller understiger de tröskelvärden som du anger.

Information om hur stora olika lagringsobjekt som blobar är finns i blogginlägget Understanding Azure Storage Billing – Bandwidth, Transactions, and Capacity (Förstå Azure Storage-fakturering – bandbredd, transaktioner och kapacitet).

Övervaka tillgänglighet

Du bör övervaka tillgängligheten för lagringstjänsterna i ditt lagringskonto genom att övervaka värdet i Availability kolumnen i tabellerna för mått per timme eller minut – $MetricsHourPrimaryTransactionsBlob, , $MetricsHourPrimaryTransactionsQueue$MetricsHourPrimaryTransactionsTable, $MetricsMinutePrimaryTransactionsBlob, $MetricsMinutePrimaryTransactionsTable, $MetricsMinutePrimaryTransactionsQueue, . $MetricsCapacityBlob Kolumnen Availability innehåller ett procentvärde som anger tillgängligheten för tjänsten eller DEN API-åtgärd som representeras av raden ( RowKey visar om raden innehåller mått för tjänsten som helhet eller för en specifik API-åtgärd).

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 de andra kolumnerna i måttdata som visar antalet begäranden med olika feltyper, till exempel ServerTimeoutError. Du bör förvänta dig att tillfälligt understiga Availability 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. I artikeln Lagringsanalys Loggade åtgärder och statusmeddelanden visas de transaktionstyper som lagringsmått innehåller i Availability beräkningen.

I Azure Portal kan du lägga till aviseringsregler för att meddela dig om Availability för en tjänst faller under ett tröskelvärde som du anger.

I avsnittet Felsökningsvägledning i den här guiden beskrivs några vanliga problem med lagringstjänsten som rör tillgänglighet.

Övervaka prestanda

Om du vill övervaka lagringstjänsternas prestanda kan du använda följande mått från tabellerna för mått per timme och minut.

  • Värdena i kolumnerna AverageE2ELatency och AverageServerLatency visar den genomsnittliga tid som lagringstjänsten eller API-åtgärdstypen tar för att bearbeta begäranden. AverageE2ELatency är ett mått på svarstid från slutpunkt till slutpunkt som inkluderar den tid det tar att läsa begäran och skicka svaret utöver den tid det tar att bearbeta begäran (omfattar därför nätverksfördröjning när begäran når lagringstjänsten). AverageServerLatency är ett mått på bara bearbetningstiden och utesluter därför alla nätverksfördröjningar relaterade till kommunikation med klienten. Se avsnittet Metrics show high AverageE2ELatency and low AverageServerLatency senare i den här guiden för en diskussion om varför det kan finnas en betydande skillnad mellan dessa två värden.
  • Värdena i kolumnerna TotalIngress och TotalEgress visar den totala mängden data, i byte, som kommer in till och går ut från din lagringstjänst eller via en specifik API-åtgärdstyp.
  • Värdena i TotalRequests kolumnen visar det totala antalet begäranden som lagringstjänsten för API-åtgärden tar emot. TotalRequests är det totala antalet begäranden som lagringstjänsten tar emot.

Vanligtvis övervakar du oväntade ändringar i något av dessa värden, eftersom detta indikerar att du har ett problem som kräver undersökning.

I Azure Portal kan du lägga till aviseringsregler för att meddela dig om några prestandamått för den här tjänsten faller under eller överskrider ett tröskelvärde som du anger.

I avsnittet Felsökningsvägledning i den här guiden beskrivs några vanliga problem med lagringstjänsten som rör prestanda.

Diagnostisera lagringsproblem

Det finns ett antal sätt att bli medveten om ett problem eller problem i ditt program, bland annat:

  • Ett stort fel som gör att programmet kraschar eller slutar fungera.
  • Betydande ändringar från baslinjevärden i de mått som du övervakar enligt beskrivningen i föregående avsnitt Övervaka din lagringstjänst.
  • Rapporter från användare av ditt program om att en viss åtgärd inte slutfördes som förväntat eller att någon funktion inte fungerar.
  • Fel som genereras i ditt program som visas i loggfiler eller via någon annan meddelandemetod.

Vanligtvis finns problem som rör Azure Storage-tjänster i en av fyra breda kategorier:

  • Ditt program har ett prestandaproblem, antingen rapporterat av dina användare eller avslöjats av ändringar i prestandamåtten.
  • Det finns ett problem med Azure Storage-infrastrukturen i en eller flera regioner.
  • Ditt program stöter på ett fel som antingen rapporteras av dina användare eller som visas av en ökning av ett av de felantalsmått som du övervakar.
  • Under utveckling och testning kan du använda den lokala lagringsemulatorn. du kan stöta på vissa problem som specifikt rör användningen av lagringsemulatorn.

I följande avsnitt beskrivs de steg du bör följa för att diagnostisera och felsöka problem i var och en av dessa fyra kategorier. Avsnittet Felsökningsvägledning senare i den här guiden innehåller mer information om några vanliga problem som du kan stöta på.

Tjänststatus problem

Tjänststatus problem ligger vanligtvis utanför din kontroll. Azure Portal innehåller information om pågående problem med Azure-tjänster, inklusive lagringstjänster. Om du valde Read-Access Geo-Redundant Storage när du skapade ditt lagringskonto kan ditt program tillfälligt växla till den skrivskyddade kopian på den sekundära platsen om dina data blir otillgängliga på den primära platsen. För att kunna läsa från den sekundära måste ditt program kunna växla mellan att använda de primära och sekundära lagringsplatserna och kunna arbeta i ett reducerat funktionsläge med skrivskyddade data. Med Azure Storage-klientbiblioteken kan du definiera en återförsöksprincip som kan läsa från sekundär lagring om en läsning från den primära lagringen misslyckas. Ditt program måste också vara medvetet om att data på den sekundära platsen så småningom är konsekventa. Mer information finns i blogginlägget om redundansalternativ för Azure Storage och Read Access Geo Redundant Storage.

Prestandaproblem

Upplevelsen av programprestanda kan vara högst subjektiv, särskilt från ett användarperspektiv. Därför är det viktigt att ha tillgång till jämförelsemått, så att du tydligt ser när det blir problem med prestandan. Många faktorer kan påverka prestandan för en Azure-lagringstjänst ur klientprogramperspektivet. Dessa faktorer kan fungera i lagringstjänsten, klienten eller nätverksinfrastrukturen. Därför är det viktigt att ha en strategi för att identifiera ursprunget till prestandaproblemet.

När du har identifierat den troliga platsen för orsaken till prestandaproblemet från måtten kan du sedan använda loggfilerna för att hitta detaljerad information för att diagnostisera och felsöka problemet ytterligare.

Avsnittet Felsökningsvägledning senare i den här guiden innehåller mer information om några vanliga prestandarelaterade problem som du kan stöta på.

Diagnostisera fel

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

Kommentar

Kom ihåg att du bör förvänta dig att se några tillfälliga fel: till exempel fel på grund av tillfälliga nätverksförhållanden eller programfel.

Följande resurser är användbara om du vill förstå lagringsrelaterade statusar och felkoder:

Problem med lagringsemulatorn

Azure SDK innehåller en lagringsemulator som du kan köra på en utvecklingsarbetsstation. Den här emulatorn simulerar det mesta av beteendet för Azure Storage-tjänsterna och är användbar under utveckling och testning, så att du kan köra program som använder Azure Storage-tjänster utan behov av en Azure-prenumeration och ett Azure-lagringskonto.

I avsnittet Felsökningsvägledning i den här guiden beskrivs några vanliga problem som påträffas med hjälp av lagringsemulatorn.

Verktyg för lagringsloggning

Lagringsloggning ger loggning på serversidan av lagringsbegäranden i ditt Azure-lagringskonto. Mer information om hur du aktiverar loggning på serversidan och åtkomst till loggdata finns i Aktivera lagringsloggning och åtkomst till loggdata.

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 artikeln om klientloggning med .NET Storage Client Library.

Kommentar

I vissa fall (till exempel SAS-auktoriseringsfel) kan en användare rapportera ett fel som du inte hittar några begärandedata för i lagringsloggarna på serversidan. Du kan använda loggningsfunktionerna i lagringsklientbiblioteket för att undersöka om orsaken till problemet finns på klienten eller använda verktyg för nätverksövervakning för att undersöka nätverket.

Använda verktyg för nätverksloggning

Du kan samla in trafiken mellan klienten och servern för att tillhandahålla detaljerad information om de data som klienten och servern utbyter och de underliggande nätverksvillkoren. Användbara verktyg för nätverksloggning är:

I många fall räcker loggdata från Lagringsloggning och Lagringsklientbiblioteket för att diagnostisera ett problem, men i vissa fall kan du behöva mer detaljerad information som dessa verktyg för nätverksloggning kan ge. Om du till exempel använder Fiddler för att visa HTTP- och HTTPS-meddelanden kan du visa sidhuvud- och nyttolastdata som skickas till och från lagringstjänsterna, vilket gör att du kan undersöka hur ett klientprogram försöker utföra lagringsåtgärder igen. Protokollanalysverktyg som Wireshark fungerar på paketnivå så att du kan visa TCP-data, vilket gör att du kan felsöka förlorade paket och anslutningsproblem.

Spårning från slutpunkt till slutpunkt

Spårning från slutpunkt till slutpunkt med en mängd olika loggfiler är en användbar teknik för att undersöka potentiella problem. Du kan använda datum-/tidsinformationen från dina måttdata för att ange var du ska börja leta i loggfilerna för detaljerad information som hjälper dig att felsöka problemet.

Korrelera loggdata

När du visar loggar från klientprogram, nätverksspårningar och lagringsloggning på serversidan är det viktigt att kunna korrelera begäranden mellan de olika loggfilerna. Loggfilerna innehåller ett antal olika fält som är användbara som korrelationsidentifierare. Klientbegärans-ID är det mest användbara fältet som ska användas för att korrelera poster i de olika loggarna. Ibland kan det dock vara användbart att använda antingen serverbegärans-ID eller tidsstämplar. Följande avsnitt innehåller mer information om dessa alternativ.

ID för klientförfrågan

Lagringsklientbiblioteket genererar automatiskt ett unikt klientbegärans-ID för varje begäran.

  • I loggen på klientsidan som lagringsklientbiblioteket skapar visas klientbegärans-ID:t i fältet för Client Request ID varje loggpost som är relaterad till begäran.
  • I en nätverksspårning, till exempel en som registrerats av Fiddler, visas klientbegärans-ID:t i begärandemeddelanden som x-ms-client-request-id HTTP-huvudvärde.
  • I loggen för lagringsloggning på serversidan visas klientbegärans-ID:t i kolumnen Klientbegärans-ID.

Kommentar

Det är möjligt för flera begäranden att dela samma klientbegärans-ID eftersom klienten kan tilldela det här värdet (även om lagringsklientbiblioteket tilldelar ett nytt värde automatiskt). När klienten försöker igen delar alla försök samma klientbegärans-ID. Om en batch skickas från klienten har batchen ett enda klientbegärans-ID.

ID för serverbegäran

Lagringstjänsten genererar automatiskt ID:t för serverbegäran.

  • I loggen för lagringsloggning på serversidan visas serverbegärans-ID:t i Request ID header kolumnen.
  • I en nätverksspårning, till exempel en som registrerats av Fiddler, visas serverbegärans-ID:t i svarsmeddelanden som x-ms-request-id HTTP-huvudvärdet.
  • I loggen på klientsidan som lagringsklientbiblioteket skapar visas serverbegärans-ID:t i Operation Text kolumnen för loggposten som visar information om serversvaret.

Kommentar

Lagringstjänsten tilldelar alltid ett unikt serverbegärans-ID till varje begäran den tar emot, så varje nytt försök från klienten och varje åtgärd som ingår i en batch har ett unikt serverbegärans-ID.

Kodexemplet nedan visar hur du använder ett anpassat klientbegärande-ID.

var connectionString = Constants.connectionString;

BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);

BlobContainerClient blobContainerClient = blobServiceClient.GetBlobContainerClient("demcontainer");

BlobClient blobClient = blobContainerClient.GetBlobClient("testImage.jpg");

string clientRequestID = String.Format("{0} {1} {2} {3}", HOSTNAME, APPNAME, USERID, Guid.NewGuid().ToString());

using (HttpPipeline.CreateClientRequestIdScope(clientRequestID))
{
    BlobDownloadInfo download = blobClient.Download();

    using (FileStream downloadFileStream = File.OpenWrite("C:\\testImage.jpg"))
    {
        download.Content.CopyTo(downloadFileStream);
        downloadFileStream.Close();
    }
}

Tidsstämplar

Du kan också använda tidsstämplar för att hitta relaterade loggposter, men var försiktig med eventuella klocksnedvridning mellan klienten och servern som kan finnas. Sök plus eller minus 15 minuter efter matchande poster på serversidan baserat på tidsstämpeln på klienten. Kom ihåg att blobmetadata för blobarna som innehåller mått anger tidsintervallet för måtten som lagras i blobben. Det här tidsintervallet är användbart om du har många måttblobar under samma minut eller timme.

Felsökningsguide

Det här avsnittet hjälper dig med diagnos och felsökning av några av de vanliga problem som ditt program kan stöta på när du använder Azure Storage-tjänsterna. Använd listan nedan för att hitta den information som är relevant för ditt specifika problem.

Felsöka beslutsträd

Gäller problemet prestanda för någon av lagringstjänsterna?

Gäller problemet tillgängligheten för någon av lagringstjänsterna?

Får klientprogrammet ett HTTP 4XX-svar (till exempel 404) från en lagringstjänst?

Mått visar att låga PercentSuccess- eller analysloggposter har åtgärder med transaktionsstatus för ClientOtherErrors.

Kapacitetsmått visar en oväntad ökning av användningen av lagringskapacitet.

Problemet uppstår när du använder lagringsemulatorn för utveckling eller testning.

Du får problem med att installera Azure SDK för .NET.

Du har ett annat problem med en lagringstjänst.

Mätningar visar ett högt värde för AverageE2ELatency och ett lågt värde för AverageServerLatency

Bilden nedan från Azure Portal övervakningsverktyget visar ett exempel där AverageE2ELatency är betydligt högre än AverageServerLatency.

Bild från Azure Portal som visar ett exempel där AverageE2ELatency är betydligt högre än AverageServerLatency.

Lagringstjänsten beräknar endast måttet AverageE2ELatency för lyckade begäranden och inkluderar, till skillnad från AverageServerLatency, den tid klienten tar att skicka data och ta emot bekräftelse från lagringstjänsten. Därför kan en skillnad mellan AverageE2ELatency och AverageServerLatency bero på att klientprogrammet svarar långsamt eller på grund av förhållandena i nätverket.

Kommentar

Du kan också visa E2ELatency och ServerLatency för enskilda lagringsåtgärder i loggdata för lagringsloggning.

Undersöka problem med klientprestanda

Möjliga orsaker till att klienten svarar långsamt är att ha ett begränsat antal tillgängliga anslutningar eller trådar eller att det är ont om resurser som CPU, minne eller nätverksbandbredd. Du kanske kan lösa problemet genom att ändra klientkoden så att den blir effektivare (till exempel genom att använda asynkrona anrop till lagringstjänsten) eller genom att använda en större virtuell dator (med fler kärnor och mer minne).

För tabell- och kötjänsterna kan Nagle-algoritmen också orsaka hög AverageE2ELatency jämfört med AverageServerLatency. Mer information finns i Nagles algoritm är inte vänlig mot små begäranden. Du kan inaktivera Nagle-algoritmen i kod med hjälp ServicePointManager av klassen i System.Net namnområdet. Du bör göra detta innan du gör några anrop till tabellen eller kötjänsterna i ditt program eftersom detta inte påverkar anslutningar som redan är öppna. Följande exempel kommer från Application_Start metoden i en arbetsroll.

var connectionString = Constants.connectionString;

QueueServiceClient queueServiceClient = new QueueServiceClient(connectionString);

ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(queueServiceClient.Uri);
queueServicePoint.UseNagleAlgorithm = false;

Du bör kontrollera loggarna på klientsidan för att se hur många begäranden klientprogrammet skickar och söka efter allmänna . NET-relaterade prestandaflaskhalsar i klienten, till exempel CPU, .NET-skräpinsamling, nätverksanvändning eller minne. Som utgångspunkt för felsökning av .NET-klientprogram kan du läsa Felsökning, Spårning och Profilering.

Undersöka problem med nätverksfördröjning

Normalt beror långa svarstider från slutpunkt till slutpunkt som orsakas av nätverket på tillfälliga förhållanden. Du kan undersöka både tillfälliga och beständiga nätverksproblem, till exempel borttagna paket, med hjälp av verktyg som Wireshark.

Mer information om hur du använder Wireshark för att felsöka nätverksproblem finns i Bilaga 2: Använda Wireshark för att samla in nätverkstrafik.

Mätningar visar låga värden för AverageE2ELatency och AverageServerLatency, men klienten har ändå långa svarstider

I det här scenariot är den troligaste orsaken en fördröjning i lagringsbegäranden som når lagringstjänsten. Du bör undersöka varför begäranden från klienten inte skickas till blobtjänsten.

En möjlig orsak till att klienten fördröjer sändningen av begäranden är att det finns ett begränsat antal tillgängliga anslutningar eller trådar.

Kontrollera också om klienten utför flera återförsök och undersöka orsaken om det är det. För att avgöra om klienten utför flera återförsök kan du:

  • Granska Lagringsanalys loggarna. Om flera återförsök görs visas flera åtgärder med samma klientbegärans-ID men med olika serverbegärande-ID:t.
  • Granska klientloggarna. Utförlig loggning indikerar att ett nytt försök har gjorts.
  • Felsök koden och kontrollera egenskaperna för objektet som OperationContext är associerat med begäran. Om åtgärden har gjorts om innehåller egenskapen RequestResults flera unika serverbegärande-ID:er. Du kan också kontrollera start- och sluttiderna för varje begäran. Mer information finns i kodexemplet i avsnittet Serverbegärans-ID.

Om det inte finns några problem i klienten bör du undersöka potentiella nätverksproblem, till exempel paketförlust. Du kan använda verktyg som Wireshark för att undersöka nätverksproblem.

Mer information om hur du använder Wireshark för att felsöka nätverksproblem finns i Bilaga 2: Använda Wireshark för att samla in nätverkstrafik.

Mätningar visar ett högt värde för AverageServerLatency

När det gäller hög AverageServerLatency för begäranden om att hämta blobar bör du använda Storage Logging-loggarna för att se om det finns upprepade begäranden för samma blob (eller uppsättning blobar). För begäranden om blobuppladdning bör du undersöka vilken blockstorlek klienten använder (till exempel kan block som är mindre än 64 K i storlek resultera i omkostnader om inte läsningarna också är i mindre än 64 K segment) och om flera klienter laddar upp block till samma blob parallellt. Du bör också kontrollera måtten per minut för toppar i antalet begäranden som resulterar i att skalbarhetsmålen per sekund överskrids. Mer information finns i Mått visar en ökning i PercentTimeoutError.

Om du ser hög AverageServerLatency för begäranden om blobnedladdning när det finns upprepade begäranden för samma blob eller uppsättning blobar kan du överväga att cachelagra dessa blobar med hjälp av Azure Cache eller Azure Content Delivery Network (CDN). När det gäller förfrågningar om uppladdning kan du förbättra dataflödet genom att använda en större blockstorlek. För frågor till tabeller är det också möjligt att implementera cachelagring på klientsidan på klienter som utför samma frågeåtgärder och där data inte ändras ofta.

Höga värden på AverageServerLatency kan även vara ett symtom på dåligt utformade tabeller eller frågor som resulterar i genomsökningsåtgärder, eller som följer antimönstret append/prepend. Mer information finns i Mått visar en ökning i PercentThrottlingError.

Kommentar

Du hittar en omfattande checklista för prestanda här: Checklista för Prestanda och skalbarhet i Microsoft Azure Storage.

Du upplever oväntade fördröjningar i en köad meddelandeleverans

Om det uppstår en fördröjning mellan den tidpunkt då ett program lägger till ett meddelande i en kö och den tid det blir tillgängligt att läsa från kön, gör du följande för att diagnostisera problemet:

  • Kontrollera att programmet har lagt till meddelandena i kön. Kontrollera att programmet inte försöker AddMessage metoden igen flera gånger innan det lyckas. Loggarna för lagringsklientbiblioteket visar upprepade återförsök av lagringsåtgärder.
  • Kontrollera att det inte finns någon klockförskjutning mellan arbetsrollen som lägger till meddelandet i kön och arbetsrollen som läser meddelandet från kön. Ett klocksnedvridning gör att det ser ut som om bearbetningen fördröjs.
  • Kontrollera om arbetsrollen som läser meddelandena från kön misslyckas. Om en köklient anropar GetMessage metoden men inte svarar med en bekräftelse förblir meddelandet osynligt i kön tills invisibilityTimeout perioden går ut. Nu blir meddelandet tillgängligt för bearbetning igen.
  • Kontrollera om kölängden växer över tid. Detta kan inträffa om du inte har tillräckligt med arbetare tillgängliga för att bearbeta alla meddelanden som andra arbetare placerar i kön. Kontrollera också måtten för att se om borttagningsbegäranden misslyckas och antalet avfrågefel på meddelanden, vilket kan tyda på upprepade misslyckade försök att ta bort meddelandet.
  • Undersök loggarna för lagringsloggning för alla köåtgärder som har högre värden än förväntat för E2ELatency och ServerLatency under en längre tidsperiod än vanligt.

Mätningar visar en ökning i PercentThrottlingError

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 måttet PercentThrottlingError visar en ökning av procentandelen begäranden som misslyckas med ett begränsningsfel måste du undersöka något av två scenarier:

En ökning av PercentThrottlingError sker ofta samtidigt som antalet lagringsbegäranden ökar eller när du först belastningstestar 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 i PercentThrottlingError

Om du ser toppar i värdet för PercentThrottlingError som sammanfaller med perioder med hög aktivitet för programmet kan du implementera 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 namnområdet Microsoft.Azure.Storage.RetryPolicies.

Kommentar

Du kan också se toppar i värdet för PercentThrottlingError som inte sammanfaller med perioder med hög aktivitet för programmet. Den troligaste orsaken är att lagringstjänsten flyttar partitioner för att förbättra belastningsutjämningen.

Permanent ökning av PercentThrottlingError

Om du ser ett konsekvent högt värde för PercentThrottlingError 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) bör 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 måste 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 mönstret prepend/append 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 antingen 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 till följd 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 tio 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.

Kommentar

Prestandatestningen bör visa ineffektiva frågedesigner i ditt program.

Mätningar visar en ökning i PercentTimeoutError

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

Kommentar

Du kan se timeout-fel tillfälligt när lagringstjänsten lastbalanserar begäranden genom att flytta en partition till en ny server.

Måttet PercentTimeoutError är en aggregering av följande mått: ClientTimeoutError, AnonymousClientTimeoutError, SASClientTimeoutError, ServerTimeoutError, AnonymousServerTimeoutError och SASServerTimeoutError.

Tidsgränserna för servern orsakas av ett fel på servern. Tidsgränsen för klienten inträffar eftersom en åtgärd på servern har överskridit den tidsgräns som angetts av klienten. En klient som använder lagringsklientbiblioteket kan till exempel ange en tidsgräns för en åtgärd med hjälp ServerTimeout av egenskapen för QueueRequestOptions klassen.

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ätningar visar en ökning i PercentNetworkError

Dina mått visar en ökning av PercentNetworkError för en av dina lagringstjänster. Måttet PercentNetworkError är en aggregering av följande mått: NetworkError, AnonymousNetworkError och SASNetworkError. Dessa inträffar när lagringstjänsten upptäcker 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 Wireshark eller Tcping för att undersöka problem med nätverksanslutningen från klienten. De här verktygen beskrivs i tilläggen.

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

Om klientprogrammet utfärdar HTTP 403-fel (förbjudet) beror det förmodligen på att klienten använder en SAS (signatur för delad åtkomst) som har upphört att gälla när den skickar förfrågningar om lagring (även om det finns andra orsaker, som klockförskjutning, ogiltiga nycklar eller tomma rubriker). Om en SAS-nyckel har upphört att gälla visas inga poster i loggdata för lagringsloggning på serversidan. I följande tabell visas ett exempel från loggen på klientsidan som genereras av lagringsklientbiblioteket som illustrerar det här problemet:

Källa Utförlighet Utförlighet ID för klientförfrågan Åtgärdstext
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 Varning 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 Varning 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 Fel 1 85d077ab -... Retry policy did not allow for a retry. Failing with The remote server returned an error: (403) Forbidden.

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 någon 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 till synes 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 genererar om dina lagringsåtkomstnycklar kan befintliga SAS-token bli ogiltiga. Det här problemet kan uppstå om du genererar SAS-token med lång förfallotid som klientappar ska cachelagra.

Om du använder Lagringsklientbiblioteket för att generera SAS-token är det enkelt att skapa en giltig token. Om du använder REST-API:et för lagring och konstruerar 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 detta att objektet som klienten försökte använda (till exempel en entitet, tabell, blob, container eller kö) inte finns i lagringstjänsten. Här är några av de möjliga orsakerna:

Klienten eller en annan process har tagit bort objektet

I scenarier där klienten försöker läsa, uppdatera eller ta bort data i en lagringstjänst är det vanligtvis enkelt att i loggarna på serversidan identifiera en tidigare åtgärd som tog bort det aktuella objektet från lagringstjänsten. Loggdata visar ofta att en annan användare eller process har tagit bort objektet. I loggloggen för lagring på serversidan visas kolumnerna operation-type och requested-object-key när en klient tog bort ett objekt.

I scenariot där en klient försöker infoga ett objekt kanske det inte är omedelbart uppenbart varför detta resulterar i ett HTTP 404-svar (hittades inte), med tanke på att 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 lagringsklientbiblioteket för att få en mer detaljerad förståelse för 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:

ID för begäran Åtgärd
07b26a5d-... DeleteIfExists -metod för att ta bort blobcontainern. Observera att den här åtgärden innehåller en HEAD begäran om att söka efter containerns existens.
e2d06d78... CreateIfNotExists -metod för att skapa blobcontainern. Observera att den här åtgärden innehåller en HEAD begäran som söker efter containerns existens. HEAD Returnerar ett 404-meddelande men fortsätter.
de8b1c3c-... UploadFromStream -metod för att skapa bloben. Begäran PUT misslyckas med ett 404-meddelande.

Loggposter:

ID för begäran Åtgärdstext
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..

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.

Det är problem med SAS-autentiseringen (signatur för delad åtkomst)

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. Samtidigt visas även ett värde som inte är noll för SASAuthorizationError i måtten.

I följande tabell visas ett exempel på ett loggmeddelande på serversidan från loggfilen för lagringsloggning:

Name Värde
Begär starttid 2014-05-30T06:17:48.4473697Z
Åtgärdstyp GetBlobProperties
Status för begäran SASAuthorizationError
HTTP-statuskod 404
Authentication type Sas
Typ av tjänst Blob
Begärans-URL https://domemaildist.blob.core.windows.net/azureimblobcontainer/blobCreatedViaSAS.txt
  ?sv=2014-02-14&sr=c&si=mypolicy&sig=XXXXX&; api-version=2014-02-14
Sidhuvud för begärande-ID <Sidhuvud för begärande-ID>
ID för klientförfrågan <Klientbegärans-ID>

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 söker du efter följande JavaScript-fel i webbläsaren:

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

Kommentar

Du kan använda F12 Developer Tools i Internet Explorer för att spåra meddelanden som utbyts mellan webbläsaren och lagringstjänsten när du felsöker JavaScript-problem på klientsidan.

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

För att kringgå JavaScript-problemet kan du konfigurera Resursdelning mellan ursprung (CORS) för den lagringstjänst som klienten har åtkomst till. Mer information finns i Cors-stöd (Cross-Origin Resource Sharing) för Azure Storage Services.

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 tog bort entiteten på det sätt som begärdes.

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 lagringsloggarna på serversidan genom att söka i request-id-header kolumnen i loggfilen. 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) Not Found" och logga det i klienten, men låta klienten fortsätta.

Klienten tar emot HTTP 409-meddelanden (konflikt)

I följande tabell visas ett extrahering från loggen på serversidan för två klientåtgärder: DeleteIfExists följt direkt med CreateIfNotExists samma namn på blobcontainern. Varje klientåtgärd resulterar i två begäranden som skickas till servern, först en GetContainerProperties begäran om att kontrollera om containern finns, följt av DeleteContainer eller CreateContainer begäran.

Tidsstämpel Åtgärd Result Containerns namn ID för klientförfrågan
05:10:13.7167225 GetContainerProperties 200 mmcont c9f52c89-...
05:10:13.8167325 DeleteContainer 202 mmcont c9f52c89-...
05:10:13.8987407 GetContainerProperties 404 mmcont bc881924-...
05:10:14.2147723 CreateContainer 409 mmcont bc881924-...

Koden i klientprogrammet tar bort och återskapar sedan omedelbart en blobcontainer med samma namn: CreateIfNotExists metoden (klientbegärans-ID bc881924-...) misslyckas till slut med HTTP 409-felet (konflikt). När en klient tar bort blobcontainrar, tabeller eller köer finns det en kort period innan namnet blir tillgängligt igen.

Klientappen bör använda unika containernamn när nya containrar skapas om det är ett vanligt mönster att ta bort/återskapa dem.

Mått visar att poster med låg PercentSuccess eller analyslogg har åtgärder med transaktionsstatus för ClientOtherErrors

Måttet PercentSuccess samlar in procentandelen åtgärder som lyckades baserat på deras HTTP-statuskod. Åtgärder med statuskoder på 2XX räknas som lyckade, medan åtgärder med statuskoder i 3XX-, 4XX- och 5XX-intervall räknas som misslyckade och sänker måttvärdet PercentSuccess . I lagringsloggfilerna på serversidan registreras dessa åtgärder med transaktionsstatusen ClientOtherErrors.

Det är viktigt att observera att dessa åtgärder har slutförts och därför inte påverkar 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.

Kapacitetsmått visar en oväntad ökning av användningen av lagringskapacitet

Om du ser plötsliga, oväntade ändringar i kapacitetsanvändningen i ditt lagringskonto kan du undersöka orsakerna genom att först titta på dina tillgänglighetsmått. En ökning av antalet misslyckade borttagningsbegäranden kan till exempel leda till en ökning av mängden bloblagring som du använder som programspecifika rensningsåtgärder som du kanske förväntade dig att frigöra utrymme kanske inte fungerar som förväntat (till exempel eftersom SAS-token som används för att frigöra utrymme har upphört att gälla).

Problemet uppstår när du använder lagringsemulatorn för utveckling eller testning

Du använder vanligtvis lagringsemulatorn under utveckling och testning för att undvika kravet på ett Azure-lagringskonto. Vanliga problem som kan uppstå när du använder lagringsemulatorn är:

Funktionen "X" fungerar inte i lagringsemulatorn

Lagringsemulatorn stöder inte alla funktioner i Azure Storage-tjänsterna, till exempel filtjänsten. Mer information finns i Använd Azure Storage-emulatorn för utveckling och testning.

För de funktioner som lagringsemulatorn inte stöder använder du Azure Storage-tjänsten i molnet.

Fel : "Värdet för en av HTTP-huvudena är inte i rätt format" när du använder lagringsemulatorn

Du testar ditt program som använder Lagringsklientbiblioteket mot den lokala lagringsemulatorn, och metodanrop som CreateIfNotExists misslyckas med felmeddelandet "Värdet för en av HTTP-huvudena är inte i rätt format". Detta indikerar att den version av lagringsemulatorn som du använder inte stöder den version av lagringsklientbiblioteket som du använder. Lagringsklientbiblioteket lägger till huvudet x-ms-version i alla begäranden som det gör. Om lagringsemulatorn inte känner igen värdet i x-ms-version huvudet avvisas begäran.

Du kan använda klientloggarna för lagringsbiblioteket för att se värdet för det som x-ms-version header skickas. Du kan också se värdet för x-ms-version header om du använder Fiddler för att spåra begäranden från klientprogrammet.

Det här scenariot inträffar vanligtvis om du installerar och använder den senaste versionen av lagringsklientbiblioteket utan att uppdatera lagringsemulatorn. Du bör antingen installera den senaste versionen av lagringsemulatorn eller använda molnlagring i stället för emulatorn för utveckling och testning.

För att köra lagringsemulatorn krävs administratörsbehörighet

Du uppmanas att ange administratörsautentiseringsuppgifter när du kör lagringsemulatorn. Detta inträffar bara när du initierar lagringsemulatorn för första gången. När du har initierat lagringsemulatorn behöver du inte administratörsbehörighet för att köra den igen.

Mer information finns i Använd Azure Storage-emulatorn för utveckling och testning. Du kan också initiera lagringsemulatorn i Visual Studio, vilket också kräver administratörsbehörighet.

Du får problem med att installera Azure SDK för .NET

När du försöker installera SDK:n misslyckas den när du försöker installera lagringsemulatorn på den lokala datorn. Installationsloggen innehåller något av följande meddelanden:

  • CAQuietExec: Fel: Det går inte att komma åt SQL-instansen
  • CAQuietExec: Fel: Det går inte att skapa databasen

Orsaken är ett problem med den befintliga LocalDB-installationen. Som standard använder lagringsemulatorn LocalDB för att spara data när den simulerar Azure Storage-tjänsterna. Du kan återställa din LocalDB-instans genom att köra följande kommandon i ett kommandotolkfönster innan du försöker installera SDK:t.

sqllocaldb stop v11.0
sqllocaldb delete v11.0
delete %USERPROFILE%\WAStorageEmulatorDb3*.*
sqllocaldb create v11.0

Kommandot delete tar bort alla gamla databasfiler från tidigare installationer av lagringsemulatorn.

Du har ett annat problem med en lagringstjänst

Om de föregående felsökningsavsnitten inte innehåller det problem du har med en lagringstjänst bör du använda följande metod för att diagnostisera och felsöka problemet.

  • Kontrollera dina mått för att se om det finns några ändringar från ditt förväntade baslinjebeteende. Från måtten kanske du kan avgöra om problemet är tillfälligt eller permanent och vilka lagringsåtgärder problemet påverkar.
  • Du kan använda måttinformationen för att söka efter mer detaljerad information om eventuella fel på serversidan. Den här informationen kan hjälpa dig att felsöka och lösa problemet.
  • Om informationen i loggarna på serversidan inte räcker för att felsöka problemet kan du använda loggarna på klientsidan för lagringsklientbiblioteket för att undersöka beteendet för klientprogrammet och verktyg som Fiddler och Wireshark för att undersöka nätverket.

Mer information om hur du använder Fiddler finns i Bilaga 1: Använda Fiddler för att samla in HTTP- och HTTPS-trafik.

Mer information om hur du använder Wireshark finns i Bilaga 2: Använda Wireshark för att samla in nätverkstrafik.

Bilagor

Tilläggen beskriver flera verktyg som kan vara användbara när du diagnostiserar och felsöker problem med Azure Storage (och andra tjänster). Dessa verktyg ingår inte i Azure Storage och vissa är produkter från tredje part. Därför omfattas inte de verktyg som beskrivs i dessa tillägg av något supportavtal som du kan ha med Microsoft Azure eller Azure Storage. Som en del av utvärderingsprocessen bör du därför undersöka de licensierings- och supportalternativ som är tillgängliga från leverantörerna av dessa verktyg.

Bilaga 1: Använda Fiddler för att samla in HTTP- och HTTPS-trafik

Fiddler är ett användbart verktyg för att analysera HTTP- och HTTPS-trafiken mellan klientprogrammet och azure-lagringstjänsten som du använder.

Kommentar

Fiddler kan avkoda HTTPS-trafik. Du bör läsa Fiddler-dokumentationen noggrant för att förstå hur det gör detta och dess säkerhetskonsekvenser.

Den här bilagan innehåller en kort genomgång av hur du konfigurerar Fiddler för att samla in trafik mellan den lokala datorn där du har installerat Fiddler och Azure Storage-tjänsterna.

När du har startat Fiddler börjar den samla in HTTP- och HTTPS-trafik på den lokala datorn. Följande är några användbara kommandon för att kontrollera Fiddler:

  • Stoppa och börja samla in trafik. På huvudmenyn går du till Arkiv och väljer sedan Avbilda trafik för att aktivera och inaktivera hämtning.
  • Spara insamlade trafikdata. På huvudmenyn går du till Arkiv, väljer Spara och sedan Alla sessioner. På så sätt kan du spara trafiken i en sessionsarkivfil. Du kan läsa in ett sessionsarkiv igen senare för analys eller skicka det om det begärs till Microsoft-supporten.

Om du vill begränsa mängden trafik som Fiddler samlar in kan du använda filter som du konfigurerar på fliken Filter . Följande skärmbild visar ett filter som endast samlar in trafik som skickas till lagringsslutpunkten contosoemaildist.table.core.windows.net :

Skärmbild som visar ett filter som endast samlar in trafik som skickas till contosoemaildist.table.core.windows.net lagringsslutpunkten.

Bilaga 2: Använda Wireshark för att samla in nätverkstrafik

Wireshark är en nätverksprotokollanalysator som gör att du kan visa detaljerad paketinformation för en mängd olika nätverksprotokoll.

Följande procedur visar hur du samlar in detaljerad paketinformation för trafik från den lokala dator där du installerade Wireshark till tabelltjänsten i ditt Azure-lagringskonto.

  1. Starta Wireshark på din lokala dator.

  2. I avsnittet Start väljer du det lokala nätverksgränssnittet eller gränssnitten som är anslutna till Internet.

  3. Välj Avbildningsalternativ.

  4. Lägg till ett filter i textrutan Insamlingsfilter . Konfigurerar till exempel host contosoemaildist.table.core.windows.net Wireshark för att endast samla in paket som skickas till eller från tabelltjänstens slutpunkt i lagringskontot contosoemaildist . Kolla in den fullständiga listan med avbildningsfilter.

    Skärmbild som visar hur du lägger till ett filter i textrutan Avbildningsfilter.

  5. Välj start. Wireshark samlar nu in alla paket som skickas till eller från tabelltjänstens slutpunkt när du använder klientprogrammet på den lokala datorn.

  6. När du är klar väljer du Avbildningsstopp> på huvudmenyn.

  7. Om du vill spara insamlade data i en Wireshark Capture-fil väljer du Spara fil>på huvudmenyn.

WireShark markerar eventuella fel som finns i paketlistefönstret . Du kan också använda fönstret Expertinformation (välj Analysera>expertinformation) för att visa en sammanfattning av fel och varningar.

Skärmbild som visar fönstret Expertinformation där du kan visa en sammanfattning av fel och varningar.

Du kan också välja att visa TCP-data som programlagret ser det genom att högerklicka på TCP-data och välja Följ TCP Stream. Det här är användbart om du har samlat in din dump utan ett avbildningsfilter. Mer information finns i Följande TCP-strömmar.

Skärmbild som visar hur du visar TCP-data när programlagret ser dem.

Kommentar

Mer information om hur du använder Wireshark finns i användarhandboken för Wireshark.

Bilaga 4: Använda Excel för att visa mått och loggdata

Med många verktyg kan du ladda ned lagringsstatistikdata från Azure Table Storage i ett avgränsat format som gör det enkelt att läsa in data i Excel för visning och analys. Lagringsloggningsdata från Azure Blob Storage är redan i ett avgränsat format som du kan läsa in i Excel. Du måste dock lägga till lämpliga kolumnrubriker baserat på informationen i Lagringsanalys loggformat och Lagringsanalys tabellschema för mått.

Så här importerar du lagringsloggningsdata till Excel när du har laddat ned dem från Blob Storage:

  • På menyn Data väljer du Från text.
  • Bläddra till loggfilen som du vill visa och välj Importera.
  • I steg 1 i guiden Textimport väljer du Avgränsad.

I steg 1 i guiden Textimport väljer du Semikolon som den enda avgränsaren och väljer dubbel citattecken som textkvalificerare. Välj sedan Slutför och välj var du vill placera data i arbetsboken.

Bilaga 5: Övervakning med Application Insights för Azure DevOps

Du kan också använda Application Insights-funktionen för Azure DevOps som en del av din prestanda- och tillgänglighetsövervakning. Det här verktyget kan:

  • Kontrollera att webbtjänsten är tillgänglig och dynamisk. Oavsett om din app är en webbplats eller en enhetsapp som använder en webbtjänst kan den testa din URL med några minuters mellanrum från platser över hela världen och meddela dig om det finns ett problem.
  • Diagnostisera snabbt eventuella prestandaproblem eller undantag i webbtjänsten. Ta reda på om processorn eller andra resurser sträcks ut, hämta stackspårningar från undantag och sök enkelt igenom loggspårningar. Om appens prestanda sjunker under acceptabla gränser kan Microsoft skicka ett e-postmeddelande till dig. Du kan övervaka både .NET- och Java-webbtjänster.

Mer information finns i Vad är Application Insights?

Nästa steg

Mer information om analys i Azure Storage finns i följande resurser:

Ansvarsfriskrivning för information från tredje part

De produkter från andra tillverkare som diskuteras i denna artikel tillverkas oberoende av Microsoft. Produkternas funktion eller tillförlitlighet kan därför inte garanteras.

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.