End-to-end-probleemoplossing op basis van metrische gegevens en logboekregistratie van Azure Storage, AzCopy en Message Analyzer

Diagnose en probleemoplossing is een belangrijke vaardigheid voor het bouwen en ondersteunen van clienttoepassingen met Microsoft Azure Storage. Vanwege de gedistribueerde aard van een Azure-toepassing kan het diagnosticeren en oplossen van fouten en prestatieproblemen complexer zijn dan in traditionele omgevingen.

In deze zelfstudie laten we zien hoe u bepaalde fouten kunt identificeren die van invloed kunnen zijn op de prestaties en hoe u deze fouten end-to-end kunt oplossen met behulp van hulpprogramma's van Microsoft en Azure Storage om de clienttoepassing te optimaliseren.

Deze zelfstudie biedt een praktijkgerichte verkenning van een end-to-end probleemoplossingsscenario. Zie Microsoft Azure Storage bewaken, diagnosticeren en problemen oplossen voor een uitgebreide conceptuele handleiding voor het oplossen van problemen met Azure Storage-toepassingen.

Hulpprogramma's voor het oplossen van problemen met Azure Storage-toepassingen

Als u problemen met clienttoepassingen wilt oplossen met Microsoft Azure Storage, kunt u een combinatie van hulpprogramma's gebruiken om te bepalen wanneer een probleem is opgetreden en wat de oorzaak van het probleem kan zijn. Tot deze hulpmiddelen behoren onder meer:

• Azure Opslaganalyse. Azure Opslaganalyse biedt metrische gegevens en logboekregistratie voor Azure Storage.

  • Metrische opslaggegevens houden metrische gegevens over transacties en capaciteit bij voor uw opslagaccount. Met behulp van metrische gegevens kunt u bepalen hoe uw toepassing presteert op basis van verschillende metingen. Zie Opslaganalyse Schema van metrische gegevenstabel voor meer informatie over de typen metrische gegevens die door Opslaganalyse worden bijgehouden.
  • Logboekregistratie van opslag registreert elke aanvraag bij de Azure Storage-services naar een logboek aan de serverzijde. In het logboek worden gedetailleerde gegevens bijgehouden voor elke aanvraag, inclusief de uitgevoerde bewerking, de status van de bewerking en latentiegegevens. Zie Opslaganalyse Logboekindeling voor meer informatie over de aanvraag- en antwoordgegevens die door Opslaganalyse naar de logboeken worden geschreven.

• Azure-portal. U kunt metrische gegevens en logboekregistratie voor uw opslagaccount configureren in de Azure Portal. U kunt ook grafieken en grafieken weergeven die laten zien hoe uw toepassing in de loop van de tijd presteert en waarschuwingen configureren om u te waarschuwen als uw toepassing anders presteert dan verwacht voor een opgegeven metrische waarde.

  Zie Een opslagaccount bewaken in de Azure Portal voor informatie over het configureren van bewaking in de Azure Portal.

• AzCopy. Serverlogboeken voor Azure Storage worden opgeslagen als blobs, zodat u AzCopy kunt gebruiken om de logboekblobs te kopiëren naar een lokale map voor analyse met behulp van Microsoft Message Analyzer. Zie Gegevens overdragen met het hulpprogramma AzCopy Command-Line voor meer informatie over AzCopy.

• Microsoft Message Analyzer. Message Analyzer is een hulpprogramma dat logboekbestanden verbruikt en logboekgegevens weergeeft in een visuele indeling waarmee u logboekgegevens eenvoudig kunt filteren, zoeken en groepeert in nuttige sets die u kunt gebruiken om fouten en prestatieproblemen te analyseren. Zie Microsoft Message Analyzer-bedieningshandleiding voor meer informatie over Message Analyzer.

Over het voorbeeldscenario

Voor deze zelfstudie onderzoeken we een scenario waarin metrische gegevens van Azure Storage een laag slagingspercentage aangeeft voor een toepassing die Azure Storage aanroept. Met de metrische waarde voor het succespercentage laag percentage (weergegeven als PercentageSuccess in de Azure Portal en in de tabellen met metrische gegevens) worden bewerkingen bijgehouden die slagen, maar die een HTTP-statuscode retourneren die groter is dan 299. In de opslaglogboekbestanden aan de serverzijde worden deze bewerkingen vastgelegd met de transactiestatus ClientOtherErrors. Zie Metrics show low PercentSuccess or analytics log entries have bewerkingen with transaction status of ClientOtherErrors (Metrische gegevens tonen laag percentage succes) voor meer informatie over de metrische waarde voor laag succes.

