Delen via

Microsoft Azure Storage bewaken, diagnosticeren en problemen oplossen (klassiek)

  • Artikel

Deze handleiding laat zien hoe u functies zoals Azure Opslaganalyse, logboekregistratie aan de clientzijde in de Azure Storage-clientbibliotheek en andere hulpprogramma's van derden gebruikt om problemen met betrekking tot Azure Storage te identificeren, te diagnosticeren en op te lossen.

Diagram met de gegevensstroom tussen clienttoepassingen en Azure Storage-services.

Deze handleiding is bedoeld om voornamelijk te worden gelezen door ontwikkelaars van onlineservices die gebruikmaken van Azure Storage Services en IT-professionals die verantwoordelijk zijn voor het beheren van dergelijke onlineservices. De doelstellingen van deze handleiding zijn:

  • Om u te helpen de status en prestaties van uw Azure Storage-accounts te behouden.
  • Om u de benodigde processen en hulpprogramma's te bieden waarmee u kunt bepalen of een probleem of probleem in een toepassing betrekking heeft op Azure Storage.
  • Om u te voorzien van bruikbare richtlijnen voor het oplossen van problemen met betrekking tot Azure Storage.

Notitie

Dit artikel is gebaseerd op het gebruik van Opslaganalyse metrische gegevens en logboeken die worden aangeduid als klassieke metrische gegevens en logboeken. Het is raadzaam om metrische gegevens en logboeken van Azure Storage te gebruiken in Azure Monitor in plaats van Opslaganalyse logboeken. Zie een van de volgende artikelen voor meer informatie:

Overzicht

Het diagnosticeren en oplossen van problemen in een gedistribueerde toepassing die wordt gehost in een cloudomgeving kan complexer zijn dan in traditionele omgevingen. Toepassingen kunnen worden geïmplementeerd in een PaaS- of IaaS-infrastructuur, on-premises, op een mobiel apparaat of in een combinatie van deze omgevingen. Normaal gesproken kan het netwerkverkeer van uw toepassing openbare en persoonlijke netwerken passeren en kan uw toepassing gebruikmaken van meerdere opslagtechnologieën, zoals Microsoft Azure Storage Tables, Blobs, Queues of Files, naast andere gegevensarchieven, zoals relationele en documentdatabases.

Als u dergelijke toepassingen succesvol wilt beheren, moet u ze proactief bewaken en begrijpen hoe u alle aspecten van deze toepassingen en hun afhankelijke technologieën kunt diagnosticeren en oplossen. Als gebruiker van Azure Storage-services moet u continu de Opslagservices bewaken die uw toepassing gebruikt voor onverwachte wijzigingen in gedrag (zoals tragere reactietijden) en logboekregistratie gebruiken om gedetailleerdere gegevens te verzamelen en een probleem grondiger te analyseren. De diagnostische gegevens die u ophaalt bij bewaking en logboekregistratie helpen u bij het bepalen van de hoofdoorzaak van het probleem dat uw toepassing heeft aangetroffen. Vervolgens kunt u het probleem oplossen en de juiste stappen bepalen om het probleem op te lossen. Azure Storage is een kernservice van Azure en vormt een belangrijk onderdeel van de meeste oplossingen die klanten implementeren in de Azure-infrastructuur. Azure Storage bevat mogelijkheden voor het vereenvoudigen van bewaking, diagnose en het oplossen van opslagproblemen in uw cloudtoepassingen.

Hoe deze handleiding is georganiseerd

In de sectie Uw opslagservice bewaken wordt beschreven hoe u de status en prestaties van uw Azure Storage-services bewaakt met behulp van Metrische gegevens van Azure Opslaganalyse (metrische opslaggegevens).

In de sectie Opslagproblemen diagnosticeren wordt beschreven hoe u problemen kunt diagnosticeren met behulp van Azure Opslaganalyse Logging (Storage Logging). Ook wordt beschreven hoe u logboekregistratie aan de clientzijde inschakelt met behulp van de faciliteiten in een van de clientbibliotheken, zoals de Storage-clientbibliotheek voor .NET of de Azure SDK voor Java.

In de sectie End-to-end tracering wordt beschreven hoe u de informatie in verschillende logboekbestanden en metrische gegevens kunt correleren.

De sectie Richtlijnen voor probleemoplossing bevat richtlijnen voor het oplossen van problemen voor enkele veelvoorkomende problemen met betrekking tot opslag.

De sectie Appendices bevat informatie over het gebruik van andere hulpprogramma's, zoals Wireshark en Netmon voor het analyseren van netwerkpakketgegevens en Fiddler voor het analyseren van HTTP/HTTPS-berichten.

Uw opslagservice bewaken

Als u bekend bent met windows-prestatiebewaking, kunt u metrische opslaggegevens beschouwen als een Azure Storage-equivalent van windows-prestatiemeteritems. In metrische opslaggegevens vindt u een uitgebreide set metrische gegevens (meteritems in Windows Performance Monitor-terminologie), zoals de beschikbaarheid van de service, het totale aantal aanvragen voor de service of het percentage geslaagde aanvragen voor de service. Zie Opslaganalyse Tabelschema voor metrische gegevens voor een volledige lijst met beschikbare metrische gegevens. U kunt opgeven of u wilt dat de opslagservice elk uur of elke minuut metrische gegevens verzamelt en samenvoegt. Zie Metrische opslaggegevens inschakelen en metrische gegevens weergeven voor meer informatie over het inschakelen van metrische gegevens en het bewaken van uw opslagaccounts.

U kunt kiezen welke metrische gegevens per uur moeten worden weergegeven in Azure Portal en regels configureren waarmee beheerders per e-mail worden geïnformeerd wanneer een metrische gegevens per uur een bepaalde drempelwaarde overschrijdt. Zie Waarschuwingsmeldingen ontvangen voor meer informatie.

U wordt aangeraden Azure Monitor for Storage (preview) te bekijken. Het is een functie van Azure Monitor die uitgebreide bewaking van uw Azure Storage-accounts biedt door een uniforme weergave te bieden van de prestaties, capaciteit en beschikbaarheid van uw Azure Storage-services. U hoeft niets in te schakelen of te configureren en u kunt deze metrische gegevens direct bekijken vanuit de vooraf gedefinieerde interactieve grafieken en andere visualisaties.

De opslagservice probeert het beste metrische gegevens te verzamelen, maar registreert mogelijk niet elke opslagbewerking.

In Azure Portal kunt u metrische gegevens bekijken, zoals beschikbaarheid, totale aanvragen en gemiddelde latentienummers voor een opslagaccount. Er is ook een meldingsregel ingesteld om een beheerder te waarschuwen als de beschikbaarheid onder een bepaald niveau daalt. Als u deze gegevens bekijkt, is één mogelijk gebied voor onderzoek het succespercentage van de tabelservice dat lager is dan 100% (zie voor meer informatie, zie de metrische gegevens geven aan dat de vermeldingen in het analyselogboek bewerkingen hebben met de transactiestatus van de sectie ClientOtherErrors ).

U moet uw Azure-toepassingen continu bewaken om ervoor te zorgen dat ze in orde zijn en werken zoals verwacht door:

  • Het vaststellen van enkele metrische basislijngegevens voor de toepassing waarmee u de huidige gegevens kunt vergelijken en belangrijke wijzigingen in het gedrag van Azure Storage en uw toepassing kunt identificeren. De waarden van uw metrische basislijngegevens zijn in veel gevallen toepassingsspecifiek en u moet deze vaststellen wanneer u de prestaties van uw toepassing test.
  • Metrische gegevens van minuten opnemen en gebruiken om actief te controleren op onverwachte fouten en afwijkingen, zoals pieken in aantal fouten of aanvraagsnelheden.
  • Het vastleggen van metrische gegevens per uur en het gebruik ervan om gemiddelde waarden zoals het gemiddelde aantal fouten en aanvraagpercentages te bewaken.
  • Mogelijke problemen onderzoeken met behulp van diagnostische hulpprogramma's, zoals verderop in de sectie Opslagproblemen diagnosticeren .

De grafieken in de volgende afbeelding laten zien hoe het gemiddelde voor metrische gegevens per uur pieken in de activiteit kan verbergen. De metrische gegevens per uur lijken een constante frequentie van aanvragen weer te geven, terwijl de metrische gegevens van de minuut de schommelingen aan het licht brengen die echt plaatsvinden.

Grafieken die laten zien hoe het gemiddelde dat plaatsvindt voor metrische gegevens per uur pieken in activiteit kan verbergen.

In de rest van deze sectie wordt beschreven welke metrische gegevens u moet controleren en waarom.

Servicestatus bewaken

U kunt Azure Portal gebruiken om de status van de Storage-service (en andere Azure-services) in alle Azure-regio's over de hele wereld weer te geven. Met bewaking kunt u direct zien of een probleem buiten uw beheer van invloed is op de Storage-service in de regio die u voor uw toepassing gebruikt.

Azure Portal kan ook meldingen geven van incidenten die van invloed zijn op de verschillende Azure-services.

Notitie

