Loggning på klientsidan med klientbiblioteket för .NET

Med Azure Storage-klientbiblioteket för .NET (version 2.1 och senare) kan du logga Azure Storage-begäranden från .NET-klientprogrammet med hjälp av standardinfrastrukturen för .NET-diagnostik. På så sätt kan du se information om de begäranden som klienten skickar till Azure Storage-tjänster och de svar som den tar emot.

Azure Storage-klientbiblioteket ger dig kontroll över vilka lagringsbegäranden du kan logga, och .NET-diagnostikinfrastrukturen ger dig fullständig kontroll över loggdata, till exempel var du ska skicka dem. Du kan till exempel välja att skicka loggdata till en fil eller till ett program för bearbetning. I kombination med Azure Lagringsanalys och nätverksövervakning kan du använda loggning av klientbibliotek för att skapa en detaljerad bild av hur ditt program interagerar med Azure Storage-tjänster. Mer information finns i Övervaka, diagnostisera och felsöka Azure Storage.

Så här aktiverar du loggning av klientbibliotek

I följande exempel visas den system.diagnostics-konfiguration som krävs för att samla in och spara lagringsloggmeddelanden i en textfil. Konfigurationsavsnittet kan läggas till i antingen app.config- eller web.config-filer.

Anteckning

Om du använder en version som är äldre än 10.0.0 använder du namnet Microsoft.WindowsAzure.Storage i stället för 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>  
  

Anteckning

.NET Framework användare i version 4.6.1-4.7.1 (inklusive) kan få loggningsproblem när de använder .NET Standard 2.0-artefakterna i Azure Storage-biblioteken, som kan väljas automatiskt av Visual Studios NuGet-pakethanterare. Biblioteken publiceras också som .NET Framework 4.5.2 artefakter, som inte upplever dessa problem. Mer information finns i .NET Standard-versionsstöd.

Det här exemplet konfigurerar klientbiblioteket för att skriva loggmeddelanden till den fysiska filen C:\logs\WebRole.log. Du kan också använda andra spårningslyssnare som EventLogTraceListener för att skriva till Windows-händelseloggen eller EventProviderTraceListener för att skriva spårningsdata till ETW-undersystemet.

Viktigt

Den fullständiga mappsökvägen för loggfilen måste finnas i det lokala filsystemet. I det här exemplet innebär det att du först måste skapa C:\logs mappen innan du skriver loggar till en fil i mappen.

Dessutom kan du ange autoflush till true för att skriva loggposterna till filen direkt i stället för att buffrar dem. Den här inställningen kan vara användbar i en utvecklings-/testmiljö med låga mängder spårningsmeddelanden, men i en produktionsmiljö kanske du vill ange autoflush till false. Du använder konfigurationsinställningarna för att aktivera klientspårning (och för att ange nivån, till exempel Utförlig, för alla meddelanden) för alla lagringsåtgärder i klienten.

Id Loggnivå Händelser
0 Av Ingenting loggas.
1 Fel Om ett undantag inte kan hanteras internt och skickas till användaren loggas det som ett fel.
2 Varning Om ett undantag fångas och hanteras internt loggas det som en varning. Det primära användningsfallet för den här loggnivån är återförsöksscenariot, där ett undantag inte skickas tillbaka till användaren för att försöka igen. Det här beteendet kan också inträffa i åtgärder som CreateIfNotExists, där 404-felet hanteras tyst.
3 Information Följande information loggas:

•Direkt efter att användaren anropar en metod för att starta en åtgärd loggas begärandeinformation som URI och klientbegärans-ID.

•Viktiga milstolpar som att skicka start/slut för begäran, ladda upp data start/slut, start/slut för mottagningssvar, start/slut för nedladdning av data loggas för att markera tidsstämplarna.

•Direkt efter att rubrikerna har tagits emot loggas svarsinformation som begärande-ID och HTTP-statuskod.

•Om en åtgärd misslyckas och lagringsklienten bestämmer sig för att försöka igen loggas orsaken till beslutet tillsammans med information om när nästa återförsök kommer att ske.

•Alla tidsgränser på klientsidan loggas när en lagringsklient bestämmer sig för att avbryta en väntande begäran.
4 Verbose Följande information loggas:

•Sträng-till-signera för varje begäran.

•Eventuell extra information som är specifik för åtgärder (upp till varje åtgärd för att definiera och använda).