Azure Storage-bewerkingen kunnen HTTP-statuscodes retourneren die groter zijn dan 299 als onderdeel van hun normale functionaliteit. Maar deze fouten geven in sommige gevallen aan dat u uw clienttoepassing mogelijk kunt optimaliseren voor verbeterde prestaties.

In dit scenario wordt een laag slagingspercentage beschouwd als iets lager dan 100%. U kunt echter een ander metrische niveau kiezen, afhankelijk van uw behoeften. We raden u aan om tijdens het testen van uw toepassing een basislijntolerantie vast te stellen voor uw belangrijkste metrische prestatiegegevens. U kunt bijvoorbeeld op basis van tests bepalen dat uw toepassing een consistent slagingspercentage van 90% of 85% moet hebben. Als uit uw metrische gegevens blijkt dat de toepassing van dat aantal afwijkt, kunt u onderzoeken waardoor de toename mogelijk wordt veroorzaakt.

Voor ons voorbeeldscenario, zodra we hebben vastgesteld dat het metrische percentage slagingspercentage lager is dan 100%, onderzoeken we de logboeken om de fouten te vinden die overeenkomen met de metrische gegevens en gebruiken we deze om erachter te komen wat de oorzaak is van het lagere slagingspercentage. We kijken specifiek naar fouten in het bereik 400. Vervolgens gaan we 404-fouten (niet gevonden) nader onderzoeken.

Enkele oorzaken van 400-bereikfouten

In de onderstaande voorbeelden ziet u een steekproef van zo'n 400-bereikfouten voor aanvragen voor Azure Blob Storage en de mogelijke oorzaken ervan. Al deze fouten, evenals fouten in het bereik van 300 en 500, kunnen bijdragen aan een laag slagingspercentage.

Houd er rekening mee dat de onderstaande lijsten verre van volledig zijn. Zie Status- en foutcodes op MSDN voor meer informatie over algemene Azure Storage-fouten en over fouten die specifiek zijn voor elk van de opslagservices.

Voorbeelden van statuscode 404 (niet gevonden)

Treedt op wanneer een leesbewerking voor een container of blob mislukt omdat de blob of container niet is gevonden.

• Treedt op als een container of blob vóór deze aanvraag door een andere client is verwijderd.
• Treedt op als u een API-aanroep gebruikt waarmee de container of blob wordt gemaakt nadat u hebt gecontroleerd of deze bestaat. De CreateIfNotExists-API's voeren eerst een HEAD-aanroep uit om te controleren of de container of blob bestaat. Als deze niet bestaat, wordt een 404-fout geretourneerd en wordt er een tweede PUT-aanroep uitgevoerd om de container of blob te schrijven.

Voorbeelden van statuscode 409 (conflict)

• Treedt op als u een Create-API gebruikt om een nieuwe container of blob te maken, zonder eerst te controleren of er een container of blob met die naam bestaat.
• Treedt op als een container wordt verwijderd en u probeert een nieuwe container met dezelfde naam te maken voordat de verwijderingsbewerking is voltooid.
• Treedt op als u een lease opgeeft voor een container of blob en er al een lease aanwezig is.

Voorbeelden van statuscode 412 (voorwaarde mislukt)

• Treedt op wanneer niet is voldaan aan de voorwaarde die is opgegeven door een voorwaardelijke header.
• Treedt op wanneer de opgegeven lease-id niet overeenkomt met de lease-id in de container of blob.

Logboekbestanden genereren voor analyse

In deze zelfstudie gebruiken we Message Analyzer om te werken met drie verschillende typen logboekbestanden, hoewel u ervoor kunt kiezen om met een van deze bestanden te werken:

• Het serverlogboek, dat wordt gemaakt wanneer u Azure Storage-logboekregistratie inschakelt. Het serverlogboek bevat gegevens over elke bewerking die wordt aangeroepen op basis van een van de Azure Storage-services: blob, wachtrij, tabel en bestand. In het serverlogboek wordt aangegeven welke bewerking is aangeroepen en welke statuscode is geretourneerd, evenals andere details over de aanvraag en het antwoord.
• Het .NET-clientlogboek, dat wordt gemaakt wanneer u logboekregistratie aan de clientzijde inschakelt vanuit uw .NET-toepassing. Het clientlogboek bevat gedetailleerde informatie over hoe de client de aanvraag voorbereidt en het antwoord ontvangt en verwerkt.
• Het HTTP-netwerktraceringslogboek, dat gegevens verzamelt op HTTP/HTTPS-aanvraag- en antwoordgegevens, inclusief voor bewerkingen met Azure Storage. In deze zelfstudie genereren we de netwerktracering via Message Analyzer.

