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-tjänster och IT-proffs som ansvarar för att hantera sådana onlinetjänster. Målen 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 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.

Obs!

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 programmet kan använda flera lagringstekniker, till exempel Microsoft Azure Storage tabeller, blobar, 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 det problem som ditt program 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 anläggningarna i ett av klientbiblioteken, till exempel Storage Client Library för .NET eller Azure SDK för Java.

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

I avsnittet Felsökningsvägledning finns felsökningsvägledning för några av de vanliga lagringsrelaterade problem som kan uppstå.

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 Performance Monitor. I Lagringsmått hittar du en omfattande uppsättning mått (räknare i terminologin för Windows Performance Monitor), till exempel tjänsttillgänglighet, det totala antalet begäranden till tjänst 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 läser 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 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 kommer i många fall att vara programspecifika och du bör upprätta dem när du prestandatestar ditt program.
  • Registrera minutmått och använda dem för att aktivt övervaka oväntade fel och avvikelser, till exempel toppar i antalet fel eller begärandefrekvenser.
  • 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 för mått per timme kan dölja aktivitetstoppar. Timmåtten verkar visa en stadig frekvens av begäranden, medan minutmåtten visar de fluktuationer som verkligen äger rum.

Diagram som visar hur medelvärdet för mått per timme kan dölja toppar i aktiviteten.

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.

Obs!

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 blobar 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 tabellen $MetricsCapacityBlob 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 blobar (ObjectCount) som används i lagringskontot. Mer information om kapacitetsmåtten som lagras i tabellen finns i $MetricsCapacityBlobLagringsanalys Måtttabellschema.

Obs!

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.

Om du vill uppskatta storleken på olika lagringsobjekt, till exempel blobar, kan du läsa 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änster i ditt lagringskonto genom att övervaka värdet i Availability kolumnen i måtttabellerna varje 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).