Deze informatie was eerder beschikbaar, samen met historische gegevens, op het Azure-servicedashboard. Zie bijlage 5: Bewaking met Application Insights voor Azure DevOps voor meer informatie over Application Insights voor Azure DevOps.

Bewakingscapaciteit

Metrische opslaggegevens slaan alleen metrische capaciteitsgegevens op voor de blobservice, omdat blobs doorgaans het grootste deel van de opgeslagen gegevens verwerken (op het moment van schrijven is het niet mogelijk om metrische opslaggegevens te gebruiken om de capaciteit van uw tabellen en wachtrijen te bewaken). U vindt deze gegevens in de $MetricsCapacityBlob tabel als u bewaking voor de Blob-service hebt ingeschakeld. Metrische opslaggegevens registreert deze gegevens eenmaal per dag en u kunt de waarde van de RowKey rij gebruiken om te bepalen of de rij een entiteit bevat die betrekking heeft op gebruikersgegevens (waarde data) of analysegegevens (waarde analytics). Elke opgeslagen entiteit bevat informatie over de hoeveelheid gebruikte opslagruimte (Capacity gemeten in bytes) en het huidige aantal containers (ContainerCount) en blobs (ObjectCount) dat in het opslagaccount wordt gebruikt. Zie Opslaganalyse Tabelschema voor metrische gegevens over capaciteit die zijn opgeslagen in de tabel voor meer informatie over de metrische capaciteitsgegevens die zijn opgeslagen in de $MetricsCapacityBlob tabel.

Notitie

U moet deze waarden controleren voor een vroegtijdige waarschuwing dat u de capaciteitslimieten van uw opslagaccount nadert. In De Azure-portal kunt u waarschuwingsregels toevoegen om u op de hoogte te stellen als het geaggregeerde opslaggebruik groter is dan of onder de drempelwaarden valt die u opgeeft.

Als u de grootte van verschillende opslagobjecten, zoals blobs, wilt schatten, raadpleegt u het blogbericht Inzicht in Azure Storage-facturering: bandbreedte, transacties en capaciteit.

Beschikbaarheid bewaken

U moet de beschikbaarheid van de opslagservices in uw opslagaccount bewaken door de waarde in de Availability kolom in de tabellen met metrische gegevens per uur of minuut te bewaken: , $MetricsMinutePrimaryTransactionsBlob$MetricsHourPrimaryTransactionsTable$MetricsHourPrimaryTransactionsBlob$MetricsHourPrimaryTransactionsQueue, $MetricsMinutePrimaryTransactionsTable, , . $MetricsCapacityBlob$MetricsMinutePrimaryTransactionsQueue De Availability kolom bevat een percentagewaarde die de beschikbaarheid van de service of de API-bewerking aangeeft die wordt vertegenwoordigd door de rij (de RowKey rij bevat metrische gegevens voor de service als geheel of voor een specifieke API-bewerking).

Elke waarde kleiner dan 100% geeft aan dat sommige opslagaanvragen mislukken. U kunt zien waarom ze mislukken door de andere kolommen in de metrische gegevens te bekijken die het aantal aanvragen met verschillende fouttypen weergeven, zoals ServerTimeoutError. U zou moeten verwachten dat Availability deze tijdelijk onder de 100% vallen om redenen zoals tijdelijke servertime-outs terwijl de service partities verplaatst naar betere taakverdelingsaanvragen. De logica voor opnieuw proberen in uw clienttoepassing moet dergelijke onregelmatige voorwaarden afhandelen. In het artikel Opslaganalyse vastgelegde bewerkingen en statusberichten worden de transactietypen vermeld die metrische opslaggegevens bevatten in de Availability berekening.

In Azure Portal kunt u waarschuwingsregels toevoegen om u op de hoogte te stellen als Availability een service onder een drempelwaarde valt die u opgeeft.

In de sectie Probleemoplossing van deze handleiding worden enkele veelvoorkomende problemen met de opslagservice beschreven die betrekking hebben op beschikbaarheid.

Prestaties bewaken

Als u de prestaties van de opslagservices wilt bewaken, kunt u de volgende metrische gegevens uit de tabellen met metrische gegevens per uur en minuut gebruiken.

  • De waarden in de AverageE2ELatency en AverageServerLatency kolommen geven de gemiddelde tijd aan die het opslagservice- of API-bewerkingstype nodig heeft om aanvragen te verwerken. AverageE2ELatency is een meting van end-to-end latentie die de tijd omvat die nodig is om de aanvraag te lezen en het antwoord te verzenden, naast de tijd die nodig is om de aanvraag te verwerken (omvat daarom netwerklatentie zodra de aanvraag de opslagservice bereikt); AverageServerLatency is een meting van alleen de verwerkingstijd en sluit daarom eventuele netwerklatentie met betrekking tot de communicatie met de client uit. Zie de sectie Metrics high AverageE2ELatency en low AverageServerLatency verderop in deze handleiding voor een discussie over waarom er mogelijk een belangrijk verschil is tussen deze twee waarden.
  • De waarden in de TotalIngress en TotalEgress kolommen tonen de totale hoeveelheid gegevens, in bytes, die binnenkomen naar en uitgaan van uw opslagservice of via een specifiek TYPE API-bewerking.
  • De waarden in de TotalRequests kolom geven het totale aantal aanvragen weer dat de opslagservice van de API-bewerking ontvangt. TotalRequests is het totale aantal aanvragen dat de opslagservice ontvangt.

Normaal gesproken controleert u op onverwachte wijzigingen in een van deze waarden, omdat dit aangeeft dat u een probleem hebt waarvoor onderzoek is vereist.

In Azure Portal kunt u waarschuwingsregels toevoegen om u op de hoogte te stellen als er prestatiegegevens voor deze service lager zijn dan of een drempelwaarde overschrijden die u opgeeft.

In de sectie Probleemoplossing van deze handleiding worden enkele veelvoorkomende problemen met betrekking tot de prestaties van de opslagservice beschreven.

Problemen met opslag vaststellen

Er zijn een aantal manieren waarop u zich mogelijk bewust wordt van een probleem of probleem in uw toepassing, waaronder:

  • Een belangrijke fout waardoor de toepassing vastloopt of niet meer werkt.
  • Belangrijke wijzigingen ten opzichte van basislijnwaarden in de metrische gegevens die u bewaakt, zoals beschreven in de vorige sectie Uw opslagservice bewaken.
  • Rapporteert van gebruikers van uw toepassing dat een bepaalde bewerking niet is voltooid zoals verwacht of dat een bepaalde functie niet werkt.
  • Fouten die worden gegenereerd in uw toepassing die worden weergegeven in logboekbestanden of via een andere meldingsmethode.

Problemen met betrekking tot Azure-opslagservices vallen doorgaans in een van de vier algemene categorieën:

  • Uw toepassing heeft een prestatieprobleem, gerapporteerd door uw gebruikers of door wijzigingen in de metrische prestatiegegevens.
  • Er is een probleem met de Azure Storage-infrastructuur in een of meer regio's.
  • Uw toepassing krijgt een fout te zien, die door uw gebruikers is gerapporteerd of door een toename in een van de metrische gegevens voor het aantal fouten die u bewaakt.
  • Tijdens het ontwikkelen en testen gebruikt u mogelijk de lokale opslagemulator; Er kunnen problemen optreden die specifiek betrekking hebben op het gebruik van de opslagemulator.

In de volgende secties worden de stappen beschreven die u moet volgen om problemen in elk van deze vier categorieën vast te stellen en op te lossen. Verderop in deze handleiding vindt u meer informatie over enkele veelvoorkomende problemen die u kunt tegenkomen.

problemen met Servicestatus

Servicestatus problemen vallen doorgaans buiten uw beheer. Azure Portal biedt informatie over eventuele lopende problemen met Azure-services, waaronder opslagservices. Als u hebt gekozen voor geografisch redundante opslag met leestoegang bij het maken van uw opslagaccount, kan uw toepassing tijdelijk overschakelen naar de alleen-lezen kopie op de secundaire locatie als uw gegevens niet meer beschikbaar zijn. Als u wilt lezen van de secundaire, moet uw toepassing kunnen schakelen tussen het gebruik van de primaire en secundaire opslaglocaties en in een modus met beperkte functionaliteit werken met alleen-lezengegevens. Met de Azure Storage-clientbibliotheken kunt u een beleid voor opnieuw proberen definiëren dat kan worden gelezen uit secundaire opslag voor het geval een leesbewerking uit de primaire opslag mislukt. Uw toepassing moet er ook rekening mee houden dat de gegevens op de secundaire locatie uiteindelijk consistent zijn. Zie het blogbericht Over redundantieopties voor Azure Storage en Geografisch redundante opslag met leestoegang voor meer informatie.

Prestatieproblemen

