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 voornamelijk bedoeld om 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 te voorzien van de benodigde processen en hulpprogramma's om u te helpen bepalen of een 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.

Opmerking

Dit artikel is gebaseerd op het gebruik van Opslaganalyse metrische gegevens en logboeken die klassieke metrische gegevens en logboeken worden genoemd. We raden u aan 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 particuliere netwerken doorkruisen en kan uw toepassing gebruikmaken van meerdere opslagtechnologieën, zoals Microsoft Azure Storage tabellen, blobs, wachtrijen of bestanden, naast andere gegevensarchieven, zoals relationele databases en documentdatabases.

Als u dergelijke toepassingen met succes wilt beheren, moet u ze proactief bewaken en begrijpen hoe u alle aspecten en hun afhankelijke technologieën kunt diagnosticeren en oplossen. Als gebruiker van Azure Storage-services moet u de Opslagservices die door uw toepassing worden gebruikt, continu controleren op onverwachte wijzigingen in het gedrag (zoals tragere dan gebruikelijke reactietijden) en logboekregistratie gebruiken om gedetailleerdere gegevens te verzamelen en een probleem uitgebreid te analyseren. De diagnostische informatie die u verkrijgt van bewaking en logboekregistratie, helpt u de hoofdoorzaak te bepalen van het probleem dat in uw toepassing is opgetreden. Vervolgens kunt u het probleem oplossen en de juiste stappen bepalen om het op te lossen. Azure Storage is een azure-kernservice en vormt een belangrijk onderdeel van de meeste oplossingen die klanten implementeren in de Azure-infrastructuur. Azure Storage bevat mogelijkheden om het bewaken, diagnosticeren en oplossen van opslagproblemen in uw cloudtoepassingen te vereenvoudigen.

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 vaststellen 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 Probleemoplossingsrichtlijnen bevat richtlijnen voor het oplossen van enkele veelvoorkomende problemen met betrekking tot opslag die u kunt tegenkomen.

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 Performance Monitor-tellers. In Metrische opslaggegevens vindt u een uitgebreide set metrische gegevens (tellers in Windows Performance Monitor-terminologie), zoals de beschikbaarheid van de service, het totale aantal aanvragen voor service of het percentage geslaagde aanvragen voor service. Zie Opslaganalyse Tabelschema voor metrische gegevens voor een volledige lijst met beschikbare metrische gegevens. U kunt opgeven of de opslagservice elk uur of elke minuut metrische gegevens moet verzamelen en aggregeren. Zie Metrische gegevens over opslag 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 uurgegevens u wilt weergeven in de Azure Portal en regels configureren waarmee beheerders per e-mail worden gewaarschuwd wanneer een metrische waarde per uur een bepaalde drempelwaarde overschrijdt. Zie Waarschuwingsmeldingen ontvangen voor meer informatie.

We raden u aan 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. Hiervoor hoeft u niets in te schakelen of te configureren en u kunt deze metrische gegevens direct bekijken vanuit de vooraf gedefinieerde interactieve grafieken en andere visualisaties die zijn opgenomen.

De opslagservice doet zijn best om metrische gegevens te verzamelen, maar registreert mogelijk niet elke opslagbewerking.

