Condividi tramite

Registrazione lato client con la libreria client per .NET

  • Articolo

Con la libreria client di Archiviazione di Azure per .NET (versione 2.1 e successive), è possibile registrare le richieste di Archiviazione di Azure dall'applicazione client .NET usando l'infrastruttura di diagnostica .NET standard. In questo modo, è possibile visualizzare i dettagli delle richieste inviate dal client ai servizi di archiviazione di Azure e le risposte ricevute.

La libreria client di Archiviazione di Azure consente di controllare le richieste di archiviazione che è possibile registrare e l'infrastruttura di diagnostica .NET offre il controllo completo sui dati di log, ad esempio dove inviarli. Ad esempio, è possibile scegliere di inviare i dati di log a un file o a un'applicazione per l'elaborazione. In combinazione con Azure Analisi archiviazione e il monitoraggio della rete, è possibile usare la registrazione della libreria client per creare un'immagine dettagliata del modo in cui l'applicazione interagisce con i servizi di archiviazione di Azure. Per altre informazioni, vedere Monitorare, diagnosticare e risolvere i problemi di Archiviazione di Azure.

Come abilitare la registrazione della libreria client

Il seguente esempio illustra la configurazione system.diagnostics necessaria per raccogliere e memorizzare i messaggi di log in un file di testo. La sezione di configurazione può essere aggiunta ai file app.config o web.config.

Nota

Se si usa una versione precedente alla 10.0.0, usare il nome Microsoft.WindowsAzure.Storage anziché 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>

Nota

Gli utenti di .NET Framework nelle versioni 4.6.1-4.7.1 (incluse) possono riscontrare problemi di registrazione quando si usano gli artefatti .NET Standard 2.0 delle librerie di Archiviazione di Azure, che possono essere selezionati automaticamente dalla gestione pacchetti NuGet di Visual Studio. Le librerie vengono pubblicate anche come artefatti di .NET Framework 4.5.2, che non riscontrano questi problemi. Per altre informazioni, vedere supporto della versione di .NET Standard.

In questo esempio viene configurata la libreria client per scrivere messaggi di log nel file C:\logs\WebRole.logfisico . È anche possibile usare altri listener di traccia, ad esempio EventLogTraceListener , per scrivere nel registro eventi di Windows o EventProviderTraceListener per scrivere dati di traccia nel sottosistema ETW.

Importante

Il percorso completo della cartella per il file di log deve esistere nel file system locale. In questo esempio, ciò significa che è necessario creare la C:\logs cartella prima di scrivere i log in un file in tale cartella.

Inoltre, è possibile impostare autoflush su true per scrivere immediatamente le voci di log nel file anziché memorizzarle nel buffer. Questa impostazione può essere utile in un ambiente di sviluppo/test con volumi limitati di messaggi di traccia, ma in un ambiente di produzione potrebbe essere necessario impostare l'impatto automatico su false. Usare le impostazioni di configurazione per abilitare la traccia client (e per specificare il livello, ad esempio Verbose, per tutti i messaggi) per tutte le operazioni di archiviazione nel client.

ID Livello registro evento
0 Off Non viene registrato nulla.
1 Errore Se un'eccezione non può essere gestita internamente e viene generata all'utente, viene registrata come errore.
2 Avviso Se un'eccezione viene intercettata e gestita internamente, viene registrata come avviso. Il caso d'uso principale per questo livello di log è lo scenario di ripetizione dei tentativi, in cui non viene generata un'eccezione all'utente per riprovare. Questo comportamento può verificarsi anche in operazioni come CreateIfNotExists, in cui l'errore 404 viene gestito automaticamente.
3 Informativo Vengono registrate le informazioni seguenti:

•Subito dopo che l'utente chiama un metodo per avviare un'operazione, vengono registrati i dettagli della richiesta, ad esempio URI e ID richiesta client.

•Attività cardine importanti, ad esempio l'avvio/fine della richiesta di invio, l'inizio/fine del caricamento dei dati, l'inizio/fine della risposta di ricezione, l'inizio/fine del download dei dati vengono registrati per contrassegnare i timestamp.

•Subito dopo la ricezione delle intestazioni, vengono registrati i dettagli della risposta, ad esempio l'ID richiesta e il codice di stato HTTP.

•Se un'operazione non riesce e il client di archiviazione decide di riprovare, il motivo della decisione viene registrato insieme alle informazioni su quando si verificherà il nuovo tentativo successivo.

•Tutti i timeout lato client vengono registrati quando un client di archiviazione decide di interrompere una richiesta in sospeso.
4 Dettagliato Vengono registrate le informazioni seguenti:

•Da stringa a firma per ogni richiesta.

