Felsökning från slutpunkt till slutpunkt med Azure Storage-mått och -loggning, AzCopy och Message Analyzer

Att diagnostisera och felsöka är en viktig färdighet för att skapa och stödja klientprogram med Microsoft Azure Storage. På grund av ett Azure-programs distribuerade natur kan det vara mer komplicerat att diagnostisera och felsöka fel och prestandaproblem än i traditionella miljöer.

I den här självstudien visar vi hur du identifierar vissa fel som kan påverka prestanda och felsöker dessa fel från slutpunkt till slutpunkt med hjälp av verktyg från Microsoft och Azure Storage för att optimera klientprogrammet.

Den här självstudien ger en praktisk utforskning av ett felsökningsscenario från slutpunkt till slutpunkt. En djupgående konceptuell guide för felsökning av Azure Storage-program finns i Övervaka, diagnostisera och felsöka Microsoft Azure Storage.

Verktyg för felsökning av Azure Storage-program

Om du vill felsöka klientprogram med Microsoft Azure Storage kan du använda en kombination av verktyg för att avgöra när ett problem har uppstått och vad orsaken till problemet kan vara. Dessa verktyg innefattar:

• Azure Lagringsanalys. Azure Lagringsanalys tillhandahåller mått och loggning för Azure Storage.

  • Lagringsmått spårar transaktionsmått och kapacitetsmått för ditt lagringskonto. Med hjälp av mått kan du avgöra hur programmet presterar enligt en mängd olika mått. Mer information om vilka typer av mått som spåras av Lagringsanalys finns i tabellschemat för Lagringsanalys mått.
  • Lagringsloggning loggar varje begäran till Azure Storage-tjänsterna till en logg på serversidan. Loggen spårar detaljerade data för varje begäran, inklusive utförd åtgärd, status för åtgärden och svarstidsinformation. Mer information om de begärande- och svarsdata som skrivs till loggarna av Lagringsanalys finns i Lagringsanalys Loggformat.

• Azure-portalen. Du kan konfigurera mått och loggning för ditt lagringskonto i Azure Portal. Du kan också visa diagram och grafer som visar hur programmet presterar över tid och konfigurera aviseringar för att meddela dig om programmet presterar annorlunda än förväntat för ett angivet mått.

  Mer information om hur du konfigurerar övervakning i Azure Portal finns i Övervaka ett lagringskonto i Azure Portal.

• AzCopy. Serverloggar för Azure Storage lagras som blobar, så du kan använda AzCopy för att kopiera loggblobbarna till en lokal katalog för analys med hjälp av Microsoft Message Analyzer. Mer information om AzCopy finns i Överföra data med Verktyget AzCopy Command-Line .

• Microsoft Message Analyzer. Message Analyzer är ett verktyg som använder loggfiler och visar loggdata i ett visuellt format som gör det enkelt att filtrera, söka och gruppera loggdata i användbara uppsättningar som du kan använda för att analysera fel och prestandaproblem. Mer information om Message Analyzer finns i Driftsguiden för Microsoft Message Analyzer .

Om exempelscenariot

I den här självstudien ska vi undersöka ett scenario där Azure Storage-mått anger en låg procents framgångsgrad för ett program som anropar Azure Storage. Måttet för låg procents framgång (visas som PercentSuccess i Azure Portal och i måtttabellerna) spårar åtgärder som lyckas, men som returnerar en HTTP-statuskod som är större än 299. I lagringsloggfilerna på serversidan registreras dessa åtgärder med transaktionsstatusen ClientOtherErrors. Mer information om måttet för låg procent lyckades finns i Mått visar låga PercentSuccess eller analysloggposter har åtgärder med transaktionsstatus för ClientOtherErrors.

Azure Storage-åtgärder kan returnera HTTP-statuskoder som är större än 299 som en del av deras normala funktioner. Men dessa fel indikerar i vissa fall att du kanske kan optimera klientprogrammet för bättre prestanda.