Logboekregistratie en metrische gegevens aan de serverzijde configureren

Eerst moeten we logboekregistratie en metrische gegevens van Azure Storage configureren, zodat we gegevens van de servicezijde kunnen analyseren. U kunt logboekregistratie en metrische gegevens op verschillende manieren configureren: via de Azure Portal, met behulp van PowerShell of programmatisch. Zie Metrische gegevens inschakelen en Logboekregistratie inschakelen voor meer informatie over het configureren van logboekregistratie en metrische gegevens.

Logboekregistratie aan de .NET-clientzijde configureren

Als u logboekregistratie aan de clientzijde wilt configureren voor een .NET-toepassing, schakelt u .NET-diagnostische gegevens in in het configuratiebestand van de toepassing (web.config of app.config). Zie Logboekregistratie aan clientzijde met de .NET Storage-clientbibliotheek en Logboekregistratie aan de clientzijde met de Microsoft Azure Storage SDK voor Java op MSDN voor meer informatie.

Het logboek aan de clientzijde bevat gedetailleerde informatie over hoe de client de aanvraag voorbereidt en het antwoord ontvangt en verwerkt.

De Storage-clientbibliotheek slaat logboekgegevens aan de clientzijde op op de locatie die is opgegeven in het configuratiebestand van de toepassing (web.config of app.config).

Een netwerktracering verzamelen

U kunt Message Analyzer gebruiken om een HTTP/HTTPS-netwerktracering te verzamelen terwijl uw clienttoepassing wordt uitgevoerd. Message Analyzer gebruikt Fiddler op de back-end. Voordat u de netwerktracering verzamelt, raden we u aan Fiddler te configureren om niet-versleuteld HTTPS-verkeer vast te leggen:

1. Installeer Fiddler.
2. Start Fiddler.
3. Selecteer Extra | Fiddler-opties.
4. Controleer in het dialoogvenster Opties of HTTPS-VERBINDINGEN vastleggen en HTTPS-verkeer ontsleutelen beide zijn geselecteerd, zoals hieronder wordt weergegeven.

Voor de zelfstudie verzamelt en slaat u eerst een netwerktracering op in Message Analyzer en maakt u vervolgens een analysesessie om de tracering en de logboeken te analyseren. Een netwerktracering verzamelen in Message Analyzer:

1. Selecteer in Message Analyzer Bestand | Snelle tracering | Niet-versleutelde HTTPS.

2. De tracering wordt onmiddellijk gestart. Selecteer Stoppen om de tracering te stoppen, zodat we deze kunnen configureren om alleen opslagverkeer te traceren.

3. Selecteer Bewerken om de traceringssessie te bewerken.

4. Selecteer de koppeling Configureren rechts van de Microsoft-Pef-WebProxy ETW-provider .

5. Klik in het dialoogvenster Geavanceerde instellingen op het tabblad Provider .

6. Geef in het veld Hostnaamfilter uw opslageindpunten op, gescheiden door spaties. U kunt bijvoorbeeld uw eindpunten als volgt opgeven; wijzig storagesample in de naam van uw opslagaccount:

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

7. Sluit het dialoogvenster en klik op Opnieuw opstarten om de tracering te verzamelen met het hostnaamfilter, zodat alleen Azure Storage-netwerkverkeer wordt opgenomen in de tracering.

Zie De functies voor netwerktracering op Technet gebruiken voor meer informatie.

Metrische gegevens in de Azure Portal controleren

Zodra uw toepassing gedurende een bepaalde periode wordt uitgevoerd, kunt u de grafieken met metrische gegevens bekijken die worden weergegeven in de Azure Portal om te zien hoe uw service presteert.

Navigeer eerst naar uw opslagaccount in de Azure Portal. Standaard wordt een bewakingsgrafiek met de metrische waarde Geslaagd percentage weergegeven op de accountblade. Als u de grafiek eerder hebt gewijzigd om verschillende metrische gegevens weer te geven, voegt u de metrische waarde Succespercentage toe.