Ett värde 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 understiger 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 måtttabellerna för varje 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 (därför inkluderar 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 (Mått visar hög AverageE2ELatency och låg AverageServerLatency ) senare i den här guiden för en beskrivning av 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 det 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, inklusive:

  • Ett större 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.
  • Rapporterar från användare av ditt program 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 delas problem som rör Azure Storage-tjänster in i någon av fyra breda kategorier:

  • Ditt program har ett prestandaproblem som antingen rapporteras av dina användare eller avslöjas 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 avslöjas av en ökning av något av de mått för antal fel som du övervakar.
  • Under utveckling och testning kanske du använder 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 som 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 kan uppstå.

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. Om du vill 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 läget nedsatt funktionalitet 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 redundansalternativ för Azure Storage och Read Access Geo Redundant Storage.

Prestandaproblem

Prestandan för ett program kan vara subjektiv, särskilt ur ett användarperspektiv. Därför är det viktigt att ha baslinjemått tillgängliga för att hjälpa dig att identifiera var det kan finnas ett prestandaproblem. Många faktorer kan påverka prestandan för en Azure Storage-tjä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 prestandaproblemets ursprung.

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 kan uppstå.

Diagnostisera fel

Användare av ditt program kan meddela dig om fel som rapporterats av klientprogrammet. Lagringsmått registrerar också antalet 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 loggar på serversidan, klientsidan och nätverket. Vanligtvis ger HTTP-statuskoden som returneras av lagringstjänsten en indikation på varför begäran misslyckades.

Obs!

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 för att förstå lagringsrelaterad status 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 Storage-konto.

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

Verktyg för lagringsloggning

Lagringsloggning ger loggning på serversidan av lagringsbegäranden i ditt Azure Storage-konto. 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 Loggning på klientsidan med .NET Storage-klientbiblioteket.

Obs!

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 ge 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 Storage-klientbiblioteket 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 huvud- 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 används 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.

Klientbegärans-ID

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ärdet.
  • I loggen för lagringsloggning på serversidan visas klientbegärans-ID:t i kolumnen Klientbegärans-ID.

Obs!

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. När det gäller en batch som skickas från klienten har batchen ett enda klientbegärans-ID.

ID för serverbegäran

Lagringstjänsten genererar automatiskt serverbegärans-ID:t.

  • 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.

Obs!

Lagringstjänsten tilldelar alltid ett unikt serverbegärans-ID till varje begäran den tar emot, så varje återfö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. Search plus eller minus 15 minuter för 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 bloben. Det här tidsintervallet är användbart om du har många måttblobar för samma minut eller timme.

Felsökningsvägledning

Det här avsnittet hjälper dig att diagnostisera och felsöka 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 en 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 transaktionsstatusen 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 stöter på problem med att installera Azure SDK för .NET.

Du har ett annat problem med en lagringstjänst.

Mått visar hög AverageE2ELatency och låg 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 bara måttet AverageE2ELatency för lyckade begäranden och inkluderar, till skillnad från AverageServerLatency, den tid det tar för klienten 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 nätverksförhållanden.

Obs!

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 finns ont om resurser som PROCESSOR, minne eller nätverksbandbredd. Du kanske kan lösa problemet genom att ändra klientkoden så att den blir mer effektiv (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 som 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ått visar låg AverageE2ELatency och låg AverageServerLatency men klienten har hög svarstid

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ärans-ID:t.
  • Granska klientloggarna. Utförlig loggning anger 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 flera unika serverbegärande-ID RequestResults :t. Du kan också kontrollera start- och sluttiderna för varje begäran. Mer information finns i kodexemplet i avsnittet Serverförfrågnings-ID.

Om det inte finns några problem i klienten bör du undersöka potentiella nätverksproblem som 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ått visar hög AverageServerLatency

När det gäller hög AverageServerLatency för begäranden om blobnedladdning bör du använda loggarna för lagringsloggning 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 bör du överväga att cachelagra dessa blobar med hjälp av Azure Cache eller Azure Content Delivery Network (CDN). För uppladdningsbegäranden kan du förbättra dataflödet med hjälp av 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 AverageServerLatency-värden kan också vara ett symptom på dåligt utformade tabeller eller frågor som resulterar i genomsökningsåtgärder eller som följer antimönstret för tillägg/förberedelse. Mer information finns i Mått visar en ökning i PercentThrottlingError.

Obs!

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

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

Om det uppstår en fördröjning mellan den tid 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, utför du följande steg för att diagnostisera problemet:

  • Kontrollera att programmet har lagt till meddelandena i kön. Kontrollera att programmet inte försöker AddMessage använda 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 klocksnedställning mellan arbetsrollen som lägger till meddelandet i kön och arbetsrollen som läser meddelandet från kön. En klocksnedställning gör att det ser ut som om bearbetningen tar för lite tid.
  • 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 personal 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 för meddelanden, vilket kan tyda på upprepade misslyckade försök att ta bort meddelandet.
  • Granska loggarna för lagringsloggning för eventuella 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ått visar en ökning i PercentThrottlingError

Begränsningsfel uppstår när 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 Servern är 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) backoff-strategi för återförsök i klienten. Backoff-återförsök minskar den omedelbara belastningen på partitionen och hjälper ditt program att jämna ut trafiktopparna. Mer information om hur du implementerar återförsöksprinciper med hjälp av Storage-klientbiblioteket finns i namnområdet Microsoft.Azure.Storage.RetryPolicies.

Obs!

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 för 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 antimönstret prepend/append där du väljer datumet som partitionsnyckel och sedan skrivs alla data 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 användning av Blob Storage kan vara en bättre lösning. Kontrollera också om begränsningen sker till följd av toppar i trafiken och undersöka olika 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å göra 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 söker igenom 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.

Obs!

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

Mått visar en ökning i PercentTimeoutError

Dina mått visar en ökning i PercentTimeoutError för en av dina lagringstjänster. Samtidigt tar klienten emot en stor mängd HTTP-statusmeddelanden för "500 åtgärdstimeout" från lagringsåtgärder.

Obs!

Du kan tillfälligt se timeout-fel 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 anges av klienten. En klient som använder storage-klientbiblioteket 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ämningsaktivitet i tjänsten. Om problemet är beständigt och inte orsakas av att programmet når tjänstens skalbarhetsgränser bör du skapa ett supportproblem. För klienttimeouter måste du bestämma om tidsgränsen är inställd på ett lämpligt värde i klienten och antingen ändra tidsgränsvärdet 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 i PercentNetworkError

Dina mått visar en ökning i 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 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 tidsgräns går ut 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 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). 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:

Source Informationsnivån Informationsnivån Klientbegärans-ID Å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 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 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 Storage-klientbiblioteket.
  • 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

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 objektet i fråga från lagringstjänsten. Loggdata visar ofta att en annan användare eller process har tagit bort objektet. I loggen för lagringsloggning 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 ä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 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:

Förfrågnings-ID Å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 kontrollera om containern finns.
e2d06d78... CreateIfNotExists -metod för att skapa blobcontainern. Observera att den här åtgärden innehåller en HEAD begäran som kontrollerar om containern finns. 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:

Förfrågnings-ID Å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.

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. 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:

Namn Värde
Starttid för begäran 2014-05-30T06:17:48.4473697Z
Åtgärdstyp GetBlobEgenskaper
Begärandestatus SASAuthorizationError
HTTP-statuskod 404
Autentiseringstyp Sas
Tjänsttyp Blob
Begärande-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>
Klientbegärans-ID <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 rubriken Access-Control-Allow-Origin.
SCRIPT7002: XMLHttpRequest: Nätverksfel 0x80070005, åtkomst nekas.

Obs!

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

I följande tabell visas ett utdrag från loggen på serversidan för två klientåtgärder: DeleteIfExists följt omedelbart 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 begäran eller CreateContainer .

Tidsstämpel Åtgärd Resultat Containernamn Klientbegärans-ID
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.

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

Måttet PercentSuccess 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 PercentSuccess . I lagringsloggfilerna på serversidan registreras dessa åtgärder med transaktionsstatusen ClientOtherErrors.

Det är viktigt att notera 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 lagringskapacitetsanvändningen

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 Storage-konto. 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ända 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.

Felet "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, till exempel 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 den 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 Storage-klientbiblioteket 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.

Körning av lagringsemulatorn kräver 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ända Azure Storage-emulatorn för utveckling och testning. Du kan också initiera lagringsemulatorn i Visual Studio, vilket också kräver administratörsbehörighet.

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

När du försöker installera SDK misslyckas det 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 kommandotolksfö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ågon ändring 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 som problemet påverkar.
  • Du kan använda måttinformationen för att söka i loggdata på serversidan efter mer detaljerad information om eventuella fel som inträffar. 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-trafik mellan klientprogrammet och Azure Storage-tjänsten som du använder.

Obs!

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 avbildning.
  • 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 Microsofts support.

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 registrerar trafik som skickas till lagringsslutpunkten contosoemaildist.table.core.windows.net :

Skärmbild som visar ett filter som endast registrerar trafik som skickas till contosoemaildist.table.core.windows.net lagringsslutpunkt.

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

Wireshark är ett nätverksprotokollanalysverktyg 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 datorn 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 Avbildningsfilter . 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 . Ta en titt på den fullständiga listan över 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 kommer att markera eventuella fel som finns i fönstret paketlista . 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. Detta ä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 som programlagret ser dem.

Obs!

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 lagringsmåttdata 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 måtttabellschema.

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 dubbelcitat som Text-kvalificerare. 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 prestanda- och tillgänglighetsövervakningen. Det här verktyget kan:

  • Kontrollera att webbtjänsten är tillgänglig och responsiv. 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 godkända 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.