I det här scenariot bedömer vi att en låg procentuell framgångsgrad är något under 100 %. Du kan dock välja en annan måttnivå beroende på dina behov. Vi rekommenderar att du under testningen av ditt program upprättar en baslinjetolerans för dina viktiga prestandamått. Du kan till exempel, baserat på testning, fastställa att programmet ska ha en konsekvent procentuell framgångsgrad på 90 % eller 85 %. Om dina måttdata visar att programmet avviker från det talet kan du undersöka vad som kan orsaka ökningen.

I vårt exempelscenario undersöker vi loggarna för att hitta felen som korrelerar med måtten och använder dem för att ta reda på vad som orsakar den lägre procentuella framgångsfrekvensen när vi har fastställt att måttens procentresultat är lägre än 100 %. Vi tittar specifikt på fel i intervallet 400. Sedan undersöker vi 404-fel (hittades inte).

Vissa orsaker till fel med 400 intervall

Exemplen nedan visar ett urval av cirka 400 intervallfel för begäranden mot Azure Blob Storage och möjliga orsaker. Något av dessa fel, samt fel i intervallet 300 och 500, kan bidra till en låg procent lyckades.

Observera att listorna nedan är långt ifrån fullständiga. Mer information om allmänna Azure Storage-fel och om fel som är specifika för var och en av lagringstjänsterna finns i Status- och felkoder på MSDN.

Exempel på statuskod 404 (hittades inte)

Inträffar när en läsåtgärd mot en container eller blob misslyckas eftersom bloben eller containern inte hittas.

• Inträffar om en container eller blob har tagits bort av en annan klient före den här begäran.
• Inträffar om du använder ett API-anrop som skapar containern eller bloben när du har kontrollerat om den finns. API:erna CreateIfNotExists gör först ett HEAD-anrop för att kontrollera om containern eller bloben finns. om det inte finns returneras ett 404-fel och sedan görs ett andra PUT-anrop för att skriva containern eller bloben.

Exempel på statuskod 409 (konflikt)

• Inträffar om du använder ett Skapa API för att skapa en ny container eller blob, utan att först kontrollera om det finns, och det redan finns en container eller blob med det namnet.
• Inträffar om en container tas bort och du försöker skapa en ny container med samma namn innan borttagningen är klar.
• Inträffar om du anger ett lån för en container eller blob och det redan finns ett lån.

Exempel på statuskod 412 (villkorsfel)

• Inträffar när villkoret som anges av ett villkorsstyrt huvud inte har uppfyllts.
• Inträffar när det angivna låne-ID:t inte matchar låne-ID:t för containern eller bloben.

Generera loggfiler för analys

I den här självstudien använder vi Message Analyzer för att arbeta med tre olika typer av loggfiler, även om du kan välja att arbeta med något av följande:

• Serverloggen som skapas när du aktiverar Azure Storage-loggning. Serverloggen innehåller data om varje åtgärd som anropas mot någon av Azure Storage-tjänsterna – blob, kö, tabell och fil. Serverloggen anger vilken åtgärd som anropades och vilken statuskod som returnerades, samt annan information om begäran och svaret.
• .NET-klientloggen som skapas när du aktiverar loggning på klientsidan inifrån .NET-programmet. Klientloggen innehåller detaljerad information om hur klienten förbereder begäran och tar emot och bearbetar svaret.
• HTTP-nätverksspårningsloggen, som samlar in data om HTTP/HTTPS-begärande- och svarsdata, inklusive för åtgärder mot Azure Storage. I den här självstudien genererar vi nätverksspårningen via Message Analyzer.

Konfigurera loggning och mått på serversidan

Först måste vi konfigurera Loggning och mått för Azure Storage, så att vi har data från tjänstsidan för att analysera. Du kan konfigurera loggning och mått på flera olika sätt – via Azure Portal, med hjälp av PowerShell eller programmatiskt. Mer information om hur du konfigurerar loggning och mått finns i Aktivera mått och Aktivera loggning .

Konfigurera loggning på .NET-klientsidan