U ziet nu succespercentage in de bewakingsgrafiek, samen met andere metrische gegevens die u mogelijk hebt toegevoegd. In het scenario dat we hierna onderzoeken door de logboeken in Message Analyzer te analyseren, ligt het slagingspercentage iets onder de 100%.

Zie Grafieken met metrische gegevens aanpassen voor meer informatie over het toevoegen en aanpassen van grafieken met metrische gegevens.

AzCopy gebruiken om serverlogboeken naar een lokale map te kopiëren

Azure Storage schrijft serverlogboekgegevens naar blobs, terwijl metrische gegevens naar tabellen worden geschreven. Logboek-blobs zijn beschikbaar in de bekende $logs container voor uw opslagaccount. Logboekblobs hebben een hiërarchische naam per jaar, maand, dag en uur, zodat u eenvoudig het tijdsbereik kunt vinden dat u wilt onderzoeken. In het storagesample account is https://storagesample.blob.core.windows.net/$logs/blob/2015/01/08/0800de container voor de logboekblobs voor 01-02-2015, van 8-9 uur, bijvoorbeeld . De afzonderlijke blobs in deze container worden opeenvolgend benoemd, te beginnen met 000000.log.

U kunt het opdrachtregelprogramma AzCopy gebruiken om deze logboekbestanden aan de serverzijde te downloaden naar een locatie naar keuze op uw lokale computer. U kunt bijvoorbeeld de volgende opdracht gebruiken om de logboekbestanden voor blobbewerkingen die plaatsvonden op 2 januari 2015 naar de map C:\Temp\Logs\Serverte downloaden; vervang door <storageaccountname> de naam van uw opslagaccount:

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

AzCopy kan worden gedownload op de pagina Azure-downloads . Zie Gegevens overdragen met het hulpprogramma AzCopy Command-Line voor meer informatie over het gebruik van AzCopy.

Zie Logboekgegevens voor opslaglogboeken downloaden voor meer informatie over het downloaden van logboeken aan de serverzijde.

Microsoft Message Analyzer gebruiken om logboekgegevens te analyseren

Microsoft Message Analyzer is een hulpprogramma voor het vastleggen, weergeven en analyseren van protocolberichtenverkeer, gebeurtenissen en andere systeem- of toepassingsberichten in probleemoplossings- en diagnostische scenario's. Met Message Analyzer kunt u ook gegevens uit logboek- en opgeslagen traceringsbestanden laden, aggregeren en analyseren. Zie Microsoft Message Analyzer Operating Guide (Bedieningshandleiding voor Microsoft Message Analyzer) voor meer informatie over Message Analyzer.

Message Analyzer bevat assets voor Azure Storage waarmee u server-, client- en netwerklogboeken kunt analyseren. In deze sectie wordt besproken hoe u deze hulpprogramma's kunt gebruiken om het probleem van een laag percentage succes in de opslaglogboeken op te lossen.

Message Analyzer en de Azure Storage-assets downloaden en installeren

1. Download Message Analyzer.
2. Start Message Analyzer.
3. Selecteer Asset Manager in het menu Extra. Selecteer downloads in het dialoogvenster Asset Manager en filter vervolgens op Azure Storage. U ziet de Azure Storage-assets, zoals wordt weergegeven in de onderstaande afbeelding.
4. Klik op Alle weergegeven items synchroniseren om de Azure Storage-assets te installeren. De beschikbare assets zijn onder andere:
   • Kleurregels voor Azure Storage: Met kleurregels van Azure Storage kunt u speciale filters definiëren die gebruikmaken van kleur-, tekst- en lettertypestijlen om berichten te markeren die specifieke informatie in een trace bevatten.
   • Azure Storage-grafieken: Azure Storage-grafieken zijn vooraf gedefinieerde grafieken waarmee serverlogboekgegevens worden weergegeven. Als u op dit moment Azure Storage-grafieken wilt gebruiken, mag u alleen het serverlogboek in analysis grid laden.
   • Azure Storage-parsers: De Azure Storage-parsers parseren de Azure Storage-client- en -server- en HTTP-logboeken om ze weer te geven in het Analysis Grid.
   • Azure Storage-filters: Azure Storage-filters zijn vooraf gedefinieerde criteria die u kunt gebruiken om query's uit te voeren op uw gegevens in analysis grid.
   • Azure Storage-weergave-indelingen: Azure Storage-weergave-indelingen zijn vooraf gedefinieerde kolomindelingen en groeperingen in het Analysis Grid.