Som standard loggar klientbiblioteket information om alla lagringsåtgärder på den utförlighetsnivå som du anger i konfigurationsfilen. Du kan också begränsa loggningen till specifika områden i klientprogrammet för att minska mängden data som loggas och för att hjälpa dig att hitta den information du behöver. Om du vill begränsa mängden data som skrivs till loggarna måste du lägga till kod i klientprogrammet. När du har aktiverat spårning på klientsidan i konfigurationsfilen stänger du vanligtvis av den globalt i kod med hjälp av klassen OperationContext . Du kan till exempel göra detta i ett ASP.NET MVC-program i Application_Start-metoden innan programmet utför några lagringsåtgärder:

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

Du kan sedan aktivera spårning för de specifika åtgärder som du är intresserad av genom att skapa ett anpassat OperationContext-objekt som definierar loggningsnivån. Skicka sedan OperationContext-objektet som en parameter till metoden Execute som du använder för att anropa en lagringsåtgärd, som i följande exempel:

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

Loggschema och exempel på klientsidan

Följande exempel är ett utdrag från loggen på klientsidan som genereras av klientbiblioteket för en åtgärd med ett klientbegärans-ID som innehåller c3aa328b. Klientbegärans-ID:t är en korrelationsidentifierare som gör att meddelanden som loggas på klientsidan kan korreleras med nätverksspårningar och lagringsloggar. Mer information om korrelation finns i Övervaka, diagnostisera och felsöka Azure Storage. Extraktet innehåller kommentarer (indragna och kursiviserade) på viss viktig information som kan observeras inifrån loggfilerna.

För att illustrera den här funktionen med hjälp av den första raden i följande loggfil är fälten:

Loggfält Värde
Källa Microsoft.Azure.Storage
Informationsnivån Information
Verbosity Nej 3
Klientbegärans-ID c3aa328b...
Åtgärdstext Startar åtgärden med plats primärt per platsläge PrimaryOnly.

Microsoft.Azure.Storage Information: 3 : c3aa328b...: Starting operation with location Primary per location mode PrimaryOnly.
Föregående spårningsmeddelande visar att platsläget endast är inställt på primärt, vilket innebär att en misslyckad begäran inte skickas till en sekundär plats.
Microsoft.Azure.Storage Information: 3 : c3aa328b...: Starting synchronous request to https://storageaccountname.table.core.windows.net/mailinglist.
Föregående spårningsmeddelande visar att begäran är synkron.
Microsoft.Azure.Storage Information: 3 : c3aa328b...: Setting payload format for the request to 'Json'.
Föregående spårningsmeddelande visar att svaret ska returneras formaterat som JSON.
Microsoft.Azure.Storage Verbose: 4 : c3aa328b...: StringToSign = GET...Fri, 23 May 2014 06:19:48 GMT./storageaccountname/mailinglist.
Föregående spårningsmeddelande innehåller StringToSign-informationen, vilket är användbart för felsökning av autentiseringsfel. Utförliga meddelanden innehåller också fullständig information om begäran, inklusive åtgärdstyp och begärandeparametrar.
Microsoft.Azure.Storage Information: 3 : c3aa328b...: Waiting for response.
Föregående spårningsmeddelande visar att begäran har skickats och att klienten väntar på ett svar.
Microsoft.Azure.Storage Information: 3 : c3aa328b...: Response received. Status code = 200, Request ID = 417db530-853d-48a7-a23c-0c8d5f728178, Content-MD5 = , ETag =
Föregående spårningsmeddelande visar att svaret har tagits emot och dess http-statuskod.
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 ''.
Föregående spårningsmeddelande visar att 8 resultat hämtades och ingen fortsättningstoken angavs, vilket innebär att det inte finns några fler resultat för den här frågan.
Microsoft.Azure.Storage Information: 3 : c3aa328b...: Operation completed successfully.
Föregående spårningsmeddelande visar att åtgärden har slutförts.

Följande två utförliga loggposter (nivå 4) visar en HEAD- och DELETE-begäran och illustrerar den detaljerade informationen i fältet Åtgärdstext :
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.
Föregående spårningsmeddelande visar fältet OperationText i utförliga spårningsmeddelanden, inklusive detaljerad information om en specifik begäran. Den här informationen omfattar HTTP-åtgärdstypen (till exempel HEAD, DELETE, POST), klientbegärans-ID, tidsstämpel, SDK-version och ytterligare åtgärdsspecifika data.