De prestaties van een toepassing kunnen subjectief zijn, met name vanuit het perspectief van een gebruiker. Het is daarom belangrijk dat u over prestatiegegevens voor een basislijn beschikt aan de hand waarvan u kunt bepalen waar er prestatieproblemen zijn. Veel factoren kunnen van invloed zijn op de prestaties van een Azure-opslagservice vanuit het perspectief van de clienttoepassing. Deze factoren werken mogelijk in de opslagservice, de client of de netwerkinfrastructuur; Daarom is het belangrijk dat u een strategie hebt voor het identificeren van de oorsprong van het prestatieprobleem.

Nadat u de waarschijnlijke locatie van de oorzaak van het prestatieprobleem van de metrische gegevens hebt geïdentificeerd, kunt u vervolgens de logboekbestanden gebruiken om gedetailleerde informatie te vinden om het probleem verder te diagnosticeren en op te lossen.

Verderop in deze handleiding vindt u meer informatie over enkele veelvoorkomende prestatieproblemen die kunnen optreden.

Fouten diagnosticeren

Gebruikers van uw toepassing kunnen u op de hoogte stellen van fouten die zijn gerapporteerd door de clienttoepassing. Metrische opslaggegevens registreert ook het aantal verschillende fouttypen van uw opslagservices, zoals NetworkError, ClientTimeoutError of AuthorizationError. Hoewel metrische opslaggegevens alleen het aantal verschillende fouttypen registreren, kunt u meer details over afzonderlijke aanvragen verkrijgen door de logboeken aan de serverzijde, clientzijde en netwerklogboeken te bekijken. Normaal gesproken geeft de HTTP-statuscode die door de opslagservice wordt geretourneerd, een indicatie van waarom de aanvraag is mislukt.

Notitie

Houd er rekening mee dat u verwacht dat er af en toe fouten optreden: bijvoorbeeld fouten als gevolg van tijdelijke netwerkomstandigheden of toepassingsfouten.

De volgende resources kunnen worden gebruikt voor een overzicht van status- en foutcodes in verband met de opslag:

Problemen met opslagemulator

De Azure SDK bevat een opslagemulator die u kunt uitvoeren op een ontwikkelwerkstation. Deze emulator simuleert het meeste gedrag van de Azure-opslagservices en is nuttig tijdens het ontwikkelen en testen, zodat u toepassingen kunt uitvoeren die gebruikmaken van Azure-opslagservices zonder dat hiervoor een Azure-abonnement en een Azure-opslagaccount nodig zijn.

In de sectie Probleemoplossing van deze handleiding worden enkele veelvoorkomende problemen beschreven die zijn opgetreden met behulp van de opslagemulator.

Hulpprogramma's voor logboekregistratie van opslag

Logboekregistratie van opslag biedt logboekregistratie aan de serverzijde van opslagaanvragen in uw Azure-opslagaccount. Zie Logboekregistratie van opslag inschakelen en logboekgegevens openen voor meer informatie over het inschakelen van logboekregistratie aan de serverzijde en het openen van logboekgegevens.

Met de Storage-clientbibliotheek voor .NET kunt u logboekgegevens aan de clientzijde verzamelen die betrekking hebben op opslagbewerkingen die door uw toepassing worden uitgevoerd. Zie Logboekregistratie op de client inschakelen met de .NET-opslagclientbibliotheek voor meer informatie.

Notitie

In sommige gevallen (zoals SAS-autorisatiefouten) kan een gebruiker een fout melden waarvoor u geen aanvraaggegevens kunt vinden in de opslaglogboeken aan de serverzijde. U kunt de logboekregistratiemogelijkheden van de Opslagclientbibliotheek gebruiken om te onderzoeken of de oorzaak van het probleem zich op de client bevindt of om hulpprogramma's voor netwerkbewaking te gebruiken om het netwerk te onderzoeken.

Hulpprogramma's voor netwerkregistratie gebruiken

U kunt het verkeer tussen de client en de server vastleggen om gedetailleerde informatie te verstrekken over de gegevens die de client en server uitwisselen en de onderliggende netwerkvoorwaarden. Handige hulpprogramma's voor netwerklogboekregistratie zijn onder andere:

In veel gevallen zijn de logboekgegevens uit Opslaglogboekregistratie en de Opslagclientbibliotheek voldoende om een probleem vast te stellen, maar in sommige scenario's hebt u mogelijk de gedetailleerdere informatie nodig die deze hulpprogramma's voor netwerklogboekregistratie kunnen bieden. Als u bijvoorbeeld Fiddler gebruikt om HTTP- en HTTPS-berichten te bekijken, kunt u header- en nettoladinggegevens weergeven die naar en van de opslagservices worden verzonden, zodat u kunt onderzoeken hoe een clienttoepassing opslagbewerkingen opnieuw probeert uit te voeren. Protocolanalyses zoals Wireshark werken op pakketniveau, zodat u TCP-gegevens kunt weergeven, zodat u verloren pakketten en connectiviteitsproblemen kunt oplossen.

End-to-end tracering

End-to-end tracering met behulp van verschillende logboekbestanden is een handige techniek voor het onderzoeken van potentiële problemen. U kunt de datum-/tijdgegevens uit uw metrische gegevens gebruiken om aan te geven waar u in de logboekbestanden naartoe moet zoeken voor gedetailleerde informatie, zodat u het probleem kunt oplossen.

Logboekgegevens correleren

Wanneer u logboeken van clienttoepassingen, netwerktraceringen en logboekregistratie van opslag aan de serverzijde bekijkt, is het essentieel dat aanvragen in de verschillende logboekbestanden kunnen worden gecorreleerd. De logboekbestanden bevatten een aantal verschillende velden die nuttig zijn als correlatie-id's. De clientaanvraag-id is het handigste veld om vermeldingen in de verschillende logboeken te correleren. Soms kan het echter handig zijn om de serveraanvraag-id of tijdstempels te gebruiken. In de volgende secties vindt u meer informatie over deze opties.

Clientaanvraag-id

De Storage-clientbibliotheek genereert automatisch een unieke clientaanvraag-id voor elke aanvraag.

  • In het logboek aan de clientzijde dat door de opslagclientbibliotheek wordt gemaakt, wordt de clientaanvraag-id weergegeven in het Client Request ID veld van elke logboekvermelding die betrekking heeft op de aanvraag.
  • In een netwerktracering, zoals één die is vastgelegd door Fiddler, is de clientaanvraag-id zichtbaar in aanvraagberichten als de WAARDE van de x-ms-client-request-id HTTP-header.
  • In het logboek voor logboekregistratie van opslag aan de serverzijde wordt de clientaanvraag-id weergegeven in de kolom Clientaanvraag-id.

Notitie

Het is mogelijk dat meerdere aanvragen dezelfde clientaanvraag-id delen omdat de client deze waarde kan toewijzen (hoewel de Opslagclientbibliotheek automatisch een nieuwe waarde toewijst). Wanneer de client opnieuw probeert, delen alle pogingen dezelfde clientaanvraag-id. In het geval van een batch die vanaf de client is verzonden, heeft de batch één clientaanvraag-id.

Serveraanvraag-id

De opslagservice genereert automatisch serveraanvraag-id's.

  • In het logboek voor logboekregistratie van opslag aan de serverzijde wordt de aanvraag-id van de server weergegeven in de Request ID header kolom.
  • In een netwerktracering, zoals één die is vastgelegd door Fiddler, wordt de serveraanvraag-id weergegeven in antwoordberichten als de x-ms-request-id HTTP-headerwaarde.
  • In het logboek aan de clientzijde dat door de Opslagclientbibliotheek wordt gemaakt, wordt de serveraanvraag-id weergegeven in de Operation Text kolom voor de logboekvermelding met de details van het serverantwoord.

Notitie

De opslagservice wijst altijd een unieke serveraanvraag-id toe aan elke aanvraag die wordt ontvangen, dus elke nieuwe poging van de client en elke bewerking in een batch heeft een unieke serveraanvraag-id.

In het onderstaande codevoorbeeld ziet u hoe u een aangepaste clientaanvraag-id gebruikt.

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();
    }
}

Timestamps

U kunt ook tijdstempels gebruiken om gerelateerde logboekvermeldingen te vinden, maar wees voorzichtig met elke klokverschil tussen de client en de server die mogelijk bestaan. Zoek plus- of min 15 minuten voor overeenkomende vermeldingen aan de serverzijde op basis van de tijdstempel op de client. Houd er rekening mee dat de blobmetagegevens voor de blobs met metrische gegevens het tijdsbereik aangeeft voor de metrische gegevens die zijn opgeslagen in de blob. Dit tijdsbereik is handig als u veel metrische blobs voor hetzelfde minuut of uur hebt.

Richtlijn voor het oplossen van problemen

Deze sectie helpt u bij de diagnose en probleemoplossing van enkele veelvoorkomende problemen die uw toepassing kan ondervinden bij het gebruik van de Azure-opslagservices. Gebruik de onderstaande lijst om de informatie te vinden die relevant is voor uw specifieke probleem.

Beslissingsstructuur voor probleemoplossing

Heeft uw probleem betrekking op de prestaties van een van de opslagservices?

Heeft uw probleem betrekking op de beschikbaarheid van een van de opslagservices?

