Logboekregistratie aan de clientzijde met de clientbibliotheek voor .NET
Met de Azure Storage-clientbibliotheek voor .NET (versie 2.1 en hoger) kunt u Azure Storage-aanvragen registreren vanuit uw .NET-clienttoepassing met behulp van de standaard .NET-diagnostische infrastructuur. Op deze manier kunt u details bekijken van de aanvragen die uw client naar Azure Storage-services verzendt en de antwoorden die deze ontvangt.
De Azure Storage-clientbibliotheek geeft u controle over welke opslagaanvragen u kunt registreren en de diagnostische infrastructuur van .NET geeft u volledige controle over de logboekgegevens, zoals waar u deze kunt verzenden. U kunt er bijvoorbeeld voor kiezen om de logboekgegevens naar een bestand of een toepassing te verzenden voor verwerking. In combinatie met Azure Opslaganalyse en netwerkbewaking kunt u logboekregistratie van de clientbibliotheek gebruiken om een gedetailleerd beeld te maken van de interactie tussen uw toepassing en Azure Storage-services. Zie Azure Storage bewaken, diagnosticeren en problemen oplossen voor meer informatie.
Logboekregistratie van clientbibliotheek inschakelen
In het volgende voorbeeld ziet u de system.diagnostics-configuratie die nodig is voor het verzamelen en persistent maken van opslaglogboekberichten in een tekstbestand. De configuratiesectie kan worden toegevoegd aan app.config- of web.config-bestanden.
Notitie
Als u een versie gebruikt die ouder is dan 10.0.0, gebruikt u de naam Microsoft.WindowsAzure.Storage in plaats van Microsoft.Azure.Storage.
<system.diagnostics>
<!--In a dev/test environment you can set autoflush to true in order to autoflush to the log file. -->
<trace autoflush="false">
<listeners>
...
<add name="storageListener" />
</listeners>
</trace>
<sources>
<source name="Microsoft.Azure.Storage">
<listeners>
<add name="storageListener"/>
</listeners>
</source>
</sources>
<switches>
<add name="Microsoft.Azure.Storage" value="Verbose" />
</switches>
<sharedListeners>
<add name="storageListener"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="C:\logs\WebRole.log"
traceOutputOptions="DateTime" />
</sharedListeners>
</system.diagnostics>
Notitie
.NET Framework gebruikers met versies 4.6.1-4.7.1 (inclusief) kunnen logboekregistratieproblemen ondervinden bij het gebruik van de .NET Standard 2.0-artefacten van de Azure Storage-bibliotheken, die automatisch kunnen worden geselecteerd door NuGet-pakketbeheer van Visual Studio. De bibliotheken worden ook gepubliceerd als .NET Framework 4.5.2-artefacten, die deze problemen niet ondervinden. Lees voor meer informatie over .NET Standard-versieondersteuning.
In dit voorbeeld wordt de clientbibliotheek geconfigureerd voor het schrijven van logboekberichten naar het fysieke bestand C:\logs\WebRole.log. U kunt ook andere traceringslisteners gebruiken, zoals de EventLogTraceListener om naar het Windows-gebeurtenislogboek te schrijven of de EventProviderTraceListener om traceringsgegevens naar het ETW-subsysteem te schrijven.
Belangrijk
Het volledige mappad voor het logboekbestand moet bestaan in het lokale bestandssysteem. In dit voorbeeld betekent dit dat u eerst de C:\logs map moet maken voordat u logboeken naar een bestand in die map schrijft.
Daarnaast kunt u autoflush instellen op true om de logboekvermeldingen onmiddellijk naar het bestand te schrijven in plaats van ze te bufferen. Deze instelling kan handig zijn in een ontwikkel-/testomgeving met weinig traceringsberichten, maar in een productieomgeving kunt u autoflush instellen op false. U gebruikt de configuratie-instellingen om clienttracering in te schakelen (en om het niveau, zoals Uitgebreid, op te geven voor alle berichten) voor alle opslagbewerkingen in de client.
| Id | Logboekniveau | gebeurtenis |
|---|---|---|
| 0 | Aan | Er wordt niets geregistreerd. |
| 1 | Fout | Als een uitzondering niet intern kan worden verwerkt en naar de gebruiker wordt gegenereerd, wordt deze geregistreerd als een fout. |
| 2 | Waarschuwing | Als een uitzondering intern wordt ondervangen en verwerkt, wordt deze geregistreerd als een waarschuwing. Het primaire gebruiksvoorbeeld voor dit logboekniveau is het scenario voor opnieuw proberen, waarbij een uitzondering niet wordt teruggegooid naar de gebruiker om het opnieuw te proberen. Dit gedrag kan ook optreden in bewerkingen zoals CreateIfNotExists, waarbij de 404-fout op de achtergrond wordt verwerkt. |
| 3 | Informatief | De volgende informatie wordt geregistreerd: •Direct nadat de gebruiker een methode aanroept om een bewerking te starten, worden aanvraaggegevens zoals URI en clientaanvraag-id geregistreerd. •Belangrijke mijlpalen, zoals begin/einde van aanvraag verzenden, begin/einde van gegevens uploaden, begin/einde van ontvangstreactie, begin/einde van downloadgegevens, worden geregistreerd om de tijdstempels te markeren. •Direct nadat de headers zijn ontvangen, worden antwoorddetails zoals aanvraag-id en HTTP-statuscode vastgelegd. •Als een bewerking mislukt en de opslagclient besluit het opnieuw te proberen, wordt de reden voor die beslissing geregistreerd, samen met informatie over wanneer de volgende nieuwe poging wordt uitgevoerd. •Alle time-outs aan de clientzijde worden geregistreerd wanneer een opslagclient besluit een in behandeling zijnde aanvraag af te breken. |
| 4 | Uitgebreid | De volgende informatie wordt geregistreerd: •Tekenreeks om te ondertekenen voor elke aanvraag. •Eventuele extra details die specifiek zijn voor bewerkingen (tot elke bewerking die moet worden gedefinieerd en gebruikt). |
Standaard registreert de clientbibliotheek details van alle opslagbewerkingen op het uitgebreidheidsniveau dat u opgeeft in het configuratiebestand. U kunt logboekregistratie ook beperken tot specifieke gebieden van uw clienttoepassing om de hoeveelheid vastgelegde gegevens te verminderen en om u te helpen de informatie te vinden die u nodig hebt. Als u de hoeveelheid gegevens die naar de logboeken worden geschreven, wilt beperken, moet u code toevoegen aan uw clienttoepassing. Na het inschakelen van tracering aan de clientzijde in het configuratiebestand, schakelt u deze doorgaans globaal uit in code met behulp van de klasse OperationContext . U kunt dit bijvoorbeeld doen in een ASP.NET MVC-toepassing in de methode Application_Start voordat uw toepassing opslagbewerkingen uitvoert:
protected void Application_Start()
{
...
// Disable Default Logging for Windows Azure Storage
OperationContext.DefaultLogLevel = LogLevel.Off;
// Verify that all of the tables, queues, and blob containers used in this application
// exist, and create any that don't already exist.
CreateTablesQueuesBlobContainers();
}
U kunt vervolgens tracering inschakelen voor de specifieke bewerkingen waarin u geïnteresseerd bent door een aangepast OperationContext-object te maken dat het logboekregistratieniveau definieert. Geef vervolgens het object OperationContext als parameter door aan de methode Execute die u gebruikt om een opslagbewerking aan te roepen, zoals in het volgende voorbeeld:
[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Create(Subscriber subscriber)
{
if (ModelState.IsValid)
{
...
var insertOperation = TableOperation.Insert(subscriber);
OperationContext verboseLoggingContext = new OperationContext() { LogLevel = LogLevel.Verbose };
mailingListTable.Execute(insertOperation, null, verboseLoggingContext);
return RedirectToAction("Index");
}
...
return View(subscriber);
}
Logboekschema en voorbeeld aan clientzijde
Het volgende voorbeeld is een extract uit het logboek aan de clientzijde dat is gegenereerd door de clientbibliotheek voor een bewerking met een clientaanvraag-id die c3aa328b bevat. De clientaanvraag-id is een correlatie-id waarmee berichten die aan de clientzijde zijn geregistreerd, kunnen worden gecorreleerd met netwerktraceringen en opslaglogboeken. Zie Azure Storage bewaken, diagnosticeren en problemen oplossen voor meer informatie over correlatie. Het extract bevat commentaar (ingesprongen en cursief) op bepaalde belangrijke informatie die vanuit de logboekbestanden kan worden waargenomen.
Om deze functionaliteit te illustreren aan de hand van de eerste rij van het volgende logboekbestand, zijn de velden:
| Logboekveld | Waarde |
|---|---|
| Bron | Microsoft.Azure.Storage |
| Uitgebreidheid | Informatie |
| Uitgebreidheidsnr. | 3 |
| Clientaanvraag-id | c3aa328b... |
| Bewerkingstekst | Bewerking starten met locatie Primair per locatiemodus PrimaryOnly. |
Microsoft.Azure.Storage Information: 3 : c3aa328b...: Starting operation with location Primary per location mode PrimaryOnly.
In het voorgaande traceringsbericht ziet u dat de locatiemodus alleen is ingesteld op primair, wat betekent dat een mislukte aanvraag niet naar een secundaire locatie wordt verzonden.
Microsoft.Azure.Storage Information: 3 : c3aa328b...: Starting synchronous request to https://storageaccountname.table.core.windows.net/mailinglist.
In het voorgaande traceringsbericht wordt aangegeven dat de aanvraag synchroon is.
Microsoft.Azure.Storage Information: 3 : c3aa328b...: Setting payload format for the request to 'Json'.
In het voorgaande traceringsbericht ziet u dat het antwoord moet worden geretourneerd als JSON.
Microsoft.Azure.Storage Verbose: 4 : c3aa328b...: StringToSign = GET...Fri, 23 May 2014 06:19:48 GMT./storageaccountname/mailinglist.
Het voorgaande traceringsbericht bevat de StringToSign-informatie, die handig is voor het opsporen van verificatiefouten. Uitgebreide berichten bevatten ook volledige aanvraagdetails, waaronder bewerkingstype en aanvraagparameters.
Microsoft.Azure.Storage Information: 3 : c3aa328b...: Waiting for response.
In het voorgaande traceringsbericht ziet u dat de aanvraag is verzonden en dat de client wacht op een antwoord.
Microsoft.Azure.Storage Information: 3 : c3aa328b...: Response received. Status code = 200, Request ID = 417db530-853d-48a7-a23c-0c8d5f728178, Content-MD5 = , ETag =
In het voorgaande traceringsbericht ziet u dat het antwoord is ontvangen en de http-statuscode.
Microsoft.Azure.Storage Information: 3 : c3aa328b...: Response headers were processed successfully, proceeding with the rest of the operation.
Microsoft.Azure.Storage Information: 3 : c3aa328b...: Processing response body.
Microsoft.Azure.Storage Information: 3 : c3aa328b...: Retrieved '8' results with continuation token ''.
In het voorgaande traceringsbericht ziet u dat er acht resultaten zijn opgehaald en dat er geen vervolgtoken is opgegeven, wat betekent dat er geen resultaten meer zijn voor deze query.
Microsoft.Azure.Storage Information: 3 : c3aa328b...: Operation completed successfully.
In het voorgaande traceringsbericht ziet u dat de bewerking is voltooid.
De volgende twee uitgebreide logboekvermeldingen (niveau 4) tonen een HEAD- en een DELETE-aanvraag en illustreren de gedetailleerde informatie in het veld Bewerkingstekst :
Microsoft.Azure.Storage Verbose: 4 : 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./storageaccountname/azuremmblobcontainer.restype:container.
Microsoft.Azure.Storage Verbose: 4 : 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./storageaccountname/azuremmblobcontainer.restype:container.
In het voorgaande traceringsbericht wordt het veld OperationText weergegeven in uitgebreide traceringsberichten, inclusief gedetailleerde informatie met betrekking tot een specifieke aanvraag. Deze details omvatten het HTTP-bewerkingstype (bijvoorbeeld HEAD, DELETE, POST), de clientaanvraag-id, de tijdstempel, SDK-versie en aanvullende bewerkingsspecifieke gegevens.