Om du vill konfigurera loggning på klientsidan för ett .NET-program aktiverar du .NET-diagnostik i programmets konfigurationsfil (web.config eller app.config). Mer information finns i Loggning på klientsidan med .NET Storage-klientbiblioteket och loggning på klientsidan med Microsoft Azure Storage SDK för Java på MSDN.

Loggen på klientsidan innehåller detaljerad information om hur klienten förbereder begäran och tar emot och bearbetar svaret.

Lagringsklientbiblioteket lagrar loggdata på klientsidan på den plats som anges i programmets konfigurationsfil (web.config eller app.config).

Samla in en nätverksspårning

Du kan använda Message Analyzer för att samla in en HTTP/HTTPS-nätverksspårning medan klientprogrammet körs. Message Analyzer använder Fiddler på serverdelen. Innan du samlar in nätverksspårningen rekommenderar vi att du konfigurerar Fiddler för att registrera okrypterad HTTPS-trafik:

1. Installera Fiddler.
2. Starta Fiddler.
3. Välj Verktyg | Fiddler-alternativ.
4. I dialogrutan Alternativ kontrollerar du att Både HTTPS CONNECTs och Dekryptera HTTPS-trafik är markerade, enligt nedan.

I självstudien samlar du in och sparar en nätverksspårning först i Message Analyzer och skapar sedan en analyssession för att analysera spårningen och loggarna. Så här samlar du in en nätverksspårning i Message Analyzer:

1. I Meddelandeanalys väljer du Fil | Snabbspårning | Okrypterade HTTPS.

2. Spårningen börjar omedelbart. Välj Stoppa för att stoppa spårningen så att vi kan konfigurera den för att endast spåra lagringstrafik.

3. Välj Redigera för att redigera spårningssessionen.

4. Välj länken Konfigurera till höger om Microsoft-Pef-WebProxy ETW-providern .

5. I dialogrutan Avancerade inställningar klickar du på fliken Provider .

6. I fältet Värdnamnfilter anger du dina lagringsslutpunkter avgränsade med blanksteg. Du kan till exempel ange dina slutpunkter på följande sätt. ändra storagesample till namnet på ditt lagringskonto:

   storagesample.blob.core.windows.net storagesample.queue.core.windows.net storagesample.table.core.windows.net

7. Avsluta dialogrutan och klicka på Starta om för att börja samla in spårningen med värdnamnsfiltret på plats, så att endast Azure Storage-nätverkstrafik ingår i spårningen.

Mer information finns i Använda nätverksspårningsfunktioner på Technet.

Granska måttdata i Azure Portal

När programmet har körts under en viss tidsperiod kan du granska måttdiagrammen som visas i Azure Portal för att se hur tjänsten har presterat.

Gå först till ditt lagringskonto i Azure Portal. Som standard visas ett övervakningsdiagram med måttet Lyckades i procent på kontobladet. Om du tidigare har ändrat diagrammet för att visa olika mått lägger du till måttet Lyckades i procent .

Nu visas procent för lyckade resultat i övervakningsdiagrammet, tillsammans med andra mått som du kan ha lagt till. I scenariot vi ska undersöka härnäst genom att analysera loggarna i Message Analyzer är andelen lyckade procent något lägre än 100 %.

Mer information om hur du lägger till och anpassar måttdiagram finns i Anpassa måttdiagram.

Använda AzCopy för att kopiera serverloggar till en lokal katalog

Azure Storage skriver serverloggdata till blobar medan mått skrivs till tabeller. Loggblobar är tillgängliga i den välkända $logs containern för ditt lagringskonto. Loggblobar namnges hierarkiskt efter år, månad, dag och timme, så att du enkelt kan hitta det tidsintervall som du vill undersöka. I kontot är https://storagesample.blob.core.windows.net/$logs/blob/2015/01/08/0800till exempel storagesample containern för loggblobbarna för 2015-01-02 från 08:00 till 09:00 . De enskilda blobarna i den här containern namnges sekventiellt, från och med 000000.log.