Ontvangt uw clienttoepassing een HTTP 4XX-antwoord (zoals 404) van een opslagservice?

Metrische gegevens tonen lage percentsuccess of vermeldingen in analyselogboeken hebben bewerkingen met de transactiestatus van ClientOtherErrors.

Metrische gegevens over capaciteit tonen een onverwachte toename van het opslagcapaciteitsgebruik.

Uw probleem ontstaat door de opslagemulator te gebruiken voor ontwikkeling of testen.

U ondervindt problemen met het installeren van de Azure SDK voor .NET.

U hebt een ander probleem met een opslagservice.

Prestatiegegevens geven hoge AverageE2ELatency en lage AverageServerLatency aan

In de onderstaande afbeelding van het bewakingsprogramma van Azure Portal ziet u een voorbeeld waarin averageE2ELatency aanzienlijk hoger is dan de AverageServerLatency.

Afbeelding van Azure Portal waarin een voorbeeld wordt weergegeven waarin averageE2ELatency aanzienlijk hoger is dan de AverageServerLatency.

De opslagservice berekent alleen de metrische waarde AverageE2ELatency voor geslaagde aanvragen en bevat, in tegenstelling tot AverageServerLatency, de tijd die de client nodig heeft om de gegevens te verzenden en bevestiging van de opslagservice te ontvangen. Daarom kan een verschil tussen AverageE2ELatency en AverageServerLatency worden veroorzaakt doordat de clienttoepassing traag reageert of vanwege omstandigheden in het netwerk.

Notitie

U kunt ook E2ELatency en ServerLatency weergeven voor afzonderlijke opslagbewerkingen in de logboekgegevens van logboekregistratie van opslag.

Problemen met clientprestaties onderzoeken

Mogelijke redenen waarom de client langzaam reageert, zijn onder andere het hebben van een beperkt aantal beschikbare verbindingen of threads, of dat er weinig resources beschikbaar zijn, zoals CPU, geheugen of netwerkbandbreedte. U kunt het probleem mogelijk oplossen door de clientcode te wijzigen zodat deze efficiënter is (bijvoorbeeld door asynchrone aanroepen naar de opslagservice te gebruiken) of door een grotere virtuele machine (met meer kernen en meer geheugen) te gebruiken.

Voor de tabel- en wachtrijservices kan het Nagle-algoritme ook een hoge AverageE2ELatency veroorzaken in vergelijking met AverageServerLatency. Zie Het algoritme van Nagle is niet vriendelijk voor kleine aanvragen voor meer informatie. U kunt het Nagle-algoritme in code uitschakelen met behulp van de ServicePointManager klasse in de System.Net naamruimte. U moet dit doen voordat u de tabel- of wachtrijservices in uw toepassing aanroept, omdat dit geen invloed heeft op verbindingen die al zijn geopend. Het volgende voorbeeld is afkomstig van de Application_Start methode in een werkrol.

var connectionString = Constants.connectionString;

QueueServiceClient queueServiceClient = new QueueServiceClient(connectionString);

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

Controleer de logboeken aan de clientzijde om te zien hoeveel aanvragen uw clienttoepassing verzendt en controleert op algemeen. Net-gerelateerde prestatieknelpunten in uw client, zoals CPU, .NET garbagecollection, netwerkgebruik of geheugen. Zie Foutopsporing, tracering en profilering als uitgangspunt voor het oplossen van problemen met .NET-clienttoepassingen.

Problemen met netwerklatentie onderzoeken

Normaal gesproken wordt een hoge end-to-endlatentie veroorzaakt door het netwerk vanwege tijdelijke omstandigheden. U kunt zowel tijdelijke als permanente netwerkproblemen onderzoeken, zoals verwijderde pakketten, met behulp van hulpprogramma's zoals Wireshark.

Zie bijlage 2: Wireshark gebruiken om netwerkverkeer vast te leggen voor meer informatie over het gebruik van Wireshark om netwerkproblemen op te lossen.

Prestatiegegevens geven lage AverageE2ELatency en lage AverageServerLatency aan, maar de client ondervindt hoge latentie

In dit scenario is de meest waarschijnlijke oorzaak een vertraging in de opslagaanvragen die de opslagservice bereiken. U moet onderzoeken waarom aanvragen van de client deze niet doorbrengen naar de blobservice.

Een mogelijke reden voor het uitstellen van verzendaanvragen door de client is dat er een beperkt aantal beschikbare verbindingen of threads is.

Controleer ook of de client meerdere nieuwe pogingen uitvoert en onderzoek de reden als dit het is. Als u wilt bepalen of de client meerdere nieuwe pogingen uitvoert, kunt u het volgende doen:

  • Bekijk de Opslaganalyse logboeken. Als er meerdere nieuwe pogingen worden uitgevoerd, ziet u meerdere bewerkingen met dezelfde clientaanvraag-id, maar met verschillende serveraanvraag-id's.
  • Controleer de clientlogboeken. Uitgebreide logboekregistratie geeft aan dat er een nieuwe poging is opgetreden.
  • Fouten opsporen in uw code en de eigenschappen controleren van het OperationContext object dat is gekoppeld aan de aanvraag. Als de bewerking opnieuw is geprobeerd, bevat de RequestResults eigenschap meerdere unieke serveraanvraag-id's. U kunt ook de begin- en eindtijden voor elke aanvraag controleren. Zie het codevoorbeeld in de sectie Serveraanvraag-id voor meer informatie.

Als er geen problemen zijn in de client, moet u potentiële netwerkproblemen onderzoeken, zoals pakketverlies. U kunt hulpprogramma's zoals Wireshark gebruiken om netwerkproblemen te onderzoeken.

Zie bijlage 2: Wireshark gebruiken om netwerkverkeer vast te leggen voor meer informatie over het gebruik van Wireshark om netwerkproblemen op te lossen.

Prestatiegegevens geven hoge AverageServerLatency aan

In het geval van een hoge AverageServerLatency voor blob-downloadaanvragen moet u de logboeken voor logboekregistratie van Azure Storage gebruiken om te kijken of er herhaalde aanvragen voor dezelfde blob (of een set blobs) zijn. Voor blob-uploadaanvragen moet u onderzoeken welke blokgrootte de client gebruikt (blokken van minder dan 64 K in grootte kunnen bijvoorbeeld leiden tot overhead, tenzij de leesbewerkingen zich ook in minder dan 64 K-segmenten bevinden) en als meerdere clients blokken parallel uploaden naar dezelfde blob. U moet ook de metrische gegevens per minuut controleren op pieken in het aantal aanvragen dat resulteert in het overschrijden van de schaalbaarheidsdoelen per seconde. Zie Metrics voor meer informatie een toename in PercentTimeoutError.

Als u hoge AverageServerLatency voor blob-downloadaanvragen ziet wanneer er herhaalde aanvragen zijn voor dezelfde blob of set blobs, kunt u deze blobs in de cache opslaan met behulp van Azure Cache of het Azure Content Delivery Network (CDN). Voor uploadaanvragen kunt u de doorvoer verbeteren met behulp van een grotere blokgrootte. Voor query's naar tabellen is het ook mogelijk om caching aan clientzijde te implementeren op clients die dezelfde querybewerkingen uitvoeren en waar de gegevens niet vaak veranderen.

Hoge AverageServerLatency-waarden kunnen ook een symptoom zijn van slecht ontworpen tabellen of query's die leiden tot scanbewerkingen of die het antipatroon toevoegen/voorafgaan volgen. Zie Metrics (Metrische gegevens) voor meer informatie een toename in PercentThrottlingError.

Notitie

U vindt hier een uitgebreide controlelijst voor prestaties: Controlelijst voor prestaties en schaalbaarheid van Microsoft Azure Storage.

U ervaart onverwachte vertragingen bij de levering van berichten in een wachtrij

Als u een vertraging ondervindt tussen het moment dat een toepassing een bericht toevoegt aan een wachtrij en de tijd die beschikbaar is om uit de wachtrij te lezen, voert u de volgende stappen uit om het probleem vast te stellen:

  • Controleer of de toepassing de berichten aan de wachtrij heeft toegevoegd. Controleer of de toepassing de AddMessage methode meerdere keren opnieuw probeert te proberen voordat deze slaagt. In de logboeken van de Opslagclientbibliotheek worden herhaalde pogingen van opslagbewerkingen weergegeven.
  • Controleer of er geen klokverschil is tussen de werkrol waarmee het bericht wordt toegevoegd aan de wachtrij en de werkrol die het bericht uit de wachtrij leest. Een klok scheeftrekken maakt het alsof er een vertraging in de verwerking is.
  • Controleer of de werkrol die de berichten uit de wachtrij leest, mislukt. Als een wachtrijclient de GetMessage methode aanroept, maar niet reageert met een bevestiging, blijft het bericht onzichtbaar in de wachtrij totdat de invisibilityTimeout periode verloopt. Op dit moment wordt het bericht weer beschikbaar voor verwerking.
  • Controleer of de wachtrijlengte na verloop van tijd groeit. Dit kan gebeuren als u niet voldoende werkrollen hebt om alle berichten te verwerken die andere werknemers in de wachtrij plaatsen. Controleer ook de metrische gegevens om te zien of verwijderaanvragen mislukken en het aantal wachtrijen op berichten, wat kan duiden op herhaalde mislukte pogingen om het bericht te verwijderen.
  • Bekijk de logboeken voor opslaglogboeken voor wachtrijbewerkingen met een hogere dan verwachte E2ELatency - en ServerLatency-waarden gedurende een langere periode dan normaal.