In de Azure Portal kunt u metrische gegevens bekijken, zoals beschikbaarheid, totale aanvragen en gemiddelde latentiecijfers 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 een mogelijk gebied voor onderzoek het succespercentage van de tabelservice lager dan 100% (zie de sectie Metrics show low PercentSuccess or analytics log entries have bewerkingen with transaction status of ClientOtherErrors (Metrische gegevens tonen lage percentagesSuccess of vermeldingen in het analyselogboek hebben bewerkingen met de transactiestatus ClientOtherErrors ) voor meer informatie.

U moet uw Azure-toepassingen continu bewaken om ervoor te zorgen dat ze in orde zijn en naar verwachting presteren door:

  • Het vaststellen van enkele 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 ze vaststellen wanneer u de prestaties van uw toepassing test.
  • Metrische gegevens van minuten vastleggen en deze gebruiken om actief te controleren op onverwachte fouten en afwijkingen, zoals pieken in het aantal fouten of aanvraagsnelheden.
  • Metrische gegevens per uur vastleggen en deze gebruiken om gemiddelde waarden te bewaken, zoals het gemiddelde aantal fouten en aanvraagsnelheden.
  • Mogelijke problemen onderzoeken met behulp van diagnostische hulpprogramma's, zoals verderop in de sectie Opslagproblemen diagnosticeren .

In de grafieken in de volgende afbeelding ziet u hoe pieken in activiteit kunnen worden verborgen door het gemiddelde dat zich voor metrische gegevens per uur voordoet. De metrische gegevens per uur lijken een constante frequentie van aanvragen weer te geven, terwijl de metrische gegevens van de minuut de schommelingen laten zien die echt plaatsvinden.

Grafieken die laten zien hoe de gemiddelden die optreden voor metrische gegevens per uur pieken in activiteit kunnen verbergen.

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

Servicestatus bewaken

U kunt de 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 controle van invloed is op de Opslagservice in de regio die u voor uw toepassing gebruikt.

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

Opmerking

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.

Capaciteit bewaken

Metrische opslaggegevens slaan alleen metrische gegevens over de capaciteit op voor de blobservice, omdat blobs doorgaans het grootste deel van de opgeslagen gegevens vormen (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 hebt ingeschakeld voor de Blob-service. Metrische opslaggegevens registreert deze gegevens eenmaal per dag en u kunt de waarde van de RowKey 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 opslag (Capacity gemeten in bytes) en het huidige aantal containers (ContainerCount) en blobs (ObjectCount) dat in het opslagaccount wordt gebruikt. Zie Opslaganalyse Metrics Table Schema voor meer informatie over de metrische capaciteitsgegevens die zijn opgeslagen in de $MetricsCapacityBlob tabel.

Opmerking

U moet deze waarden controleren op een vroege 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 totale opslaggebruik de drempelwaarden overschrijdt of onder de drempelwaarden valt die u opgeeft.

Als u de grootte van verschillende opslagobjecten, zoals blobs, wilt schatten, raadpleegt u het blogbericht Azure Storage Billing – Bandwidth, Transactions, and Capacity ( Azure Storage Billing – Bandwidth, Transactions, and Capacity).

Beschikbaarheid bewaken

U moet de beschikbaarheid van de opslagservices in uw opslagaccount bewaken door de waarde in de Availability kolom in de metrische gegevenstabellen per uur of minuut te bewaken: $MetricsHourPrimaryTransactionsBlob, $MetricsHourPrimaryTransactionsTable, $MetricsHourPrimaryTransactionsQueue, $MetricsMinutePrimaryTransactionsBlob, $MetricsMinutePrimaryTransactionsTable, $MetricsMinutePrimaryTransactionsQueue. $MetricsCapacityBlob 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).

Een waarde van minder dan 100% geeft aan dat sommige opslagaanvragen mislukken. U kunt zien waarom ze mislukken door de andere kolommen in de metrische gegevens te onderzoeken die het aantal aanvragen met verschillende fouttypen weergeven, zoals ServerTimeoutError. U moet verwachten dat Availability de daling tijdelijk onder de 100% valt om redenen zoals tijdelijke servertime-outs terwijl de service partities verplaatst naar aanvragen voor een betere taakverdeling. De logica voor opnieuw proberen in uw clienttoepassing moet dergelijke onregelmatige omstandigheden verwerken. In het artikel Opslaganalyse Geregistreerde bewerkingen en statusberichten worden de transactietypen vermeld die metrische gegevens over opslag in de berekening worden Availability opgenomen.

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

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

Prestaties bewaken

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

  • De waarden in de AverageE2ELatency kolommen en AverageServerLatency geven de gemiddelde tijd aan die de opslagservice of het 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 (dus inclusief netwerklatentie zodra de aanvraag de opslagservice bereikt); AverageServerLatency is een meting van alleen de verwerkingstijd en sluit daarom netwerklatentie met betrekking tot communicatie met de client uit. Zie de sectie Metrics show high AverageE2ELatency and low AverageServerLatency verderop in deze handleiding voor een bespreking van waarom er mogelijk een significant verschil is tussen deze twee waarden.
  • De waarden in de TotalIngress kolommen en TotalEgress geven de totale hoeveelheid gegevens weer, in bytes, die binnenkomen en uitgaan van uw opslagservice of via een specifiek API-bewerkingstype.
  • 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 dat onderzoek vereist.

In de Azure Portal kunt u waarschuwingsregels toevoegen om u op de hoogte te stellen als metrische prestatiegegevens voor deze service onder een door u opgegeven drempelwaarde vallen of overschrijden.

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

Opslagproblemen diagnosticeren

Er zijn een aantal manieren waarop u op de hoogte kunt raken van een probleem of probleem in uw toepassing, waaronder:

  • Een grote 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 Storage-services vallen doorgaans in een van de vier algemene categorieën:

  • Uw toepassing heeft een prestatieprobleem dat wordt gerapporteerd door uw gebruikers of wordt weergegeven door wijzigingen in de metrische prestatiegegevens.
  • Er is een probleem met de Azure Storage-infrastructuur in een of meer regio's.
  • Uw toepassing ondervindt een fout, die wordt gerapporteerd door uw gebruikers of wordt weergegeven door een toename van 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 enkele 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. In de sectie Probleemoplossingsrichtlijnen verderop in deze handleiding vindt u meer informatie over enkele veelvoorkomende problemen die u kunt tegenkomen.

problemen met Servicestatus

Servicestatus problemen liggen meestal buiten uw controle. De Azure Portal biedt informatie over lopende problemen met Azure-services, waaronder opslagservices. Als u bij het maken van uw opslagaccount hebt gekozen voor Read-Access Geo-Redundant Storage en uw gegevens niet meer beschikbaar zijn op de primaire locatie, kan uw toepassing tijdelijk overschakelen naar de alleen-lezen kopie op de secundaire locatie. Als u wilt lezen vanuit de secundaire locatie, moet uw toepassing kunnen schakelen tussen het gebruik van de primaire en secundaire opslaglocatie en kunnen werken in een modus met beperkte functionaliteit 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 Azure Storage Redundanty Options and Read Access Geografisch redundante opslag voor meer informatie.

Prestatieproblemen

De prestaties van een toepassing kunnen subjectief zijn, met name vanuit gebruikersperspectief. Daarom is het belangrijk om basislijngegevens beschikbaar te hebben om te bepalen waar zich mogelijk een prestatieprobleem voordoet. Veel factoren kunnen van invloed zijn op de prestaties van een Azure Storage-service vanuit het perspectief van de clienttoepassing. Deze factoren kunnen werken in de opslagservice, de client of de netwerkinfrastructuur; Daarom is het belangrijk om een strategie te hebben voor het identificeren van de oorzaak van het prestatieprobleem.

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

De sectie Probleemoplossingsrichtlijnen verderop in deze handleiding bevat meer informatie over enkele veelvoorkomende prestatieproblemen die u kunt tegenkomen.

Fouten diagnosticeren

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

Opmerking

Houd er rekening mee dat u af en toe fouten moet zien, bijvoorbeeld fouten als gevolg van tijdelijke netwerkomstandigheden of toepassingsfouten.

De volgende resources zijn handig voor meer informatie over de status en foutcodes van 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 handig tijdens het ontwikkelen en testen, zodat u toepassingen kunt uitvoeren die gebruikmaken van Azure-opslagservices zonder dat u een Azure-abonnement en een Azure-opslagaccount nodig hebt.

In de sectie Probleemoplossingsrichtlijnen van deze handleiding worden enkele veelvoorkomende problemen beschreven die zijn opgetreden bij het gebruik van de opslagemulator.

Hulpprogramma's voor opslaglogboekregistratie

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

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

Opmerking

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 op de client ligt of netwerkbewakingshulpprogramma's gebruiken om het netwerk te onderzoeken.

Hulpprogramma's voor netwerklogboekregistratie gebruiken

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

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

End-to-end tracering

End-to-end tracering met behulp van verschillende logboekbestanden is een handige techniek voor het onderzoeken van mogelijke problemen. U kunt de datum-/tijdgegevens uit uw metrische gegevens gebruiken om aan te geven waar u in de logboekbestanden naar gedetailleerde informatie kunt zoeken om het probleem op te lossen.

Logboekgegevens correleren

Bij het bekijken van logboeken van clienttoepassingen, netwerktraceringen en opslaglogboekregistratie aan de serverzijde, is het essentieel om aanvragen in de verschillende logboekbestanden te kunnen correleren. 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 opslagclientbibliotheek 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 een die is vastgelegd door Fiddler, is de clientaanvraag-id zichtbaar in aanvraagberichten als http-headerwaarde x-ms-client-request-id .
  • In het logboek voor opslaglogboeken aan de serverzijde wordt de aanvraag-id van de client weergegeven in de kolom Clientaanvraag-id.

Opmerking

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 is verzonden vanuit de client, heeft de batch één clientaanvraag-id.

Serveraanvraag-id

De opslagservice genereert automatisch serveraanvraag-id's.

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

Opmerking

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

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

Tijdstempels

U kunt ook tijdstempels gebruiken om gerelateerde logboekvermeldingen te zoeken, maar wees voorzichtig met eventuele scheeftrekken van de klok tussen de client en de server. Search 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 dezelfde minuut of hetzelfde uur hebt.

Richtlijnen voor probleemoplossing

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 een laag percentageSuccess of vermeldingen in het analyselogboek hebben bewerkingen met de transactiestatus ClientOtherErrors.

Metrische gegevens over capaciteit geven een onverwachte toename van het gebruik van de opslagcapaciteit aan.

Uw probleem doet zich voor als u de opslagemulator gebruikt voor ontwikkeling of testen.

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

U hebt een ander probleem met een opslagservice.

Metrische gegevens tonen een hoge AverageE2ELatency en een lage AverageServerLatency

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

Afbeelding van de Azure Portal met een voorbeeld waarin de AverageE2ELatency aanzienlijk hoger is dan de AverageServerLatency.

De opslagservice berekent alleen de metrische gemiddeldeE2ELatency voor geslaagde aanvragen en omvat, 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 komen doordat de clienttoepassing traag reageert of door omstandigheden op het netwerk.

Opmerking

U kunt ook E2ELatency en ServerLatency weergeven voor afzonderlijke opslagbewerkingen in de logboekgegevens voor opslaglogboeken.

Prestatieproblemen van client onderzoeken

Mogelijke redenen voor het traag reageren van de client zijn onder andere het hebben van een beperkt aantal beschikbare verbindingen of threads of het feit dat er weinig resources beschikbaar zijn, zoals CPU, geheugen of netwerkbandbreedte. U kunt het probleem mogelijk oplossen door de clientcode efficiënter te maken (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 geschikt 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 indient en controleer op algemene . 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

Een hoge end-to-end latentie die door het netwerk wordt veroorzaakt, wordt meestal veroorzaakt door tijdelijke omstandigheden. U kunt zowel tijdelijke als permanente netwerkproblemen, zoals verwijderde pakketten, onderzoeken 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.

Metrische gegevens tonen een lage AverageE2ELatency en een lage AverageServerLatency, maar de client ondervindt een 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 niet worden doorgevoerd in de blobservice.

Een mogelijke reden waarom de client het verzenden van aanvragen vertraagt, 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 dat zo is. Om te bepalen of de client meerdere nieuwe pogingen uitvoert, kunt u het volgende doen:

  • Bekijk de Opslaganalyse logboeken. Als er meerdere nieuwe pogingen plaatsvinden, 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.
  • Foutopsporing in uw code en controleer de eigenschappen van het OperationContext object dat aan de aanvraag is gekoppeld. Als de bewerking opnieuw is geprobeerd, bevat de RequestResults eigenschap meerdere unieke serveraanvraag-id's. U kunt ook de begin- en eindtijd 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 mogelijke 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.

Metrische gegevens tonen een hoge AverageServerLatency

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

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

Hoge AverageServerLatency-waarden kunnen ook een symptoom zijn van slecht ontworpen tabellen of query's die resulteren in scanbewerkingen of die het toevoeg-/voorbewerkte antipatroon volgen. Zie Metrische gegevens tonen een toename in PercentThrottlingError voor meer informatie.

Opmerking

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

U ondervindt onverwachte vertragingen bij de bezorging van berichten in een wachtrij

Als u een vertraging ondervindt tussen het moment dat een toepassing een bericht aan een wachtrij toevoegt en het tijdstip waarop het bericht uit de wachtrij kan worden gelezen, 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 niet meerdere keren opnieuw probeert voordat het lukt. In de logboeken van de opslagclientbibliotheek worden eventuele herhaalde pogingen van opslagbewerkingen weergegeven.
  • Controleer of er geen klokverschil is tussen de werkrol die het bericht toevoegt aan de wachtrij en de werkrol die het bericht uit de wachtrij leest. Een scheefgetrokken klok zorgt ervoor dat het lijkt alsof er een vertraging is in de verwerking.
  • 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 is verstreken. Op dit moment is het bericht weer beschikbaar voor verwerking.
  • Controleer of de wachtrijlengte in de loop van de tijd toeneemt. Dit kan gebeuren als u onvoldoende werknemers beschikbaar hebt om alle berichten te verwerken die andere werknemers in de wachtrij plaatsen. Controleer ook de metrische gegevens om te zien of verwijderingsaanvragen mislukken en het aantal berichten in de wachtrij, wat kan duiden op herhaalde mislukte pogingen om het bericht te verwijderen.
  • Bekijk de logboeken voor logboekregistratie van opslag op wachtrijbewerkingen met een hogere E2ELatency - en ServerLatency-waarden gedurende een langere periode dan normaal.

Metrische gegevens geven een toename van PercentThrottlingError aan

Beperkingsfouten treden op wanneer u de schaalbaarheidsdoelen van een opslagservice overschrijdt. De opslagservice beperkt om ervoor te zorgen dat geen enkele client of tenant de service kan gebruiken ten koste van anderen. 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 laat zien van het percentage aanvragen dat mislukt met een beperkingsfout, moet u een van de volgende twee scenario's onderzoeken:

Een toename van PercentThrottlingError treedt vaak tegelijkertijd op als een toename van het aantal opslagaanvragen of wanneer u uw toepassing in eerste instantie laadt. Dit kan zich in de client ook manifesteren als HTTP-statusberichten van opslagbewerkingen als '503 Server bezet' of '500 Bewerkingstime-out'.

Tijdelijke toename van PercentThrottlingError

Als u pieken ziet in de waarde van PercentThrottlingError die samenvallen met perioden van hoge activiteit voor de toepassing, kunt u een exponentiële (niet lineaire) back-offstrategie implementeren voor nieuwe pogingen in uw client. Nieuwe pogingen voor back-off verminderen de onmiddellijke belasting van de partitie en helpen uw toepassing pieken in het verkeer af 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.

Opmerking

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

Permanente toename van PercentThrottlingError

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

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

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

Opmerking

Uw prestatietests moeten inefficiënte queryontwerpen in uw toepassing aan het licht brengen.

Metrische gegevens tonen een toename van PercentTimeoutError

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

Opmerking

Er kunnen tijdelijk time-outfouten optreden wanneer de opslagservice de taakverdeling van aanvragen verkrijgt 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 instellen voor een bewerking met behulp van de ServerTimeout eigenschap van de QueueRequestOptions klasse.

Time-outs van de server duiden op een probleem met de opslagservice dat nader moet worden onderzocht. U kunt metrische gegevens gebruiken om te zien of u de schaalbaarheidslimieten voor de service bereikt en om eventuele 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 persistent is en niet wordt veroorzaakt doordat uw toepassing de schaalbaarheidslimieten van de service heeft bereikt, moet u een ondersteuningsprobleem melden. Voor clienttime-outs moet u beslissen of de time-out is ingesteld op een juiste waarde in de client en de time-outwaarde wijzigen 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.

Metrische gegevens tonen een toename van PercentNetworkError

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 de 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 Bijlagen.

De client ontvangt HTTP 403-berichten (verboden)

Als uw clienttoepassing HTTP 403-fouten (verboden) genereert, is een waarschijnlijke oorzaak dat de client een verlopen Shared Access Signature (SAS) gebruikt wanneer deze een opslagaanvraag verzendt (hoewel andere mogelijke oorzaken zijn: klokscheefheid, ongeldige sleutels en lege headers). Als een verlopen SAS-sleutel de oorzaak is, ziet u geen vermeldingen in de logboekgegevens voor opslaglogboeken aan de serverzijde. In de volgende tabel ziet u een voorbeeld van het logboek aan de clientzijde dat is gegenereerd door de Storage-clientbibliotheek, waarin dit probleem wordt geïllustreerd:

Source Uitgebreidheid Uitgebreidheid Clientaanvraag-id Bewerkingstekst
Microsoft.Azure.Storage Informatie 3 85d077ab-... Starting operation with location Primary per location mode PrimaryOnly.
Microsoft.Azure.Storage Informatie 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 Informatie 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 Informatie 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 Informatie 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 Informatie 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 kan worden gebruikt. Als er kleine klokverschillen zijn tussen de host die de SAS genereert met behulp van de huidige tijd en de opslagservice, kan de opslagservice een SAS ontvangen die nog niet geldig is.
  • Stel geen zeer korte verlooptijd in voor een SAS. Nogmaals, kleine klokverschillen tussen de host die de SAS genereert en de opslagservice kunnen 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 bestaande SAS-tokens ongeldig worden gemaakt. Dit probleem kan zich voordoen als u SAS-tokens genereert met een lange verlooptijd voor clienttoepassingen in de cache.

Als u de Opslagclientbibliotheek 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 maakt, raadpleegt u Toegang delegeren met een Shared Access Signature.

De client ontvangt HTTP 404-berichten (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. Er zijn een aantal mogelijke redenen hiervoor, zoals:

De client of een ander proces heeft het object eerder verwijderd

In scenario's waarin de client probeert gegevens in een opslagservice te lezen, bij te werken of te verwijderen, is het meestal gemakkelijk om in de logboeken aan de serverzijde een eerdere bewerking te identificeren die het betreffende object uit de opslagservice heeft verwijderd. Vaak wordt in de logboekgegevens aangegeven dat een andere gebruiker of een ander proces het object heeft verwijderd. In het logboek voor opslaglogboeken 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 een object probeert in te voegen, is het mogelijk niet direct duidelijk waarom dit resulteert in een HTTP 404-antwoord (niet gevonden), aangezien 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 deze 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.

In het volgende logboek aan de clientzijde dat wordt gegenereerd door de opslagclientbibliotheek wordt het probleem geïllustreerd wanneer de client de container niet kan vinden voor de blob die wordt gemaakt. Dit logboek bevat details van de volgende opslagbewerkingen:

Aanvraag-ID Bewerking
07b26a5d-... DeleteIfExists 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 om de blobcontainer te maken. Houd er rekening mee dat deze bewerking een HEAD aanvraag bevat waarmee wordt gecontroleerd op het bestaan van de container. De HEAD retourneert een 404-bericht, maar gaat door.
de8b1c3c-... UploadFromStream methode om de blob te maken. 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 van de CreateIfNotExists methode (aanvraag-id e2d06d78...) koppelt aan de aanvragen van de UploadFromStream methode (de8b1c3c-...). 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 gegevens uploadt naar een blob in die container. In het ideale geval moet u al uw containers van tevoren maken.

Een probleem met sas-autorisatie (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 Waarde
Begintijd van aanvraag 2014-05-30T06:17:48.4473697Z
Bewerkingstype GetBlobProperties
Aanvraagstatus SASAuthorizationError
HTTP-statuscode 404
Verificatietype 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 van aanvraag-id <Header van aanvraag-id>
Clientaanvraag-id <Clientaanvraag-id>

Onderzoek waarom uw clienttoepassing probeert een bewerking uit te voeren waarvoor geen machtigingen zijn verleend.

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

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

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

Opmerking

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 JavaScript-problemen aan de clientzijde wilt oplossen.

Deze fouten treden op omdat de webbrowser dezelfde beveiligingsbeperking voor het 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 gebruikt. Zie Cross-Origin Resource Sharing (CORS)-ondersteuning voor Azure Storage Services voor meer informatie.

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

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 naar de client retourneert. Wanneer uw clienttoepassing bijvoorbeeld een entiteit uit de tabelservice verwijdert, ziet u dat de client een opslaguitzondering genereert met het bericht 'HTTP 404 (Niet gevonden)' van de tabelservice. 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 omvatten de aanvraag-id (7e84f12d...) die is toegewezen door de tabelservice voor de aanvraag. U kunt deze informatie gebruiken om de aanvraagdetails te vinden in de opslaglogboeken aan de serverzijde door te zoeken in de request-id-header kolom in het logboekbestand. U kunt de metrische gegevens ook gebruiken om te bepalen wanneer dergelijke fouten optreden en vervolgens de logboekbestanden doorzoeken op basis van het tijdstip waarop de metrische gegevens deze fout hebben vastgelegd. In dit logboek ziet u dat het verwijderen is mislukt met het statusbericht 'HTTP (404) Client Other Error'. Dezelfde logboekvermelding bevat ook de aanvraag-id die door de client is gegenereerd 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 verwijderingsbewerking voor dezelfde entiteit en van dezelfde client. Deze geslaagde verwijderingsbewerking vond plaats kort voor de mislukte verwijderingsaanvraag.

De meest waarschijnlijke oorzaak van dit scenario is dat de client een verwijderingsaanvraag 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 behulp van dezelfde client-request-id), en deze nieuwe poging is mislukt omdat de entiteit al was verwijderd.

Als dit probleem regelmatig 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' oversluiten en deze in de client registreren, maar de client toestaan om door te gaan.

De client ontvangt HTTP 409-berichten (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 aanvraag of CreateContainer .

Tijdstempel Bewerking 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 verwijdert 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 unieke containernamen gebruiken wanneer er nieuwe containers worden gemaakt als het patroon verwijderen/opnieuw maken gebruikelijk is.

Metrische gegevens tonen een laag percentageSuccess of analytische logboekvermeldingen hebben bewerkingen met de transactiestatus ClientOtherErrors

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

Het is belangrijk te weten dat deze bewerkingen zijn voltooid en daarom geen invloed hebben op andere metrische gegevens, zoals beschikbaarheid. Enkele voorbeelden van bewerkingen die met succes 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 van een CreateIfNotExist bewerking waarbij de resource al bestaat.
  • ConditionNotMet (Niet gewijzigd 304), bijvoorbeeld van een voorwaardelijke bewerking, zoals wanneer een client een ETag waarde en een HTTP-header If-None-Match verzendt om een afbeelding op te vragen, alleen als deze is bijgewerkt sinds de laatste bewerking.

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

Metrische gegevens over capaciteit geven een onverwachte toename van het gebruik van de opslagcapaciteit aan

Als u plotselinge, onverwachte wijzigingen ziet in het capaciteitsgebruik in uw opslagaccount, kunt u de redenen onderzoeken door eerst te kijken naar uw metrische beschikbaarheidsgegevens. Een toename van het aantal mislukte verwijderingsaanvragen kan bijvoorbeeld leiden tot een toename van de hoeveelheid blobopslag die u gebruikt als toepassingsspecifieke opschoningsbewerkingen waarvan u had verwacht dat ze ruimte vrijmaken, werken mogelijk niet zoals verwacht (bijvoorbeeld omdat de SAS-tokens die worden gebruikt voor het vrijmaken van ruimte, zijn verlopen).

Uw probleem ontstaat door het gebruik van de opslagemulator voor ontwikkeling of test

Meestal gebruikt u de opslagemulator tijdens het ontwikkelen en testen om te voorkomen dat er een Azure-opslagaccount nodig is. De veelvoorkomende problemen die kunnen optreden wanneer u de opslagemulator gebruikt, zijn:

Functie 'X' werkt niet in de opslagemulator

De opslagemulator ondersteunt niet alle functies van de Azure-opslagservices, zoals de bestandsservice. Zie De Azure Storage Emulator gebruiken voor ontwikkeling en testen voor meer informatie.

Gebruik de Azure-opslagservice in de cloud voor de functies die niet worden ondersteund door de opslagemulator.

Fout 'De waarde voor een van de HTTP-headers heeft niet de juiste indeling' bij gebruik van de opslagemulator

U test uw toepassing die gebruikmaakt van de Storage-clientbibliotheek op basis van de lokale opslagemulator en er wordt een methode aangeroepen, zoals CreateIfNotExists mislukt 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 gemaakt. Als de opslagemulator de waarde in de x-ms-version header niet herkent, wordt de aanvraag geweigerd.

U kunt de clientlogboeken van de opslagbibliotheek gebruiken om de waarde te bekijken van de x-ms-version header die wordt verzonden. U kunt ook de waarde van de x-ms-version header 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 Storage-clientbibliotheek installeert en gebruikt zonder de opslagemulator bij te werken. Installeer de nieuwste versie van de opslagemulator of gebruik cloudopslag 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 het eerst initialiseert. Nadat u de opslagemulator hebt geïnitialiseerd, hebt u geen beheerdersbevoegdheden nodig om deze opnieuw uit te voeren.

Zie De Azure Storage Emulator gebruiken voor ontwikkeling en testen voor meer informatie. U kunt ook de opslagemulator initialiseren in Visual Studio, waarvoor ook beheerdersbevoegdheden zijn vereist.

U ondervindt problemen met 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. Standaard gebruikt de opslagemulator LocalDB om gegevens te behouden 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 installeert.

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

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

U hebt een ander probleem met een opslagservice

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

  • Controleer uw metrische gegevens om te zien of er een wijziging is ten opzichte van het verwachte basislijngedrag. Op basis van de metrische gegevens kunt u mogelijk bepalen of het probleem tijdelijk of permanent is en op welke opslagbewerkingen het probleem van invloed is.
  • U kunt de metrische gegevens gebruiken om de logboekgegevens aan de serverzijde te doorzoeken voor meer gedetailleerde informatie over eventuele fouten die optreden. Deze informatie kan u helpen bij het oplossen van het probleem.
  • 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 Opslagclientbibliotheek gebruiken om het gedrag van uw clienttoepassing en hulpprogramma's zoals Fiddler en Wireshark te onderzoeken om uw netwerk te onderzoeken.

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

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

Bijlagen

In de bijlagen 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 bijlagen 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 bekijken 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.

Opmerking

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

In deze bijlage vindt u een kort overzicht van het configureren van Fiddler om verkeer vast te leggen tussen de lokale computer waarop u Fiddler hebt geïnstalleerd en de Azure-opslagservices.

Nadat u Fiddler hebt gestart, wordt 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 Verkeer vastleggen om vastleggen in en 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 het op verzoek verzenden naar 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 dat alleen verkeer vastlegt 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 pakketinformatie vastlegt voor verkeer van 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 Filter vastleggen . Configureert bijvoorbeeld host contosoemaildist.table.core.windows.net Wireshark om alleen pakketten vast te leggen die naar of van het eindpunt van de tabelservice in het opslagaccount contosoemaildist worden verzonden. Bekijk de volledige lijst met Capture Filters.

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

  5. Selecteer Start. Wireshark legt nu alle pakketten vast die naar of van het eindpunt van de tabelservice worden verzonden terwijl u uw clienttoepassing op uw lokale computer gebruikt.

  6. Wanneer u klaar bent, selecteert u Vastleggen>stoppen 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 in het pakketlijstvenster . U kunt ook het venster Expert-informatie gebruiken (selecteer Expertgegevens analyseren>) 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 opnamefilter. Zie Tcp-streams volgen voor meer informatie.

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

Opmerking

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 opslaggegevens downloaden uit Azure Table Storage in een gescheiden indeling, zodat 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.

Uw opslaglogboekgegevens importeren in Excel nadat u deze hebt gedownload uit blob-opslag:

  • Selecteer in het menu Gegevensde optie Uit 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 een dubbele aanhalingsteken 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 functie Application Insights 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, deze 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, haal stacktraceringen op van uitzonderingen en zoek eenvoudig in logboektraceringen. Als de prestaties van de app onder acceptabele limieten komen, kan Microsoft u een e-mail sturen. U kunt zowel .NET- als Java-webservices bewaken.

Meer informatie vindt u op 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 Feedback-community van Azure.