Du kan använda kommandoradsverktyget AzCopy för att ladda ned loggfilerna på serversidan till valfri plats på den lokala datorn. Du kan till exempel använda följande kommando för att ladda ned loggfilerna för blobåtgärder som ägde rum den 2 januari 2015 till mappen C:\Temp\Logs\Server. Ersätt <storageaccountname> med namnet på ditt lagringskonto:

azcopy copy 'http://<storageaccountname>.blob.core.windows.net/$logs/blob/2015/01/02' 'C:\Temp\Logs\Server'  --recursive

AzCopy kan laddas ned på sidan Azure Downloads . Mer information om hur du använder AzCopy finns i Överföra data med Verktyget AzCopy Command-Line.

Mer information om hur du laddar ned loggar på serversidan finns i Ladda ned loggdata för Lagringsloggning.

Använda Microsoft Message Analyzer för att analysera loggdata

Microsoft Message Analyzer är ett verktyg för att samla in, visa och analysera protokollmeddelandetrafik, händelser och andra system- eller programmeddelanden i felsöknings- och diagnostikscenarier. Med Message Analyzer kan du också läsa in, aggregera och analysera data från loggfiler och sparade spårningsfiler. Mer information om Message Analyzer finns i Driftsguide för Microsoft Message Analyzer.

Message Analyzer innehåller tillgångar för Azure Storage som hjälper dig att analysera server-, klient- och nätverksloggar. I det här avsnittet diskuterar vi hur du använder dessa verktyg för att åtgärda problemet med låg procents framgång i lagringsloggarna.

Ladda ned och installera Message Analyzer och Azure Storage-tillgångarna

1. Ladda ned Message Analyzer.
2. Starta Message Analyzer.
3. På menyn Verktyg väljer du Tillgångshanteraren. I dialogrutan Tillgångshanteraren väljer du Nedladdningar och filtrerar sedan på Azure Storage. Du ser Azure Storage-tillgångarna enligt bilden nedan.
4. Klicka på Synkronisera alla objekt som visas för att installera Azure Storage-tillgångarna. Bland de tillgängliga tillgångarna finns:
   • Färgregler för Azure Storage: Med Azure Storage-färgregler kan du definiera särskilda filter som använder färg-, text- och teckensnittsformat för att markera meddelanden som innehåller specifik information i en spårning.
   • Azure Storage-diagram: Azure Storage-diagram är fördefinierade diagram som grafserverloggdata. Observera att om du vill använda Azure Storage-diagram just nu kan du bara läsa in serverloggen i Analysis Grid.
   • Azure Storage-parsers: Azure Storage-parsarna parsar Azure Storage-klienten, servern och HTTP-loggarna för att visa dem i Analysis Grid.
   • Azure Storage-filter: Azure Storage-filter är fördefinierade kriterier som du kan använda för att köra frågor mot dina data i Analysis Grid.
   • Vylayouter för Azure Storage: Azure Storage-vylayouter är fördefinierade kolumnlayouter och grupperingar i Analysis Grid.
5. Starta om Message Analyzer när du har installerat tillgångarna.

Importera dina loggfiler till Message Analyzer

Du kan importera alla dina sparade loggfiler (serversidan, klientsidan och nätverket) till en enda session i Microsoft Message Analyzer för analys.