Prestatiegegevens geven een toename in PercentThrottlingError aan

Beperkingsfouten treden op wanneer u de schaalbaarheidsdoelen van een opslagservice overschrijdt. De opslagservice beperkt zich om ervoor te zorgen dat geen enkele client of tenant de service ten koste van anderen kan gebruiken. Zie schaalbaarheids- en prestatiedoelen voor standaardopslagaccounts voor meer informatie over schaalbaarheidsdoelen voor opslagaccounts en prestatiedoelen voor partities binnen opslagaccounts.

Als de metrische waarde PercentThrottlingError een toename toont van het percentage aanvragen dat mislukt met een beperkingsfout, moet u een van de twee scenario's onderzoeken:

Een toename in PercentThrottlingError vindt vaak plaats op hetzelfde moment als een toename van het aantal opslagaanvragen of wanneer u de toepassing in eerste instantie laadt. Dit kan zich ook in de client voordoen als HTTP-statusberichten van de HTTP-status '503 Server Bezet' of 'Time-out van 500 bewerkingen' voor bewerkingen.

Tijdelijke toename in PercentThrottlingError

Als u pieken ziet in de waarde van PercentThrottlingError die samenvalt met perioden van hoge activiteit voor de toepassing, kunt u een exponentiële (niet lineaire) back-off-strategie implementeren voor nieuwe pogingen in uw client. Back-off-nieuwe pogingen verminderen de onmiddellijke belasting van de partitie en helpen uw toepassing pieken in het verkeer op te vlakken. Zie de naamruimte Microsoft.Azure.Storage.RetryPolicies voor meer informatie over het implementeren van beleid voor opnieuw proberen met behulp van de Storage-clientbibliotheek.

Notitie

Mogelijk ziet u ook pieken in de waarde van PercentThrottlingError die niet samenvallen met perioden met hoge activiteit voor de toepassing. De meest waarschijnlijke oorzaak is dat de opslagservice partities verplaatst om de taakverdeling te verbeteren.

Permanente toename in PercentThrottlingError

Als u een consistent hoge waarde ziet voor PercentThrottlingError na een permanente toename van uw transactievolumes of wanneer u de eerste belastingstests voor uw toepassing uitvoert, moet u evalueren hoe uw toepassing opslagpartities gebruikt en of deze de schaalbaarheidsdoelen voor een opslagaccount nadert. Als u bijvoorbeeld bandbreedtebeperkingsfouten ziet in een wachtrij (die als één partitie telt), kunt u overwegen om extra wachtrijen te gebruiken om de transacties over meerdere partities te verdelen. Als u bandbreedtebeperkingsfouten in een tabel ziet, moet u overwegen een ander partitioneringsschema te gebruiken om uw transacties over meerdere partities te verdelen met behulp van een breder scala aan partitiesleutelwaarden. Een veelvoorkomende oorzaak van dit probleem is het antipatroon voor vooraf/toevoegen waarbij u de datum als partitiesleutel selecteert en vervolgens alle gegevens op een bepaalde dag naar één partitie worden geschreven: onder belasting kan dit leiden tot een knelpunt voor schrijven. Overweeg een ander partitioneringsontwerp of evalueer of het gebruik van blobopslag een betere oplossing kan zijn. Controleer ook of er beperkingen optreden als gevolg van pieken in uw verkeer en onderzoek manieren om uw patroon van aanvragen te vereffenen.

Als u uw transacties over meerdere partities distribueert, moet u nog steeds rekening houden met de schaalbaarheidslimieten die zijn ingesteld voor het opslagaccount. Als u bijvoorbeeld tien wachtrijen hebt gebruikt, wordt elke verwerking van het maximum van 20.000 1 KB-berichten per seconde bereikt, de totale limiet van 20.000 berichten per seconde voor het opslagaccount. Als u meer dan 20.000 entiteiten per seconde moet verwerken, kunt u overwegen meerdere opslagaccounts te gebruiken. Houd er ook rekening mee dat de grootte van uw aanvragen en entiteiten van invloed is op wanneer de opslagservice uw clients beperkt. Als u grotere aanvragen en entiteiten hebt, wordt u mogelijk eerder beperkt.

Inefficiënt queryontwerp kan er ook toe leiden dat u de schaalbaarheidslimieten voor tabelpartities bereikt. Een query met een filter dat bijvoorbeeld slechts één procent van de entiteiten in een partitie selecteert, maar dat alle entiteiten in een partitie scant, moet toegang krijgen tot elke entiteit. Elke entiteit die wordt gelezen, telt mee voor het totale aantal transacties in die partitie; Daarom kunt u eenvoudig de schaalbaarheidsdoelen bereiken.

Notitie

Uw prestatietests moeten inefficiënte queryontwerpen in uw toepassing onthullen.

Prestatiegegevens geven een toename in PercentTimeoutError aan

Uw metrische gegevens tonen een toename in PercentTimeoutError voor een van uw opslagservices. Tegelijkertijd ontvangt de client een groot aantal HTTP-statusberichten van '500 Bewerkingstime-out' van opslagbewerkingen.

Notitie

Mogelijk ziet u tijdelijk time-outfouten wanneer de load balancer van de opslagservice aanvragen verdeelt door een partitie naar een nieuwe server te verplaatsen.

De metrische waarde PercentTimeoutError is een aggregatie van de volgende metrische gegevens: ClientTimeoutError, AnonymousClientTimeoutError, SASClientTimeoutError, ServerTimeoutError, AnonymousServerTimeoutError en SASServerTimeoutError.

De time-outs van de server worden veroorzaakt door een fout op de server. De time-outs van de client treden op omdat een bewerking op de server de time-out heeft overschreden die is opgegeven door de client; Een client die de Opslagclientbibliotheek gebruikt, kan bijvoorbeeld een time-out voor een bewerking instellen met behulp van de ServerTimeout eigenschap van de QueueRequestOptions klasse.

Servertime-outs geven een probleem aan met de opslagservice waarvoor nader onderzoek is vereist. U kunt metrische gegevens gebruiken om te zien of u de schaalbaarheidslimieten voor de service bereikt en om pieken in het verkeer te identificeren die dit probleem kunnen veroorzaken. Als het probleem af en toe optreedt, kan dit worden veroorzaakt door taakverdelingsactiviteit in de service. Als het probleem permanent is en niet wordt veroorzaakt door uw toepassing die de schaalbaarheidslimieten van de service bereikt, moet u een ondersteuningsprobleem veroorzaken. Voor clienttime-outs moet u bepalen of de time-out is ingesteld op een geschikte waarde in de client en de time-outwaarde die is ingesteld in de client of onderzoeken hoe u de prestaties van de bewerkingen in de opslagservice kunt verbeteren, bijvoorbeeld door uw tabelquery's te optimaliseren of de grootte van uw berichten te verkleinen.

Prestatiegegevens geven een toename in PercentNetworkError aan

Uw metrische gegevens tonen een toename in PercentNetworkError voor een van uw opslagservices. De metrische waarde PercentNetworkError is een aggregatie van de volgende metrische gegevens: NetworkError, AnonymousNetworkError en SASNetworkError. Deze treden op wanneer de opslagservice een netwerkfout detecteert wanneer de client een opslagaanvraag indient.

De meest voorkomende oorzaak van deze fout is dat de verbinding met een client wordt verbroken voordat een time-out verloopt in de opslagservice. Onderzoek de code in uw client om te begrijpen waarom en wanneer de client de verbinding met de opslagservice verbreekt. U kunt ook Wireshark of Tcping gebruiken om problemen met de netwerkverbinding van de client te onderzoeken. Deze hulpprogramma's worden beschreven in de Appendices.

De client ontvangt HTTP 403-meldingen (verboden)

Als de clienttoepassing een HTTP 403-fout (verboden) weergeeft, is een vermoedelijke oorzaak dat de client gebruikmaakt van een verlopen Shared Access Signature (SAS) bij het verzenden van een opslagaanvraag (hoewel andere mogelijke oorzaken een tijdverschil, ongeldige sleutels of lege headers kunnen zijn). Als een verlopen SAS-sleutel de oorzaak is, ziet u geen vermeldingen in de logboekgegevens voor logboekregistratie aan de serverzijde. In de volgende tabel ziet u een voorbeeld uit het logboek aan de clientzijde dat is gegenereerd door de Opslagclientbibliotheek waarin dit probleem wordt geïllustreerd:

Bron Uitgebreidheid Uitgebreidheid Clientaanvraag-id Bewerkingstekst
Microsoft.Azure.Storage Gegevens 3 85d077ab-... Starting operation with location Primary per location mode PrimaryOnly.
Microsoft.Azure.Storage Gegevens 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 Gegevens 3 85d077ab -... Waiting for response.
Microsoft.Azure.Storage Waarschuwing 2 85d077ab -... Exception thrown while waiting for response: The remote server returned an error: (403) Forbidden.
Microsoft.Azure.Storage Gegevens 3 85d077ab -... Response received. Status code = 403, Request ID = <Request ID>, Content-MD5 = , ETag = .
Microsoft.Azure.Storage Waarschuwing 2 85d077ab -... Exception thrown during the operation: The remote server returned an error: (403) Forbidden..
Microsoft.Azure.Storage Gegevens 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 Gegevens 3 85d077ab -... The next location has been set to Primary, based on the location mode.
Microsoft.Azure.Storage Error 1 85d077ab -... Retry policy did not allow for a retry. Failing with The remote server returned an error: (403) Forbidden.

In dit scenario moet u onderzoeken waarom het SAS-token verloopt voordat de client het token naar de server verzendt:

  • Normaal gesproken moet u geen begintijd instellen wanneer u een SAS maakt voor een client die onmiddellijk moet worden gebruikt. Als er kleine klokverschillen zijn tussen de host die de SAS genereert met behulp van de huidige tijd en de opslagservice, is het mogelijk dat de opslagservice een SAS ontvangt die nog niet geldig is.
  • Stel geen zeer korte verlooptijd in voor een SAS. Nogmaals, kleine klokverschillen tussen de host die de SAS en de opslagservice genereert, kan ertoe leiden dat een SAS schijnbaar eerder verloopt dan verwacht.
  • Komt de versieparameter in de SAS-sleutel (bijvoorbeeld sv=2015-04-05) overeen met de versie van de Opslagclientbibliotheek die u gebruikt? U wordt aangeraden altijd de nieuwste versie van de Storage-clientbibliotheek te gebruiken.
  • Als u uw opslagtoegangssleutels opnieuw genereert, kunnen eventuele SAS-tokens ongeldig worden. Dit probleem doet zich voor als u SAS-tokens genereert met een lange verlooptijd voor clienttoepassingen die in de cache worden opgeslagen.

Als u de Storage-clientbibliotheek gebruikt om SAS-tokens te genereren, kunt u eenvoudig een geldig token maken. Als u echter de Storage REST API gebruikt en de SAS-tokens handmatig samenwerkt, raadpleegt u Het delegeren van Access met een Shared Access Signature.

De client ontvangt HTTP 404-meldingen (niet gevonden)

Als de clienttoepassing een HTTP 404-bericht (niet gevonden) van de server ontvangt, betekent dit dat het object dat de client probeerde te gebruiken (zoals een entiteit, tabel, blob, container of wachtrij) niet bestaat in de opslagservice. Hiervoor zijn een aantal mogelijke redenen, bijvoorbeeld:

Het object is eerder door de client of een ander proces verwijderd

In scenario's waarin de client probeert gegevens in een opslagservice te lezen, bij te werken of te verwijderen, is het meestal eenvoudig om in de serverlogboeken een vorige bewerking vast te stellen waarmee het betreffende object uit de opslagservice is verwijderd. Vaak blijkt uit de logboekgegevens dat een andere gebruiker of proces het object heeft verwijderd. In het logboek voor logboekregistratie van opslag aan de serverzijde worden de kolommen operation-type en requested-object-key weergegeven wanneer een client een object heeft verwijderd.

In het scenario waarin een client probeert een object in te voegen, is het mogelijk niet direct duidelijk waarom dit resulteert in een HTTP 404-antwoord (niet gevonden), gezien het feit dat de client een nieuw object maakt. Als de client echter een blob maakt, moet deze de blobcontainer kunnen vinden. Als de client een bericht maakt, moet het een wachtrij kunnen vinden. En als de client een rij toevoegt, moet deze de tabel kunnen vinden.

U kunt het logboek aan de clientzijde van de Opslagclientbibliotheek gebruiken om een gedetailleerder inzicht te krijgen in wanneer de client specifieke aanvragen naar de opslagservice verzendt.

Het volgende logboek aan de clientzijde dat is gegenereerd door de Opslagclientbibliotheek illustreert het probleem wanneer de client de container voor de blob die wordt gemaakt, niet kan vinden. Dit logboek bevat details van de volgende opslagbewerkingen:

Aanvraag-id Operation
07b26a5d-... DeleteIfExists methode om de blobcontainer te verwijderen. Houd er rekening mee dat deze bewerking een HEAD aanvraag bevat om te controleren of de container bestaat.
e2d06d78... CreateIfNotExists methode voor het maken van de blobcontainer. Houd er rekening mee dat deze bewerking een HEAD aanvraag bevat waarmee wordt gecontroleerd op het bestaan van de container. Het HEAD retourneert een 404-bericht, maar gaat door.
de8b1c3c-... UploadFromStream methode voor het maken van de blob. De PUT aanvraag mislukt met een 404-bericht.

Logboekvermeldingen:

Aanvraag-id Bewerkingstekst
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..

In dit voorbeeld ziet u in het logboek dat de client aanvragen uit de CreateIfNotExists methode (aanvraag-id e2d06d78...) met de aanvragen van de UploadFromStream methode (de8b1c3c-...) interleaving uitvoert. Deze interleaving treedt op omdat de clienttoepassing deze methoden asynchroon aanroept. Wijzig de asynchrone code in de client om ervoor te zorgen dat de container wordt gemaakt voordat u probeert gegevens te uploaden naar een blob in die container. In het ideale geval moet u al uw containers vooraf maken.

Een probleem met de verificatie van een SAS (Shared Access Signature)

Als de clienttoepassing probeert een SAS-sleutel te gebruiken die niet de benodigde machtigingen voor de bewerking bevat, retourneert de opslagservice een HTTP 404-bericht (niet gevonden) naar de client. Tegelijkertijd ziet u ook een niet-nulwaarde voor SASAuthorizationError in de metrische gegevens.

In de volgende tabel ziet u een voorbeeld van een logboekbericht aan de serverzijde van het logboekbestand voor logboekregistratie van opslag:

Naam Weergegeven als
Begintijd van aanvraag 2014-05-30T06:17:48.4473697Z
Het type bewerking GetBlobProperties
Aanvraagstatus SASAuthorizationError
HTTP-statuscode 404
Authentication type Sas
Servicetype Blob
Aanvraag-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
Header aanvraag-id <Header aanvraag-id>
Clientaanvraag-id <Clientaanvraag-id>

Onderzoek waarom uw clienttoepassing probeert een bewerking uit te voeren waarvoor deze geen machtigingen heeft gekregen.

JavaScript-code aan de clientzijde heeft geen toegang tot het object

Als u een JavaScript-client gebruikt en de opslagservice HTTP 404-berichten retourneert, controleert u in de browser op de volgende JavaScript-fouten:

SEC7120: Oorsprong http://localhost:56309 niet gevonden in de header Access-Control-Allow-Origin.
SCRIPT7002: XMLHttpRequest: Netwerkfout 0x80070005, wordt de toegang geweigerd.

Notitie

U kunt de F12-ontwikkelhulpprogramma's in Internet Explorer gebruiken om de berichten te traceren die worden uitgewisseld tussen de browser en de opslagservice wanneer u problemen met JavaScript aan de clientzijde wilt oplossen.

Deze fouten treden op omdat de webbrowser dezelfde beveiligingsbeperking voor oorsprongsbeleid implementeert die voorkomt dat een webpagina een API aanroept in een ander domein dan het domein waarvan de pagina afkomstig is.

Als u het JavaScript-probleem wilt omzeilen, kunt u CORS (Cross-Origin Resource Sharing) configureren voor de opslagservice die de client opent. Zie CorS-ondersteuning (Cross-Origin Resource Sharing) voor Azure Storage Services voor meer informatie.

In het volgende codevoorbeeld ziet u hoe u uw blobservice configureert om JavaScript in het Contoso-domein toegang te geven tot een blob in uw blobopslagservice:

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

Netwerkfout

In sommige gevallen kunnen verloren netwerkpakketten ertoe leiden dat de opslagservice HTTP 404-berichten retourneert naar de client. Wanneer uw clienttoepassing bijvoorbeeld een entiteit uit de tabelservice verwijdert, ziet u dat de client een opslaguitzondering genereert die een http 404-statusbericht (niet gevonden) van de tabelservice rapporteert. Wanneer u de tabel in de Table Storage-service onderzoekt, ziet u dat de service de entiteit heeft verwijderd zoals aangevraagd.

De uitzonderingsdetails in de client bevatten de aanvraag-id (7e84f12d...), toegewezen door de tabelservice voor de aanvraag. U kunt deze informatie gebruiken om de aanvraaggegevens in de opslaglogboeken aan de serverzijde te vinden door in de request-id-header kolom in het logboekbestand te zoeken. U kunt ook de metrische gegevens gebruiken om te bepalen wanneer fouten zoals deze optreden en vervolgens de logboekbestanden doorzoeken op basis van het tijdstip waarop de metrische gegevens deze fout hebben vastgelegd. Deze logboekvermelding laat zien dat het verwijderen is mislukt met het statusbericht HTTP (404) Client Other Error. Dezelfde logboekvermelding bevat ook de aanvraag-id die is gegenereerd door de client in de client-request-id kolom (813ea74f...).