5. Start Message Analyzer opnieuw nadat u de assets hebt geïnstalleerd.

Uw logboekbestanden importeren in Message Analyzer

U kunt al uw opgeslagen logboekbestanden (serverzijde, clientzijde en netwerk) importeren in één sessie in Microsoft Message Analyzer voor analyse.

1. Klik in het menu Bestand in Microsoft Message Analyzer op Nieuwe sessie en klik vervolgens op Lege sessie. Voer in het dialoogvenster Nieuwe sessie een naam in voor uw analysesessie. Klik in het deelvenster Sessiedetails op de knop Bestanden .
2. Als u de netwerktraceringsgegevens wilt laden die door Message Analyzer zijn gegenereerd, klikt u op Bestanden toevoegen, bladert u naar de locatie waar u het MATP-bestand hebt opgeslagen vanuit uw webtraceringssessie, selecteert u het .matp-bestand en klikt u op Openen.
3. Als u de logboekgegevens aan de serverzijde wilt laden, klikt u op Bestanden toevoegen, bladert u naar de locatie waar u de logboeken aan de serverzijde hebt gedownload, selecteert u de logboekbestanden voor het tijdsbereik dat u wilt analyseren en klikt u op Openen. Stel vervolgens in het deelvenster Sessiedetails de vervolgkeuzelijst Configuratie van tekstlogboek voor elk logboekbestand aan de serverzijde in op AzureStorageLog om ervoor te zorgen dat Microsoft Message Analyzer het logboekbestand correct kan parseren.
4. Als u de logboekgegevens aan de clientzijde wilt laden, klikt u op Bestanden toevoegen, bladert u naar de locatie waar u de logboeken aan de clientzijde hebt opgeslagen, selecteert u de logboekbestanden die u wilt analyseren en klikt u op Openen. Stel vervolgens in het deelvenster Sessiedetails de vervolgkeuzelijst Configuratie van tekstlogboek voor elk logboekbestand aan de clientzijde in op AzureStorageClientDotNetV4 om ervoor te zorgen dat Microsoft Message Analyzer het logboekbestand correct kan parseren.
5. Klik op Start in het dialoogvenster Nieuwe sessie om de logboekgegevens te laden en te parseren. De logboekgegevens worden weergegeven in het Message Analyzer Analysis Grid.

In de onderstaande afbeelding ziet u een voorbeeldsessie die is geconfigureerd met logboekbestanden voor server, client en netwerktracering.

Houd er rekening mee dat Message Analyzer logboekbestanden in het geheugen laadt. Als u een grote set logboekgegevens hebt, wilt u deze filteren om de beste prestaties van Message Analyzer te krijgen.

Bepaal eerst het tijdsbestek dat u wilt beoordelen en houd dit tijdsbestek zo klein mogelijk. In veel gevallen wilt u een periode van maximaal minuten of uren bekijken. Importeer de kleinste set logboeken die aan uw behoeften kunnen voldoen.

Als u nog steeds een grote hoeveelheid logboekgegevens hebt, kunt u een sessiefilter opgeven om uw logboekgegevens te filteren voordat u deze laadt. Selecteer in het vak Sessiefilter de knop Bibliotheek om een vooraf gedefinieerd filter te kiezen; Kies bijvoorbeeld Global Time Filter I in de Azure Storage-filters om te filteren op een tijdsinterval. Vervolgens kunt u de filtercriteria bewerken om de begin- en eindtijdstempel op te geven voor het interval dat u wilt zien. U kunt ook filteren op een bepaalde statuscode; U kunt er bijvoorbeeld voor kiezen om alleen logboekvermeldingen te laden waarvan de statuscode 404 is.

Zie Berichtgegevens ophalen op TechNet voor meer informatie over het importeren van logboekgegevens in Microsoft Message Analyzer.

De clientaanvraag-id gebruiken om logboekbestandsgegevens te correleren

De Azure Storage-clientbibliotheek genereert automatisch een unieke clientaanvraag-id voor elke aanvraag. Deze waarde wordt geschreven naar het clientlogboek, het serverlogboek en de netwerktracering, zodat u deze kunt gebruiken om gegevens in alle drie de logboeken in Message Analyzer te correleren. Zie Clientaanvraag-id voor meer informatie over de clientaanvraag-id.