1. På Arkiv-menyn i Microsoft Message Analyzer klickar du på Ny session och sedan på Tom session. I dialogrutan Ny session anger du ett namn för din analyssession. I panelen Sessionsinformation klickar du på knappen Filer .
2. Om du vill läsa in nätverksspårningsdata som genererats av Message Analyzer klickar du på Lägg till filer, bläddrar till den plats där du sparade matp-filen från webbspårningssessionen, väljer matp-filen och klickar på Öppna.
3. Om du vill läsa in loggdata på serversidan klickar du på Lägg till filer, bläddrar till den plats där du laddade ned loggarna på serversidan, väljer loggfilerna för det tidsintervall som du vill analysera och klickar på Öppna. I panelen Sessionsinformation anger du sedan listrutan Konfiguration av textlogg för varje loggfil på serversidan till AzureStorageLog för att säkerställa att Microsoft Message Analyzer kan parsa loggfilen korrekt.
4. Om du vill läsa in loggdata på klientsidan klickar du på Lägg till filer, bläddrar till den plats där du sparade loggarna på klientsidan, väljer de loggfiler som du vill analysera och klickar på Öppna. I panelen Sessionsinformation anger du sedan listrutan Konfiguration av textlogg för varje loggfil på klientsidan till AzureStorageClientDotNetV4 för att säkerställa att Microsoft Message Analyzer kan parsa loggfilen korrekt.
5. Klicka på Start i dialogrutan Ny session för att läsa in och parsa loggdata. Loggdata visas i Analysrutnätet för meddelandeanalys.

Bilden nedan visar en exempelsession som konfigurerats med server-, klient- och nätverksspårningsloggfiler.

Observera att Message Analyzer läser in loggfiler i minnet. Om du har en stor uppsättning loggdata bör du filtrera dem för att få bästa möjliga prestanda från Message Analyzer.

Bestäm först tidsramen som du är intresserad av att granska och håll den här tidsramen så liten som möjligt. I många fall vill du granska en period av minuter eller timmar som mest. Importera den minsta uppsättningen loggar som kan uppfylla dina behov.

Om du fortfarande har en stor mängd loggdata kanske du vill ange ett sessionsfilter för att filtrera dina loggdata innan du läser in dem. I rutan Sessionsfilter väljer du knappen Bibliotek för att välja ett fördefinierat filter. Välj till exempel Globalt tidsfilter I från Azure Storage-filtren för att filtrera efter ett tidsintervall. Du kan sedan redigera filtervillkoren för att ange start- och sluttidsstämpeln för det intervall som du vill se. Du kan också filtrera på en viss statuskod. Du kan till exempel välja att endast läsa in loggposter där statuskoden är 404.

Mer information om hur du importerar loggdata till Microsoft Message Analyzer finns i Hämta meddelandedata på TechNet.

Använd klientbegärans-ID:t för att korrelera loggfilsdata

Azure Storage-klientbiblioteket genererar automatiskt ett unikt klientbegärande-ID för varje begäran. Det här värdet skrivs till klientloggen, serverloggen och nätverksspårningen, så att du kan använda det för att korrelera data i alla tre loggarna i Message Analyzer. Mer information om klientbegäran-ID finns i Klientbegäran-ID .

I avsnitten nedan beskrivs hur du använder förkonfigurerade och anpassade layoutvyer för att korrelera och gruppera data baserat på klientens begärande-ID.

Välj en vylayout som ska visas i Analysis Grid

Storage Assets for Message Analyzer innehåller Azure Storage View Layouts, som är förkonfigurerade vyer som du kan använda för att visa dina data med användbara grupperingar och kolumner för olika scenarier. Du kan också skapa anpassade vylayouter och spara dem för återanvändning.

Bilden nedan visar menyn Visa layout , som är tillgänglig genom att välja Visa layout i menyfliksområdet i verktygsfältet. Vylayouterna för Azure Storage grupperas under Noden Azure Storage på menyn. Du kan söka efter i sökrutan för Azure Storage att endast filtrera på Azure Storage-vylayouter. Du kan också välja star bredvid en vylayout för att göra den till en favorit och visa den överst på menyn.

Börja med genom att välja Grupperad efter ClientRequestID och Module. Den här vylayouten grupperar loggdata från alla tre loggarna först efter klientbegärans-ID, sedan efter källloggfilen (eller modulen i Message Analyzer). Med den här vyn kan du öka detaljnivån till ett visst klientbegärans-ID och se data från alla tre loggfilerna för det klientbegärande-ID:t.

Bilden nedan visar den här layoutvyn som tillämpas på exempelloggdata, med en delmängd kolumner som visas. Du kan se att Analysis Grid för ett visst klientbegärande-ID visar data från klientloggen, serverloggen och nätverksspårningen.