Het logboek aan de serverzijde bevat ook een andere vermelding met dezelfde client-request-id waarde (813ea74f...) voor een geslaagde verwijderbewerking voor dezelfde entiteit en van dezelfde client. Deze geslaagde verwijderingsbewerking vond zeer kort voor de mislukte verwijderingsaanvraag plaats.

De meest waarschijnlijke oorzaak van dit scenario is dat de client een verwijderaanvraag voor de entiteit heeft verzonden naar de tabelservice, die is geslaagd, maar geen bevestiging van de server heeft ontvangen (mogelijk vanwege een tijdelijk netwerkprobleem). De client heeft de bewerking vervolgens automatisch opnieuw geprobeerd (met dezelfde client-request-idbewerking) en deze nieuwe poging is mislukt omdat de entiteit al is verwijderd.

Als dit probleem vaak optreedt, moet u onderzoeken waarom de client geen bevestigingen van de tabelservice ontvangt. Als het probleem af en toe optreedt, moet u de fout HTTP (404) Niet gevonden onderschekken en aanmelden bij de client, maar de client toestaan om door te gaan.

De client ontvangt HTTP 409-meldingen (conflict)

In de volgende tabel ziet u een extract uit het logboek aan de serverzijde voor twee clientbewerkingen: DeleteIfExists onmiddellijk gevolgd door CreateIfNotExists dezelfde blobcontainernaam te gebruiken. Elke clientbewerking resulteert in twee aanvragen die naar de server worden verzonden, eerst een GetContainerProperties aanvraag om te controleren of de container bestaat, gevolgd door de DeleteContainer of CreateContainer aanvraag.

Tijdstempel Operation Resultaat Containernaam Clientaanvraag-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-...

De code in de clienttoepassing wordt verwijderd en maakt vervolgens onmiddellijk een blobcontainer opnieuw met dezelfde naam: de CreateIfNotExists methode (clientaanvraag-id bc881924-...) mislukt uiteindelijk met de HTTP 409-fout (Conflict). Wanneer een client blobcontainers, tabellen of wachtrijen verwijdert, is er een korte periode voordat de naam weer beschikbaar is.

De clienttoepassing moet een unieke containernaam gebruiken wanneer er een nieuwe container wordt gemaakt als het patroon voor verwijderen/opnieuw maken algemeen is.

Metrische gegevens tonen lage percentsuccess of analyselogboekvermeldingen hebben bewerkingen met de transactiestatus van ClientOtherErrors

De metrische waarde PercentSuccess legt het percentage bewerkingen vast dat is geslaagd op basis van hun HTTP-statuscode. Bewerkingen met statuscodes van 2XX tellen als geslaagd, terwijl bewerkingen met statuscodes in 3XX-, 4XX- en 5XX-bereiken worden meegeteld als mislukt en verlagen de metrische waarde percentSuccess . In de opslaglogboekbestanden aan de serverzijde worden deze bewerkingen vastgelegd met een transactiestatus van ClientOtherErrors.

Het is belangrijk om te weten dat deze bewerkingen zijn voltooid en dus geen invloed hebben op andere metrische gegevens, zoals beschikbaarheid. Enkele voorbeelden van bewerkingen die succesvol worden uitgevoerd, maar die kunnen leiden tot mislukte HTTP-statuscodes zijn:

  • ResourceNotFound (Niet gevonden 404), bijvoorbeeld van een GET aanvraag naar een blob die niet bestaat.
  • ResourceAlreadyExists (Conflict 409), bijvoorbeeld vanuit een CreateIfNotExist bewerking waarin de resource al bestaat.
  • ConditionNotMet (Niet gewijzigd 304), bijvoorbeeld vanaf een voorwaardelijke bewerking, zoals wanneer een client een ETag waarde en een HTTP-header If-None-Match verzendt om een afbeelding alleen aan te vragen als deze sinds de laatste bewerking is bijgewerkt.

U vindt een lijst met veelvoorkomende REST API-foutcodes die de opslagservices retourneren op de pagina Algemene REST API-foutcodes.

Metrische gegevens over capaciteit tonen een onverwachte toename van het opslagcapaciteitsgebruik

Als u plotselinge, onverwachte wijzigingen in het capaciteitsgebruik in uw opslagaccount ziet, kunt u de redenen onderzoeken door eerst uw metrische beschikbaarheidsgegevens te bekijken; Een toename van het aantal mislukte verwijderingsaanvragen kan bijvoorbeeld leiden tot een toename van de hoeveelheid blobopslag die u gebruikt als toepassingsspecifieke opschoonbewerkingen die u verwachtte om ruimte vrij te maken, werkt mogelijk niet zoals verwacht (bijvoorbeeld omdat de SAS-tokens die worden gebruikt voor het vrijmaken van ruimte zijn verlopen).

Uw probleem treedt op bij het gebruik van de opslagemulator voor ontwikkeling of test

Doorgaans gebruikt u de opslagemulator tijdens het ontwikkelen en testen om de vereiste voor een Azure-opslagaccount te voorkomen. De veelvoorkomende problemen die kunnen optreden wanneer u de opslagemulator gebruikt, zijn:

De functie X werkt niet in de opslagemulator

De opslagemulator biedt geen ondersteuning voor alle functies van de Azure-opslagservices, zoals de bestandsservice. Zie Use the Azure Storage Emulator for Development and Testing (De Azure-opslagemulator gebruiken voor het ontwikkelen en testen) voor meer informatie.

Voor deze functies die de opslagemulator niet ondersteunt, gebruikt u de Azure Storage-service in de cloud.

Fout 'De waarde voor een van de HTTP-headers heeft niet de juiste indeling' wanneer u de opslagemulator gebruikt

U test uw toepassing die gebruikmaakt van de opslagclientbibliotheek voor de lokale opslagemulator en methode-aanroepen zoals CreateIfNotExists mislukken met het foutbericht 'De waarde voor een van de HTTP-headers heeft niet de juiste indeling'. Dit geeft aan dat de versie van de opslagemulator die u gebruikt, geen ondersteuning biedt voor de versie van de opslagclientbibliotheek die u gebruikt. De storage-clientbibliotheek voegt de header x-ms-version toe aan alle aanvragen die worden ingediend. Als de opslagemulator de waarde in de x-ms-version header niet herkent, wordt de aanvraag geweigerd.

U kunt de logboeken van de opslagbibliotheekclient gebruiken om de waarde te zien van het x-ms-version header verzenden ervan. U kunt ook de waarde van de x-ms-version header functie zien als u Fiddler gebruikt om de aanvragen van uw clienttoepassing te traceren.

Dit scenario treedt meestal op als u de nieuwste versie van de Opslagclientbibliotheek installeert en gebruikt zonder de opslagemulator bij te werken. U moet de nieuwste versie van de opslagemulator installeren of cloudopslag gebruiken in plaats van de emulator voor ontwikkeling en testen.

Voor het uitvoeren van de opslagemulator zijn beheerdersbevoegdheden vereist

U wordt gevraagd om beheerdersreferenties wanneer u de opslagemulator uitvoert. Dit gebeurt alleen wanneer u de opslagemulator voor de eerste keer initialiseert. Nadat u de opslagemulator hebt geïnitialiseerd, hebt u geen beheerdersbevoegdheden nodig om deze opnieuw uit te voeren.

Zie Use the Azure Storage Emulator for Development and Testing (De Azure-opslagemulator gebruiken voor het ontwikkelen en testen) voor meer informatie. U kunt de opslagemulator ook initialiseren in Visual Studio, waarvoor ook beheerdersbevoegdheden zijn vereist.

U ondervindt problemen bij het installeren van de Azure SDK voor .NET

Wanneer u de SDK probeert te installeren, mislukt deze tijdens het installeren van de opslagemulator op uw lokale computer. Het installatielogboek bevat een van de volgende berichten:

  • CAQuietExec: Fout: Kan geen toegang krijgen tot SQL-exemplaar
  • CAQuietExec: Fout: Kan database niet maken

De oorzaak is een probleem met de bestaande LocalDB-installatie. De opslagemulator maakt standaard gebruik van LocalDB om gegevens vast te houden wanneer de Azure-opslagservices worden gesimuleerd. U kunt uw LocalDB-exemplaar opnieuw instellen door de volgende opdrachten uit te voeren in een opdrachtpromptvenster voordat u de SDK probeert te installeren.

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

Met delete de opdracht worden oude databasebestanden verwijderd uit eerdere installaties van de opslagemulator.

U hebt een ander probleem met een opslagservice