In de onderstaande secties wordt beschreven hoe u vooraf geconfigureerde en aangepaste indelingsweergaven gebruikt om gegevens te correleren en groepeert op basis van de clientaanvraag-id.

Selecteer een weergave-indeling om weer te geven in het Analysis Grid

De opslagassets voor Message Analyzer bevatten indelingen voor Azure Storage-weergaven. Dit zijn vooraf geconfigureerde weergaven die u kunt gebruiken om uw gegevens weer te geven met nuttige groeperingen en kolommen voor verschillende scenario's. U kunt ook aangepaste weergave-indelingen maken en opslaan voor hergebruik.

In de onderstaande afbeelding ziet u het menu Weergave-indeling , dat beschikbaar is door Weergave-indeling te selecteren op het werkbalklint. De weergave-indelingen voor Azure Storage worden gegroepeerd onder het Azure Storage-knooppunt in het menu. U kunt zoeken Azure Storage naar in het zoekvak om alleen te filteren op Azure Storage-weergave-indelingen. U kunt ook de star naast een weergave-indeling selecteren om deze als favoriet te maken en deze bovenaan het menu weer te geven.

Selecteer eerst Gegroepeerd op ClientRequestID en Module. Deze weergave-indeling groepeert logboekgegevens uit alle drie de logboeken eerst op clientaanvraag-id en vervolgens op bronlogboekbestand (of module in Message Analyzer). Met deze weergave kunt u inzoomen op een bepaalde clientaanvraag-id en gegevens bekijken uit alle drie de logboekbestanden voor die clientaanvraag-id.

In de onderstaande afbeelding ziet u deze indelingsweergave die is toegepast op de voorbeeldlogboekgegevens, waarbij een subset van kolommen wordt weergegeven. U kunt zien dat voor een bepaalde clientaanvraag-id in analysis grid gegevens worden weergegeven uit het clientlogboek, het serverlogboek en de netwerktracering.

Naast het gebruik van de Weergave-indelingen van Azure Storage kunt u ook uw eigen weergave-indelingen definiëren en opslaan. U kunt andere gewenste velden selecteren voor het groeperen van gegevens en de groepering ook opslaan als onderdeel van uw aangepaste indeling.

Kleurregels toepassen op het analyseraster

De opslagassets bevatten ook kleurregels, die een visuele manier bieden om verschillende soorten fouten in het Analysis Grid te identificeren. De vooraf gedefinieerde kleurregels zijn van toepassing op HTTP-fouten, zodat ze alleen worden weergegeven voor het serverlogboek en de netwerktracering.

Als u kleurregels wilt toepassen, selecteert u Kleurregels op het werkbalklint. U ziet de Azure Storage-kleurregels in het menu. Selecteer voor de zelfstudie Clientfouten (StatusCode tussen 400 en 499), zoals wordt weergegeven in de onderstaande afbeelding.

Naast het gebruik van de Azure Storage-kleurregels kunt u ook uw eigen kleurregels definiëren en opslaan.

Logboekgegevens groepeer en filter deze om fouten met een bereik van 400 te vinden

Vervolgens groepeer en filtert u de logboekgegevens om alle fouten in het 400-bereik te vinden.

1. Zoek de kolom StatusCode in analysis grid, klik met de rechtermuisknop op de kolomkop en selecteer Groep.

2. Groepeer vervolgens op de kolom ClientRequestId . U ziet dat de gegevens in Analysis Grid nu zijn geordend op statuscode en op clientaanvraag-id.

3. Het venster Filter weergeven als dit nog niet wordt weergegeven. Selecteer op het werkbalklint Hulpprogramma Windows en vervolgens Filter weergeven.

4. Als u de logboekgegevens wilt filteren om alleen fouten van 400 bereiken weer te geven, voegt u de volgende filtercriteria toe aan het venster Filter weergeven en klikt u op Toepassen:

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

In de onderstaande afbeelding ziet u de resultaten van deze groepering en het filter. Als u bijvoorbeeld het veld ClientRequestID onder de groepering voor statuscode 409 uitbreidt, ziet u een bewerking die heeft geresulteerd in die statuscode.

Nadat u dit filter hebt toegepast, ziet u dat rijen uit het clientlogboek worden uitgesloten, omdat het clientlogboek geen kolom StatusCode bevat. Om te beginnen controleren we de server- en netwerktraceringslogboeken om 404-fouten te vinden. Vervolgens keren we terug naar het clientlogboek om de clientbewerkingen te onderzoeken die tot deze fouten hebben geleid.