•Eventuali dettagli aggiuntivi specifici delle operazioni (fino a ogni operazione da definire e utilizzare).

Per impostazione predefinita, la libreria client registra i dettagli di tutte le operazioni di archiviazione a livello di dettaglio specificato nel file di configurazione. È anche possibile limitare la registrazione a aree specifiche dell'applicazione client per ridurre la quantità di dati registrati e per trovare le informazioni necessarie. Per limitare la quantità di dati scritti nei log, è necessario aggiungere codice all'applicazione client. In genere, dopo aver abilitato la traccia sul lato client nel file di configurazione, è possibile disattivarla a livello globale nel codice usando la classe OperationContext . Ad esempio, è possibile eseguire questa operazione in un'applicazione MVC ASP.NET nel metodo Application_Start prima che l'applicazione esegua qualsiasi operazione di archiviazione:

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

È quindi possibile abilitare la traccia per le operazioni specifiche a cui si è interessati creando un oggetto OperationContext personalizzato che definisce il livello di registrazione. Passare quindi l'oggetto OperationContext come parametro al metodo Execute usato per richiamare un'operazione di archiviazione, come nell'esempio seguente:

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

Schema ed esempio di log lato client

L'esempio seguente è un estratto dal log lato client generato dalla libreria client per un'operazione con un ID richiesta client che include c3aa328b. L'ID richiesta client è un identificatore di correlazione che consente la correlazione dei messaggi connessi sul lato client con le tracce di rete e i log di archiviazione. Per altre informazioni sulla correlazione, vedere Monitorare, diagnosticare e risolvere i problemi di Archiviazione di Azure. L'estratto comprende dei commenti (contrassegnati con rientro e corsivo) su alcune informazioni chiave che è possibile osservare dall'interno dei file di log.

Per illustrare questa funzionalità usando la prima riga del file di log seguente, i campi sono:

Campo log Valore
Origine Microsoft.Azure.Storage
Dettaglio Informazioni
Numero livello di dettaglio 3
ID richiesta client c3aa328b...
testo dell'operazione Avvio operazione con posizione primaria in base alla modalità di posizionamento PrimaryOnly.

Microsoft.Azure.Storage Information: 3 : c3aa328b...: Starting operation with location Primary per location mode PrimaryOnly.
Il messaggio di traccia precedente mostra che la modalità posizione è impostata solo su primaria, ovvero una richiesta non riuscita non verrà inviata a una posizione secondaria.
Microsoft.Azure.Storage Information: 3 : c3aa328b...: Starting synchronous request to https://storageaccountname.table.core.windows.net/mailinglist.
Il messaggio di traccia precedente indica che la richiesta è sincrona.
Microsoft.Azure.Storage Information: 3 : c3aa328b...: Setting payload format for the request to 'Json'.
Il messaggio di traccia precedente mostra che la risposta deve essere restituita formattata come JSON.
Microsoft.Azure.Storage Verbose: 4 : c3aa328b...: StringToSign = GET...Fri, 23 May 2014 06:19:48 GMT./storageaccountname/mailinglist.
Il messaggio di traccia precedente include le informazioni StringToSign, utili per il debug degli errori di autenticazione. I messaggi dettagliati contengono anche i dettagli completi della richiesta, inclusi i parametri del tipo di operazione e della richiesta.
Microsoft.Azure.Storage Information: 3 : c3aa328b...: Waiting for response.
Il messaggio di traccia precedente indica che la richiesta è stata inviata e che il client è in attesa di una risposta.
Microsoft.Azure.Storage Information: 3 : c3aa328b...: Response received. Status code = 200, Request ID = 417db530-853d-48a7-a23c-0c8d5f728178, Content-MD5 = , ETag =
Il messaggio di traccia precedente mostra che la risposta è stata ricevuta e il relativo codice di stato HTTP.
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 ''.
Il messaggio di traccia precedente mostra che sono stati recuperati 8 risultati e non è stato fornito alcun token di continuazione, ovvero non sono presenti altri risultati per questa query.
Microsoft.Azure.Storage Information: 3 : c3aa328b...: Operation completed successfully.
Il messaggio di traccia precedente indica che l'operazione è stata completata correttamente.

Le due voci di log dettagliate (livello 4) seguenti mostrano una richiesta HEAD e DELETE e illustrano le informazioni dettagliate nel campo Testo operazione :
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.
Il messaggio di traccia precedente mostra il campo OperationText all'interno di messaggi di traccia dettagliati, incluse informazioni dettagliate correlate a una richiesta specifica. Questi dettagli includono il tipo di operazione HTTP (ad esempio HEAD, DELETE, POST), l'ID richiesta client, il timestamp, la versione dell'SDK e dati aggiuntivi specifici dell'operazione.