Als in de vorige secties voor probleemoplossing het probleem dat u hebt met een opslagservice niet is opgenomen, moet u de volgende benadering gebruiken om uw probleem te diagnosticeren en op te lossen.

  • Controleer uw metrische gegevens om te zien of er wijzigingen zijn ten opzichte van het verwachte basislijngedrag. Vanuit de metrische gegevens kunt u mogelijk bepalen of het probleem tijdelijk of permanent is en welke opslagbewerkingen het probleem beïnvloeden.
  • U kunt de metrische gegevens gebruiken om u te helpen bij het doorzoeken van logboekgegevens aan de serverzijde voor gedetailleerdere informatie over eventuele fouten die optreden. Deze informatie kan u helpen het probleem op te lossen.
  • Als de informatie in de logboeken aan de serverzijde niet voldoende is om het probleem op te lossen, kunt u de logboeken aan de clientzijde van de Storage-clientbibliotheek gebruiken om het gedrag van uw clienttoepassing en hulpprogramma's, zoals Fiddler en Wireshark, te onderzoeken om uw netwerk te onderzoeken.

Zie Bijlage 1 voor meer informatie over het gebruik van Fiddler: Fiddler gebruiken om HTTP- en HTTPS-verkeer vast te leggen.

Zie bijlage 2: Wireshark gebruiken om netwerkverkeer vast te leggen voor meer informatie over het gebruik van Wireshark.

Bijlagen

In de indexen worden verschillende hulpprogramma's beschreven die nuttig kunnen zijn bij het diagnosticeren en oplossen van problemen met Azure Storage (en andere services). Deze hulpprogramma's maken geen deel uit van Azure Storage en sommige zijn producten van derden. Als zodanig worden de hulpprogramma's die in deze indexen worden besproken, niet gedekt door een ondersteuningsovereenkomst die u mogelijk hebt met Microsoft Azure of Azure Storage. Daarom moet u als onderdeel van uw evaluatieproces de licentie- en ondersteuningsopties onderzoeken die beschikbaar zijn bij de providers van deze hulpprogramma's.

Bijlage 1: Fiddler gebruiken om HTTP- en HTTPS-verkeer vast te leggen

Fiddler is een handig hulpprogramma voor het analyseren van het HTTP- en HTTPS-verkeer tussen uw clienttoepassing en de Azure Storage-service die u gebruikt.

Notitie

Fiddler kan HTTPS-verkeer decoderen. Lees de Fiddler-documentatie zorgvuldig om te begrijpen hoe dit werkt en wat de gevolgen zijn voor de beveiliging.

Deze bijlage bevat een kort overzicht van het configureren van Fiddler voor het vastleggen van verkeer tussen de lokale computer waarop u Fiddler en de Azure-opslagservices hebt geïnstalleerd.

Nadat u Fiddler hebt gestart, worden HTTP- en HTTPS-verkeer op uw lokale computer vastgelegd. Hier volgen enkele handige opdrachten voor het beheren van Fiddler:

  • Stop en begin met het vastleggen van verkeer. Ga in het hoofdmenu naar Bestand en selecteer Vervolgens Capture Traffic om vastleggen in of uit te schakelen.
  • Sla vastgelegde verkeersgegevens op. Ga in het hoofdmenu naar Bestand, selecteer Opslaan en selecteer vervolgens Alle sessies. Hiermee kunt u het verkeer opslaan in een sessiearchiefbestand. U kunt een sessiearchief later opnieuw laden voor analyse of verzenden als dit wordt gevraagd aan microsoft-ondersteuning.

Als u de hoeveelheid verkeer wilt beperken die fiddler vastlegt, kunt u filters gebruiken die u configureert op het tabblad Filters . In de volgende schermopname ziet u een filter waarmee alleen verkeer wordt vastgelegd dat naar het contosoemaildist.table.core.windows.net opslageindpunt wordt verzonden:

Schermopname van een filter dat alleen verkeer vastlegt dat naar het contosoemaildist.table.core.windows.net opslageindpunt wordt verzonden.

Bijlage 2: Wireshark gebruiken om netwerkverkeer vast te leggen

Wireshark is een netwerkprotocolanalyse waarmee u gedetailleerde pakketinformatie voor een breed scala aan netwerkprotocollen kunt bekijken.

In de volgende procedure ziet u hoe u gedetailleerde pakketgegevens kunt vastleggen voor verkeer vanaf de lokale computer waarop u Wireshark hebt geïnstalleerd naar de tabelservice in uw Azure-opslagaccount.

  1. Start Wireshark op uw lokale computer.

  2. Selecteer in de sectie Start de lokale netwerkinterface of interfaces die zijn verbonden met internet.

  3. Selecteer Opties voor vastleggen.

  4. Voeg een filter toe aan het tekstvak Capture Filter . Hiermee configureert u Bijvoorbeeld host contosoemaildist.table.core.windows.net Wireshark om alleen pakketten vast te leggen die zijn verzonden naar of van het eindpunt van de tabelservice in het opslagaccount contosoemaildist . Bekijk de volledige lijst met Capture-filters.

    Schermopname die laat zien hoe u een filter toevoegt aan het tekstvak Capture Filter.

  5. Selecteer Starten. Wireshark legt nu alle pakketten vast die naar of van het service-eindpunt van de tabel worden verzonden wanneer u uw clienttoepassing op uw lokale computer gebruikt.

  6. Wanneer u klaar bent, selecteert u Capture>Stop in het hoofdmenu.

  7. Als u de vastgelegde gegevens wilt opslaan in een Wireshark Capture-bestand, selecteert u Bestand>opslaan in het hoofdmenu.

WireShark markeert eventuele fouten die aanwezig zijn in het pakketlijstvenster . U kunt ook het venster Expert info (selecteer Expertgegevens analyseren>) gebruiken om een overzicht van fouten en waarschuwingen weer te geven.

Schermopname van het venster Expert Info, waar u een overzicht van fouten en waarschuwingen kunt bekijken.

U kunt er ook voor kiezen om de TCP-gegevens weer te geven terwijl de toepassingslaag deze ziet door met de rechtermuisknop op de TCP-gegevens te klikken en TCP Stream volgen te selecteren. Dit is handig als u uw dump hebt vastgelegd zonder een capture-filter. Zie Tcp-streams volgen voor meer informatie.

Schermopname die laat zien hoe u de TCP-gegevens kunt weergeven terwijl de toepassingslaag deze ziet.

Notitie

Zie de Wireshark-gebruikershandleiding voor meer informatie over het gebruik van Wireshark.

Bijlage 4: Excel gebruiken om metrische gegevens en logboekgegevens weer te geven

Met veel hulpprogramma's kunt u de metrische gegevens van Opslag uit Azure Table Storage downloaden in een indeling met scheidingstekens waarmee u de gegevens eenvoudig in Excel kunt laden voor weergave en analyse. Opslaglogboekgegevens van Azure Blob Storage hebben al een indeling met scheidingstekens die u in Excel kunt laden. U moet echter de juiste kolomkoppen toevoegen op basis van de informatie in Opslaganalyse Logboekindeling en Opslaganalyse Schema voor metrische gegevenstabel.

Als u uw opslaglogboekgegevens wilt importeren in Excel nadat u deze hebt gedownload uit blobopslag:

  • Selecteer in het menu Gegevens de optie Van tekst.
  • Blader naar het logboekbestand dat u wilt weergeven en selecteer Importeren.
  • Selecteer in stap 1 van de wizard Tekst importeren de optie Gescheiden.

Selecteer in stap 1 van de wizard Tekst importeren de optie Puntkomma als het enige scheidingsteken en kies dubbele aanhalingstekens als tekstscheidingsteken. Selecteer Vervolgens Voltooien en kies waar u de gegevens in uw werkmap wilt plaatsen.

Bijlage 5: Bewaking met Application Insights voor Azure DevOps

U kunt ook de Application Insights-functie voor Azure DevOps gebruiken als onderdeel van uw prestatie- en beschikbaarheidsbewaking. Met dit hulpprogramma kunt u het volgende doen:

  • Zorg ervoor dat uw webservice beschikbaar en responsief is. Of uw app nu een website of een apparaat-app is die gebruikmaakt van een webservice, het kan uw URL elke paar minuten vanaf locaties over de hele wereld testen en u laten weten of er een probleem is.
  • Stel snel prestatieproblemen of uitzonderingen in uw webservice vast. Ontdek of de CPU of andere resources worden uitgerekt, stacktraceringen ophalen uit uitzonderingen en eenvoudig zoeken in logboektraceringen. Als de prestaties van de app lager zijn dan acceptabele limieten, kan Microsoft u een e-mail sturen. U kunt zowel .NET- als Java-webservices bewaken.

Meer informatie vindt u in Wat is Application Insights.

Volgende stappen

Zie deze resources voor meer informatie over analyses in Azure Storage:

Disclaimerinformatie van derden

De producten van derden die in dit artikel worden vermeld, worden vervaardigd door bedrijven die onafhankelijk zijn van Microsoft. Microsoft verleent dan ook geen enkele garantie, impliciet noch anderszins, omtrent de prestaties of de betrouwbaarheid van deze producten.

Contacteer ons voor hulp

Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Azure-feedbackcommunity.