Logboekgegevens filteren om 404-fouten te vinden

De opslagassets bevatten vooraf gedefinieerde filters die u kunt gebruiken om logboekgegevens te beperken om de fouten of trends te vinden die u zoekt. Vervolgens passen we twee vooraf gedefinieerde filters toe: één waarmee de server- en netwerktraceringslogboeken worden gefilterd op 404-fouten en één waarmee de gegevens in een opgegeven tijdsbereik worden gefilterd.

1. Het venster Filter weergeven als dit nog niet wordt weergegeven. Selecteer op het werkbalklint Hulpprogramma Windows en vervolgens Filter weergeven.

2. Selecteer in het venster Filter weergeven de optie Bibliotheek en zoek op Azure Storage om de Azure Storage-filters te vinden. Selecteer het filter voor 404 -berichten (niet gevonden) in alle logboeken.

3. Het menu Bibliotheek opnieuw weergeven en het globale tijdfilter zoeken en selecteren.

4. Bewerk de tijdstempels die in het filter worden weergegeven tot het bereik dat u wilt weergeven. Dit helpt bij het beperken van het gegevensbereik dat moet worden geanalyseerd.

5. Het filter moet er ongeveer uitzien als in het onderstaande voorbeeld. Klik op Toepassen om het filter toe te passen op analysis grid.

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

   

Uw logboekgegevens analyseren

Nu u uw gegevens hebt gegroepeerd en gefilterd, kunt u de details bekijken van afzonderlijke aanvragen die 404-fouten hebben gegenereerd. In de huidige weergave-indeling worden de gegevens gegroepeerd op clientaanvraag-id en vervolgens op logboekbron. Omdat we filteren op aanvragen waarbij het veld StatusCode 404 bevat, zien we alleen de traceringsgegevens van de server en het netwerk, niet de clientlogboekgegevens.

In de onderstaande afbeelding ziet u een specifieke aanvraag waarbij een get-blobbewerking een 404 opleverde omdat de blob niet bestond. Houd er rekening mee dat sommige kolommen zijn verwijderd uit de standaardweergave om de relevante gegevens weer te geven.

Vervolgens correleren we deze clientaanvraag-id met de clientlogboekgegevens om te zien welke acties de client ondernam toen de fout optreedt. U kunt een nieuwe Analysis Grid-weergave voor deze sessie weergeven om de clientlogboekgegevens weer te geven, die op een tweede tabblad wordt geopend:

1. Kopieer eerst de waarde van het veld ClientRequestId naar het klembord. U kunt dit doen door een van de rijen te selecteren, het veld ClientRequestId te zoeken, met de rechtermuisknop op de gegevenswaarde te klikken en 'ClientRequestId' kopiëren te kiezen.

2. Selecteer op het werkbalklint De optie Nieuwe viewer en selecteer vervolgens Analysis Grid om een nieuw tabblad te openen. Op het nieuwe tabblad worden alle gegevens in uw logboekbestanden weergegeven, zonder groeperings-, filter- of kleurregels.

3. Selecteer op het werkbalklint Indeling weergeven en selecteer vervolgens Alle .NET-clientkolommen in de sectie Azure Storage . In deze weergave-indeling worden gegevens uit het clientlogboek en de traceringslogboeken van de server en het netwerk weergegeven. Deze wordt standaard gesorteerd op de kolom MessageNumber .

4. Zoek vervolgens in het clientlogboek naar de clientaanvraag-id. Selecteer op het werkbalklint Berichten zoeken en geef vervolgens een aangepast filter op op de clientaanvraag-id in het veld Zoeken . Gebruik deze syntaxis voor het filter, waarbij u uw eigen clientaanvraag-id opgeeft:

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

Message Analyzer zoekt en selecteert de eerste logboekvermelding waarin de zoekcriteria overeenkomen met de aanvraag-id van de client. In het clientlogboek zijn er verschillende vermeldingen voor elke clientaanvraag-id, dus u kunt deze groeperen in het veld ClientRequestId om ze allemaal gemakkelijker te kunnen zien. In de onderstaande afbeelding ziet u alle berichten in het clientlogboek voor de opgegeven clientaanvraag-id.