Förutom att använda Azure Storage-vylayouter kan du även definiera och spara dina egna vylayouter. Du kan välja andra önskade fält för att gruppera data och spara grupperingen som en del av din anpassade layout.

Tillämpa färgregler på Analysis Grid

Lagringstillgångarna innehåller också färgregler, som erbjuder ett visuellt sätt att identifiera olika typer av fel i Analysis Grid. De fördefinierade färgreglerna gäller för HTTP-fel, så de visas bara för serverloggen och nätverksspårningen.

Om du vill tillämpa färgregler väljer du Färgregler i menyfliksområdet i verktygsfältet. Du ser Färgregler för Azure Storage på menyn. I självstudien väljer du Klientfel (StatusKod mellan 400 och 499) enligt bilden nedan.

Förutom att använda Färgregler i Azure Storage kan du även definiera och spara dina egna färgregler.

Gruppera och filtrera loggdata för att hitta fel med 400 intervall

Därefter ska vi gruppera och filtrera loggdata för att hitta alla fel i intervallet 400.

1. Leta upp kolumnen StatusCode i Analysis Grid, högerklicka på kolumnrubriken och välj Grupp.

2. Gruppera sedan kolumnen ClientRequestId . Du ser att data i Analysis Grid nu är ordnade efter statuskod och efter klientbegärans-ID.

3. Visa verktygsfönstret Visa filter om det inte redan visas. I menyfliksområdet i verktygsfältet väljer du Verktyg Windows och sedan Visa filter.

4. Om du bara vill filtrera loggdata så att de endast visar fel med 400 intervall lägger du till följande filtervillkor i fönstret Visa filter och klickar på Använd:

   (AzureStorageLog.StatusCode >= 400 && AzureStorageLog.StatusCode <=499) || (HTTP.StatusCode >= 400 && HTTP.StatusCode <= 499)

Bilden nedan visar resultatet av den här gruppering och filtret. Om du expanderar fältet ClientRequestID under gruppering för statuskod 409 visas till exempel en åtgärd som resulterade i statuskoden.

När du har tillämpat det här filtret ser du att rader från klientloggen undantas, eftersom klientloggen inte innehåller någon StatusCode-kolumn . Till att börja med granskar vi server- och nätverksspårningsloggarna för att hitta 404-fel. Sedan går vi tillbaka till klientloggen för att undersöka klientåtgärderna som ledde till dem.

Filtrera loggdata för att hitta 404-fel

Lagringstillgångarna innehåller fördefinierade filter som du kan använda för att begränsa loggdata för att hitta de fel eller trender som du letar efter. Därefter tillämpar vi två fördefinierade filter: ett som filtrerar server- och nätverksspårningsloggarna för 404-fel och ett som filtrerar data efter ett angivet tidsintervall.

1. Visa verktygsfönstret Visa filter om det inte redan visas. I menyfliksområdet i verktygsfältet väljer du Verktyg Windows och sedan Visa filter.

2. I fönstret Visa filter väljer du Bibliotek och söker efter Azure Storage Azure Storage-filtren. Välj filtret för 404 meddelanden (hittades inte) i alla loggar.

3. Visa biblioteksmenyn igen och leta upp och välj det globala tidsfiltret.

4. Redigera de tidsstämplar som visas i filtret till det intervall som du vill visa. Detta hjälper till att begränsa mängden data som ska analyseras.