Met behulp van de gegevens die worden weergegeven in de weergave-indelingen op deze twee tabbladen, kunt u de aanvraaggegevens analyseren om te bepalen wat de fout mogelijk heeft veroorzaakt. U kunt ook aanvragen bekijken die hieraan voorafgingen om te zien of een eerdere gebeurtenis mogelijk heeft geleid tot de 404-fout. U kunt bijvoorbeeld de vermeldingen in het clientlogboek vóór deze clientaanvraag-id controleren om te bepalen of de blob mogelijk is verwijderd of dat de fout wordt veroorzaakt doordat de clienttoepassing een CreateIfNotExists-API op een container of blob aanroept. In het clientlogboek vindt u het adres van de blob in het veld Beschrijving ; in de traceringslogboeken van de server en het netwerk wordt deze informatie weergegeven in het veld Samenvatting .

Zodra u het adres weet van de blob die de 404-fout heeft opgeleverd, kunt u verder onderzoeken. Als u in de logboekvermeldingen zoekt naar andere berichten die zijn gekoppeld aan bewerkingen in dezelfde blob, kunt u controleren of de client de entiteit eerder heeft verwijderd.

Andere typen opslagfouten analyseren

Nu u bekend bent met het gebruik van Message Analyzer om uw logboekgegevens te analyseren, kunt u andere typen fouten analyseren met behulp van weergave-indelingen, kleurregels en zoeken/filteren. De onderstaande tabellen bevatten een aantal problemen die u kunt tegenkomen en de filtercriteria die u kunt gebruiken om deze te vinden. Zie Berichtgegevens filteren voor meer informatie over het samenstellen van filters en de filtertaal Message Analyzer.

Onderzoeken...	Filterexpressie gebruiken...	Expressie is van toepassing op logboek (client, server, netwerk, alle)
Onverwachte vertragingen in de bezorging van berichten in een wachtrij	AzureStorageClientDotNetV4.Description bevat 'Mislukte bewerking opnieuw proberen'.	Client
HTTP-toename in PercentThrottlingError	HTTP. Response.StatusCode == 500 || HTTP. Response.StatusCode == 503	Netwerk
Toename in PercentTimeoutError	HTTP. Response.StatusCode == 500	Netwerk
Toename in PercentTimeoutError (alle)	*StatusCode == 500	Alles
Toename in PercentNetworkError	AzureStorageClientDotNetV4.EventLogEntry.Level < 2	Client
HTTP 403-berichten (verboden)	HTTP. Response.StatusCode == 403	Netwerk
HTTP 404-berichten (niet gevonden)	HTTP. Response.StatusCode == 404	Netwerk
404 (alle)	*StatusCode == 404	Alles
Een probleem met de verificatie van een SAS (Shared Access Signature)	AzureStorageLog.RequestStatus == "SASAuthorizationError"	Netwerk
HTTP 409-berichten (conflict)	HTTP. Response.StatusCode == 409	Netwerk
409 (alle)	*StatusCode == 409	Alles
Laag percentageSuccess- of analyselogboekvermeldingen hebben bewerkingen met de transactiestatus Van ClientOtherErrors	AzureStorageLog.RequestStatus == "ClientOtherError"	Server
Nagle-waarschuwing	((AzureStorageLog.EndToEndLatencyMS - AzureStorageLog.ServerLatencyMS) > (AzureStorageLog.ServerLatencyMS * 1.5)) en (AzureStorageLog.RequestPacketSize <1460) en (AzureStorageLog.EndToEndLatencyMS - AzureStorageLog.ServerLatencyMS >= 200)	Server
Tijdsbereik in server- en netwerklogboeken	>#Timestamp = 2014-10-20T16:36:38 en #Timestamp <= 2014-10-20T16:36:39	Server, netwerk
Tijdsbereik in serverlogboeken	AzureStorageLog.Timestamp >= 2014-10-20T16:36:38 en AzureStorageLog.Timestamp <= 2014-10-20T16:36:39	Server

Volgende stappen

Zie deze resources voor meer informatie over het oplossen van end-to-end-scenario's in Azure Storage:

• Microsoft Azure Storage bewaken, problemen opsporen en oplossen
• Storage Analytics
• Een Storage-account bewaken in de Azure-portal
• Gegevens overdragen met het AzCopy Command-Line-hulpprogramma
• Microsoft Message Analyzer Operating Guide (Operationele handleiding voor Microsoft Message Analyzer)