5. Filtret bör se ut ungefär som i exemplet nedan. Klicka på Använd för att tillämpa filtret på Analysis Grid.

   ((AzureStorageLog.StatusCode == 404 || HTTP.StatusCode == 404)) And (#Timestamp >= 2014-10-20T16:36:38 and #Timestamp <= 2014-10-20T16:36:39)

   

Analysera dina loggdata

Nu när du har grupperat och filtrerat dina data kan du granska information om enskilda begäranden som genererade 404-fel. I den aktuella vylayouten grupperas data efter klientbegärans-ID och sedan efter loggkälla. Eftersom vi filtrerar på begäranden där fältet StatusCode innehåller 404 ser vi bara server- och nätverksspårningsdata, inte klientloggdata.

Bilden nedan visar en specifik begäran där en Get Blob-åtgärd gav 404 eftersom bloben inte fanns. Observera att vissa kolumner har tagits bort från standardvyn för att kunna visa relevanta data.

Därefter korrelerar vi det här klientbegärans-ID:t med klientloggdata för att se vilka åtgärder klienten vidtog när felet inträffade. Du kan visa en ny Analysis Grid-vy för den här sessionen för att visa klientloggdata, som öppnas på en andra flik:

1. Kopiera först värdet för fältet ClientRequestId till Urklipp. Du kan göra detta genom att välja någon av raderna, hitta fältet ClientRequestId , högerklicka på datavärdet och välja Kopiera ClientRequestId.

2. I menyfliksområdet i verktygsfältet väljer du Nytt visningsprogram och sedan Analysis Grid för att öppna en ny flik. På den nya fliken visas alla data i loggfilerna, utan gruppering, filtrering eller färgregler.

3. I menyfliksområdet i verktygsfältet väljer du Visa layout och sedan Alla .NET-klientkolumner under avsnittet Azure Storage . Den här vylayouten visar data från klientloggen samt server- och nätverksspårningsloggarna. Som standard sorteras den i kolumnen MessageNumber .

4. Sök sedan i klientloggen efter klientbegärans-ID. I menyfliksområdet i verktygsfältet väljer du Sök meddelanden och anger sedan ett anpassat filter för klientbegärans-ID:t i fältet Sök . Använd den här syntaxen för filtret och ange ditt eget klientbegärande-ID:

   *ClientRequestId == "398bac41-7725-484b-8a69-2a9e48fc669a"

Message Analyzer letar upp och väljer den första loggposten där sökvillkoren matchar klientens begärande-ID. I klientloggen finns det flera poster för varje klientbegärans-ID, så du kanske vill gruppera dem i fältet ClientRequestId för att göra det enklare att se dem tillsammans. Bilden nedan visar alla meddelanden i klientloggen för det angivna klientbegärande-ID:t.

Med hjälp av de data som visas i vylayouterna på dessa två flikar kan du analysera begärandedata för att avgöra vad som kan ha orsakat felet. Du kan också titta på begäranden som föregick den här för att se om en tidigare händelse kan ha lett till 404-felet. Du kan till exempel granska klientloggposterna före detta klientbegärans-ID för att avgöra om bloben kan ha tagits bort eller om felet berodde på att klientprogrammet anropade ett CreateIfNotExists-API på en container eller blob. I klientloggen hittar du blobens adress i fältet Beskrivning . i server- och nätverksspårningsloggarna visas den här informationen i fältet Sammanfattning .

När du känner till adressen för bloben som gav 404-felet kan du undersöka vidare. Om du söker i loggposterna efter andra meddelanden som är associerade med åtgärder på samma blob kan du kontrollera om klienten tidigare har tagit bort entiteten.

Analysera andra typer av lagringsfel

Nu när du är bekant med att använda Message Analyzer för att analysera dina loggdata kan du analysera andra typer av fel med hjälp av vylayouter, färgregler och sökning/filtrering. I tabellerna nedan visas några problem som kan uppstå och de filtervillkor som du kan använda för att hitta dem. Mer information om hur du skapar filter och filtreringsspråket Message Analyzer finns i Filtrera meddelandedata.

Nästa steg

Mer information om hur du felsöker scenarier från slutpunkt till slutpunkt i Azure Storage finns i följande resurser:

• Övervaka, diagnostisera och felsök Microsoft Azure Storage
• Lagringsanalys
• Övervaka ett lagringskonto i Azure-portalen
• Överföra data med kommandoradsverktyget AzCopy
• Microsoft Message Analyzer – användningsguide