Il presente articolo è stato tradotto automaticamente.

Diagnostica Cloud

Controllo della registrazione e della traccia in Windows Azure

Mike Kelly

Scaricare il codice di esempio

Come molti programmatori, quando ho iniziato a scrivere codice ho utilizzato le istruzioni di stampa per il debug. Non so come utilizzare un debugger e le istruzioni di stampa erano un crude ma è stato eseguito in modo efficace per vedere come si stava eseguendo il programma. Successivamente, ho imparato a utilizzare un debugger reale ed eliminare le istruzioni di stampa come strumento di debug.

Inoltrare rapidamente all'avvio di scrivere codice che viene eseguito sul server. Ho scoperto che quelli stampati istruzioni ora passare in più sofisticati del “ registrazione e analisi, ” tecniche fondamentali per qualsiasi programmatore dell'applicazione server.

Anche se è possibile associare un debugger a un'applicazione server di produzione, che spesso non possibile a causa di restrizioni di protezione sul computer che ospita l'applicazione, ovvero i tipi di problemi in applicazioni di server non sono facilmente protetta con debugger tradizionali. Molte applicazioni server vengono distribuite in esecuzione su più computer, e ciò che accade in un computer di debug non è sempre sufficiente per diagnosticare problemi reali.

Inoltre, le applicazioni server spesso eseguiti sotto il controllo di uno staff di operazioni non sapere come utilizzare un debugger tradizionale e la chiamata di uno sviluppatore per ogni problema non è praticabile o auspicabile.

In questo articolo spiegherò alcune registrazione base di analisi e debug tecniche utilizzate per le applicazioni server. Quindi verrà è possibile approfondire come queste tecniche possono essere utilizzate per i progetti Windows Azure. Lungo il percorso si vedrà come registrazione e analisi vengono utilizzati con alcune applicazioni reali e verrà illustrato come utilizzare Windows PowerShell per la gestione di diagnostica per un servizio in esecuzione.

Una strategia di registrazione

In teoria, qualsiasi applicazione server, e praticamente tutte le applicazioni Web, inclusi quelli in esecuzione in Windows Azure, è una registrazione e analisi strategia progettato dall'inizio. Le informazioni di registrazione devono essere idonea per descrivere quasi tutto ciò che accade all'interno di ciascun componente. Tuttavia, come quelli di stampa istruzioni aggiunte ai programmi primo potrebbero generare una grande quantità di output, così troppo possibile la registrazione. Registrazione ben progettata e analisi include pertanto modi per modificare il tipo e il volume di registrazione da qualsiasi componente. Ciò consente al personale operativo e agli sviluppatori di concentrarsi su un particolare componente inadeguato, forse anche su un determinato computer, per ottenere più informazioni su esattamente 
what del corso all'interno, senza generare una grande quantità di disturbo del log può essere significativamente distrazione e forse rallentamento dell'applicazione.

Inoltre, poiché le applicazioni server sono applicazioni comunemente distribuite, informazioni devono essere raccolte e aggregate da più computer (probabilmente nell'applicazione diversi ruoli) per ottenere un'immagine completa di ciò che doveva su cui si è verificato un problema particolare. Un modo per identificare un thread di transazione tramite il computer è pertanto importante, consentendo l'aggregazione posteriori.

Registrazione disponibile in Windows Azure ha maturare attraverso le versioni CTP (Community Technology Preview). La registrazione iniziale non era molto più sofisticata rispetto a un'istruzione print, acquisita come testo in Windows Azure tabella di archiviazione. A partire dal rilascio PDC09 Windows Azure ha iniziato a offrire un accesso molto più completo e infrastruttura di traccia, in base al framework Event Tracing for Windows (ETW).

Questo framework ETW è supportato in ASP.NET tramite le classi dello spazio dei nomi System.Diagnostics. Lo spazio dei nomi Microsoft.WindowsAzure.Diagnostics, che eredita da ed estende classi System.Diagnostics standard, consente di utilizzare System.Diagnostics come un framework di registrazione in ambiente Windows Azure. Figura 1 Mostra come ETW è implementata dalla diagnostica Windows Azure.

Figura 1 Panoramica generale di Windows Diagnostics azzurro

ETW fornisce un modello nei registri codice per una o più TraceSources. Il livello di accesso consentito a ogni origine è controllato da un SourceSwitch. Origini a sua volta connessi a uno o più consumer, mantenere la registrazione delle informazioni in modi diversi.

Windows Azure fornisce un consumer standard o listener per rendere persistenti le informazioni di registrazione genera uno Windows Azure tabella archivio o blob di archiviazione. È anche possibile scrivere un consumer personalizzato se si desidera qualcosa di diverso con i dati dell'evento o utilizzare un consumer pronti (sebbene alcune debba essere modificato in ambiente Windows Azure).

Il framework ETW associa un TraceEventType ciascun evento, come illustrato in di Figura 2. Le prime righe di cinque gravità sono i valori comunemente utilizzati e indicano l'importanza relativa dell'output di analisi. Si noti che i tipi Suspend e Resume trasferimento vengono utilizzati da Windows Communication Foundation (WCF).

Figura 2 tipi di eventi di traccia

TraceEventType	Valore	Significato
Critica	0 x 0001	Errore irreversibile o l'applicazione si blocchi
Errore	0 x 0002	Errore risolvibile
Avviso	0 x 0004	Problemi non critici, potrebbe essere un'indicazione dei problemi più gravi portare
Informazioni	0x0008	Messaggio informativo
Verbose	0 x 0010	Traccia di debug (ad esempio informazioni sul flusso di esecuzione dettagliate, parametri e così via)
Avviare	0 x 0100	Avvio di un'operazione logica
Arrestare	0 x 0200	Interruzione di un'operazione logica
Sospensione	0x0400	Sospensione di un'operazione logica
Curriculum	0x0800	Ripresa di un'operazione logica
Trasferimento	0 x 1000	Trasferire una nuova attività

Se stai cercando solo per le cose veramente errate, sarà necessario che cattura critici e probabilmente i valori di errore. Se si desidera che molte informazioni su cosa sta succedendo, cercare in tutti gli elementi sopra verbose.

La strategia di registrazione deve includere l'utilizzo uniforme del tipo di evento e le voci di registrazione abbondanti ulteriormente i valori verso il basso nella gerarchia. Dovrebbe essere possibile praticamente seguire il flusso di esecuzione dell'applicazione se è attivata la registrazione per tutti i valori evidenziati nell'applicazione. Questo può essere estremamente utile nella risoluzione di un errore o un problema nell'ambiente di produzione.

È possibile agganciare listener, origini e opzioni per abilitare i diversi livelli di output a livello di codice, ma in genere ciò avviene attraverso i file di configurazione. È possibile configurare l'output nel file app.config (per Windows Azure lavoro ruoli) o web.config (per i ruoli di Windows Azure Web). Tuttavia, come verrà spiegato in dettaglio più avanti nell'articolo, inserendo in ServiceConfiguration.cscfg consente di regolare registrazione e traccia opzioni durante l'esecuzione del servizio Windows Azure, senza dover ridistribuire gli aggiornamenti al codice in esecuzione o persino interrompere il servizio. Windows Azure espone anche un'interfaccia RESTful per consentire di controllare alcune opzioni di registrazione in modalità remota. Windows PowerShell può essere utilizzato il RESTful interfaccia.

Registrazione, analisi e debug output

Le condizioni di accesso, output di analisi e debug possono talvolta essere utilizzate indifferentemente. In questo articolo, ho intenzione di distinguere i quattro diversi tipi di cosa può in genere essere chiamato diagnosticoutput nel codice. Questi approssimativamente sono ordinati dal più dettagliato a meno dettagliato.

• Output di debug: Si tratta di informazioni viene visualizzata solo nelle build di debug dell'applicazione e viene escluso in fase di compilazione dalla build di rilascio (basato su se è definito il simbolo del preprocessore DEBUG in fase di compilazione definisce Visual Studio per impostazione predefinita solo nelle build di debug). Output di debug in genere include elementi quali Asserts aggiungere per individuare i casi in cui codice è non conformi a condizioni preliminari previste, causando bug o persino dump delle strutture di dati. Algoritmi questi consente di aggiungere debug durante il debug e il test.
• Analisi: Si tratta di istruzioni sono utili per tenere traccia del flusso di controllo e di stato del programma è in esecuzione. Si supponga che esegue un debugger, passo lungo codice e selezionare i valori delle chiavi variabili nella finestra Espressioni di controllo. Le istruzioni di analisi si intendono replicare tale esperienza nei casi in cui non è possibile allegare un debugger. In teoria dovrebbe forniscono sufficienti contesto è possibile vedere quale percorso viene eseguita ogni punto di controllo dell'applicazione e specie di seguirli nel codice di leggere le istruzioni di analisi. L'analisi è attivata quando il simbolo del preprocessore TRACE viene definito in fase di compilazione e può essere in entrambi versione e la build di debug. (Per impostazione predefinita, Visual Studio definisce TRACE di debug e rilascio generazioni, ma è possibile ovviamente modificare questa.)
• Registrazione evento: Si tratta di istruzioni sono utili per acquisire gli eventi principali dell'esecuzione dell'applicazione, ad esempio l'inizio di una transazione o l'aggiunta di un elemento a un database. Registrazione degli eventi è diversa dalla traccia che acquisisce gli stati principali piuttosto dettagliata flusso di controllo.
• Errore di registrazione: Questi sono casi speciali di registrazione degli eventi in cui l'acquisizione di situazioni eccezionali o potenzialmente pericolosi. Sono esempi di qualsiasi eccezione intercettata; casi in cui è Impossibile accedere a una risorsa su un altro computer dovrebbe essere in grado di accedere (e che, naturalmente, l'applicazione gestirà correttamente ma si desidera tenere presente); e casi in cui errori tornare dalle API da cui non si prevede che gli errori.

Registrazione degli errori può anche essere utili al personale operativo in situazioni in cui non sono ancora presenti problemi, ma sono di indicazioni che essi presto sarà, ad esempio, una quota sta raggiungendo il limite massimo o un'operazione riuscita, ma richiede più tempo rispetto al solito. Questi tipi di registrazione degli eventi consentono operazioni personale preventivamente risolvere i problemi prima che si verifichino, evitare tempi di inattività nell'applicazione.

La maggior parte degli sviluppatori buona hanno ottenuta utilizzato per compresi output di debug nelle applicazioni per facilitare la diagnosi dei problemi durante lo sviluppo e molte hanno sviluppato una sorta di soluzione per la registrazione degli errori.

Tuttavia, è necessario che si sta considerando non solo l'output di debug e di errore delle opzioni di registrazione, ma dispone anche di una strategia efficace per la registrazione di eventi realmente per diagnosticare i problemi che si verificano solo con carichi stressful negli ambienti di produzione.

Inoltre, valutare attentamente se genera gran parte ora opinione dell'output di debug non devono essere invece disponibili nella release e debug e analisi. In genere verrà eseguita un'applicazione anomalo in produzione le build di rilascio. Se si dispone di analisi istruzioni presentano ma disattivato (come verrà spiegato come effettuare più avanti), è possibile selettivamente attivarli ottenere un output simile a debug molto ricca dalla build di rilascio, consentono di diagnosticare i problemi.

Analisi e registrazione in Windows Azure

È possibile utilizzare Windows Azure registrazione destra fuori della casella, del parte Azure Windows SDK. Esistono alcuni vantaggi nell'utilizzo di un framework di registrazione come Logger.NET, Enterprise Library, log4net o Ukadc.Diagnostics. Questi aggiungere ulteriore struttura per la messaggi dei registrazione e consente inoltre di fornire alcune configurabilità menzionati in precedenza. Tuttavia, la maggior parte non sono stata modificata in ambiente Windows Azure e alcuni sono molto più di una struttura di registrazione.

Per il codice di esempio per questo articolo ho deciso di utilizzare semplicemente il standard Windows Azure registrazione e traccia API con un livello ridotto in primo piano per fornire la configurazione dinamica. Si verrà probabilmente utile strategia su questo di analisi e creazione di alcune classi di supporto e un framework per la registrazione o controllare altri Framework fornire versioni Windows Azure.

Quando si crea un nuovo servizio in Windows Azure utilizzando Visual Studio, è già abilitato per effettuare la registrazione di base. Il codice di lavoro ruolo e ruolo Web standard generato dai modelli di Windows Azure ha già configurato e attivato il listener di diagnostica.

Per abilitare la registrazione semplice in un servizio Windows Azure, avviare un nuovo progetto in Visual Studio utilizzando il modello di servizio di Windows Azure area (Visual C#). Assegnare un nome al progetto. Per il mio esempio ho utilizzato MSDNSampleLoggingService. Fare clic su OK.

Verrà eseguita la creazione guidata nuovo progetto di servizio di area. Nella procedura guidata, aggiungere un ruolo di lavoro e un ruolo Web al progetto. Rinominare il ruolo di lavoro LoggingWorkerRole e ruolo Web a LoggingWebRole, quindi scegliere OK. In Visual Studio verrà creato il progetto.

A questo punto è possibile esplorare il codice generato. Esaminare il file app.config nel progetto LoggingWorkerRole e verrà visualizzato il seguente codice:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <system.diagnostics>

    <trace autoflush="false" indentsize="4">

      <listeners>

        <add name="AzureDiagnostics" type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Mi-crosoft.WindowsAzure.Diagnostics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

      </listeners>

    </trace>

  </system.diagnostics>

</configuration>

Questo associa la Azure Windows standard listener diagnostica al codice, ovvero qualsiasi registrazione e analisi è eseguire dal ruolo di lavoro verranno indirizzati al listener Windows Azure (DiagnosticMonitorTraceListener) solo se si modifica questa. Troverete una voce simile nel file web.config per il ruolo Web creato per questo servizio.

Se si esamina il file WorkerRole.cs nel progetto di ruolo di lavoro, verrà visualizzata anche questa riga nel metodo OnStart:

DiagnosticMonitor.Start("DiagnosticsConnectionString");

E nel metodo Run, si vedrà una chiamata alla traccia:

// This is a sample worker implementation. Replace with your logic.

Trace.WriteLine("LoggingWorkerRole entry point called", "Information");

Infine, se si esamina il file ServiceConfiguration.cscfg nella directory principale del servizio, questa riga verrà visualizzata per il ruolo del lavoro e il ruolo Web:

<Setting name="DiagnosticsConnectionString" 

         value="UseDevelopmentStorage=true" />

In questo modo il listener Windows Azure account di archiviazione da utilizzare per la registrazione di persistenza e le informazioni di analisi. In questo caso, le informazioni di registrazione vengono memorizzate nello sviluppo di memorizzazione nel computer locale. Passa questo a un account di Windows Azure area di archiviazione, è possibile che i registri Vai all'area di archiviazione. Ecco un esempio di formato di che dal codice di esempio fornito con questo articolo:

<Setting name="DiagnosticsConnectionString" 

  value="DefaultEndpointsProtocol=https;AccountName=Xxxxxx;AccountKey=Yyyyyy" />

I valori NomeAccount e AccountKey devono essere personalizzati per il particolare conto azzurro e la chiave. Per ottenere questa informazione dal portale archivio account per il servizio di windows.azure.com. AccountName è la prima parte dell'URL per l'endpoint di archiviazione tabella e blob (parte prima “. table.core.windows. NET ”). AccountKey è la che chiave primaria di accesso per l'account di archiviazione codificata in base 64.

Nota Poiché è presente un account distinti di archiviazione utilizzato per la diagnostica, è possibile scegliere di archiviare le informazioni di diagnostica separate dai dati dell'applicazione. A tale scopo, impostare un account di archiviazione separato facendo clic su nuovo servizio nella pagina del portale, selezionando archivi account, quindi assegnare un nome (MyAppLogs, ad esempio). È consigliabile impostare un gruppo di affinità è della stessa regione come servizio di archiviazione per i registri.

Ora che è stato necessario breve presentazione dell'analisi del codice nei servizi Windows Azure, è possibile eseguire il progetto semplice ruolo Web creato. Si basa nota che il listener predefinito fornito da Windows Azure anche indirizza l'output alla finestra di output di debug in Visual Studio si vedrà OnStart messaggio visualizzato nella finestra di debug:

Information: LoggingWorkerRole entry point called

Se si desidera esaminare i registri dopo l'esecuzione del servizio? Per impostazione predefinita, Windows Azure non mantenuto archiviazione dei registri. È possibile stabilire che per eseguire questa operazione mediante l'aggiunta di poche righe di codice al metodo OnStart del ruolo:

TimeSpan tsOneMinute = TimeSpan.FromMinutes(1);

DiagnosticMonitorConfiguration dmc =

DiagnosticMonitor.GetDefaultInitialConfiguration();



// Transfer logs to storage every minute

dmc.Logs.ScheduledTransferPeriod = tsOneMinute;

// Transfer verbose, critical, etc. logs

dmc.Logs.ScheduledTransferLogLevelFilter = LogLevel.Verbose;    

// Start up the diagnostic manager with the given configuration

DiagnosticMonitor.Start("DiagnosticsConnectionString", dmc);

Aggiunta di questo codice WorkerRole.cs e rieseguire causerà Azure Windows trasferire i registri sviluppo archiviazione ogni minuto. È inoltre possibile scegliere di effettuare un trasferimento su richiesta dei registri (vedere il codice in admin.aspx.cs nella mia applicazione di esempio di questa procedura) o utilizzare i comandi di Windows PowerShell descritti più avanti in questo articolo. Tenere presente che una volta registri trasferimenti per l'archiviazione, addebitato per lo spazio di archiviazione e spetta a eliminare le informazioni quando non è più necessario.

Una volta è stato utilizzato il log in Windows Azure archiviazione, è necessario uno strumento per esaminare le tabelle di archiviazione per visualizzare i registri. Ho utilizzato area archiviazione Studio del Cerebrata (cerebrata.com ). Cerebrata poiché sono disponibili uno strumento denominato Azure Diagnostics Manager e sono disponibili anche strumenti gratuiti su CodePlex (codeplex.com ) per l'analisi diagnostica e area di archiviazione. I registri vengono inseriti in una tabella denominata WADLogsTable, è possibile visualizzare in di Figura 3.

Figura 3 registri persistente nell'archiviazione Development

 

Quando si esaminano i registri di archiviazione si noterà un paio di cose. Innanzitutto, Windows Azure associa automaticamente alcune informazioni a ogni evento registrato: un timestamp, conteggio tick (che fornisce ulteriori intervalli con granularità di 100 nanosecondi) e informazioni sull'istanza della distribuzione, ruolo e ruolo. Consente di restringere i registri a istanze specifiche se desiderato.

In secondo luogo, è disponibile un livello e un EventId associato a ciascun evento. Livello corrisponde ai valori di di Figura 2, gli eventi di traccia registrati come informazioni avrà un valore di livello 4, mentre quelli registrati come errore avrà un livello 2. Eventi generici inviati tramite Trace.WriteLine (come il codice boilerplate) avranno livello 5 (verbose).

L'EventId è un valore specificato. Base chiamata Trace.WriteLine mostrata in precedenza non è possibile specificarlo, è necessario utilizzare altri metodi di analisi per passare l'EventId.

Attivazione selettiva di traccia e registrazione

Un'applicazione tipica è costituito da più componenti logici. Ad esempio, si dispone di un componente database riguarda il modello di dati nell'archivio di Windows Azure. Il ruolo Web a sua volta può essere suddiviso in un componente di amministrazione e un componente utente (e che può anche essere suddivise ulteriormente in componenti logici in base alle esigenze dell'applicazione).

È possibile associare la registrazione e le opzioni di analisi, ovvero il tipo di registrazione è attivato e a quale livello di dettaglio, per questi componenti. Consente di attivare l'analisi nei componenti per i quali è necessario, evitando molta confusione.

L'approccio chiave qui è di non chiamare direttamente Trace, ma utilizzare TraceSource istanze multiple, in genere uno per lo spazio dei nomi. Un TraceSource presenta un SourceSwitch associato che controlla se è attivato l'origine, nonché il livello di output desiderato. I valori SourceSwitch importante, non vengono impostati in fase di compilazione, ma in fase di esecuzione. Di conseguenza, è possibile attivare o disattivare l'output di diagnostica da varie parti dell'applicazione senza dover ricompilare o ridistribuire anche una versione diversa.

WorkerDiagnostics.cs e WebDiagnostics.cs contengono la configurazione delle origini di analisi e parametri nel codice di esempio. Di seguito è riportato un estratto:

// Trace sources

public TraceSource ConfigTrace;

public TraceSource WorkerTrace;

// Add additional sources here



// Corresponding trace switches to control 

// level of output for each source

public SourceSwitch ConfigTraceSwitch { get; set; }

public SourceSwitch WorkerTraceSwitch { get; set; }

// Add additional switches 1:1 with trace sources here

Quindi, nel file di configurazione per il ruolo collegare tali fino ai listener, come illustrato nella Figura 4 . Questo primo imposta il listener di diagnostica Windows Azure standard come listener condivisi in modo che sia possibile farvi riferimento in elementi <sources>. Viene quindi configurato due origini: un'origine WorkerTrace e un'origine ConfigTrace. Imposta inoltre le corrispondenti opzioni consentono di regolare il livello di output. ConfigTrace fornisce l'output più dettagliato mentre WorkerTrace errori solo.

Figura 4 configurazione origini di analisi e di listener

<configuration>

  <system.diagnostics>

    <sharedListeners>

      <add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"

        name="AzureDiagnostics">

        <filter type="" />

      </add>

    </sharedListeners>

    <sources>

      <source name="ConfigTrace">

        <listeners>

          <add name="AzureDiagnostics" />

        </listeners>

      </source>

      <source name="WorkerTrace">

        <listeners>

          <add name="AzureDiagnostics" />

        </listeners>

      </source>

    </sources>

    <switches>

      <add name="ConfigTrace" value="Verbose"/>

      <add name="WorkerTrace" value="Error"/>

    </switches>

    <trace>

      <listeners>

        <add name="AzureDiagnostics" />

      </listeners>

    </trace>

  </system.diagnostics>

</configuration>

Non è necessario denominare i parametri come le origini ma semplifica vita. Se non sono uguali, è necessario aggiungere un attributo switchName all'elemento di origine per indicare il nome dell'opzione che controlla l'output di questa origine. Ciò consente di condividere un unico switch più origini di analisi. Si noti che i nomi di origine e switch di traccia sono maiuscole e minuscole e devono corrispondere esattamente al caso che passare al costruttore nel codice.

È possibile evitare l'opzione completamente se si desidera semplicemente aggiungendo un attributo switchValue all'elemento di origine che specifica il valore dell'opzione desiderata per l'origine. I valori di opzione che utilizzare effettivamente vengono analizzati dal file di configurazione come uno SourceLevels definiti in Figura 5 , che illustra inoltre come TraceEventType passare alle chiamate TraceSource interagisce con il SourceLevel impostata per l'origine per determinare ciò che attraversano.

Figura 5 analisi TraceEventType e livelli di origine

Si sarà notato che il SourceLevel è semplicemente una maschera di bit è ANDed in fase di esecuzione con TraceEventType per determinare se l'evento. Per ottenere le combinazioni come attività di analisi e di avviso, specificare il valore numerico per il campo di bit come il valore dell'opzione anziché i valori simbolici.

Oltre ai parametri, un listener può avere un TraceFilter, aggiunta di logica di runtime più sofisticata per se un determinato messaggio è consentito tramite. Scrittura personalizzato TraceFilter esula dall'ambito di questo articolo, ma un utile esempio sono disponibili nella documentazione del progetto Ukadc.Diagnostics su CodePlex (ukadcdiagnostics.codeplex.com/wikipage?title=LoggingPrimer ).

Modifica What Is Logged in fase di esecuzione

Si tratta della modalità predefinita con i servizi di distribuzione Windows Azure, che funziona correttamente l'analisi di ASP.NET e funzionerà correttamente. Il problema è che si desidera modificare i valori di parametro in fase di esecuzione e Windows Azure non consente di sostituire il file web.config o app.config senza ridistribuire il servizio. La soluzione ASP.NET generica per questo è utilizzare WebConfiguationManager per modificare i valori di configurazione, ma Windows Azure attualmente non consente di effettuare sia per i servizi distribuiti cloud.

La soluzione è per riflettere i valori per queste opzioni in ServiceConfiguration.cscfg. Windows Azure consente di modificare il file (o caricare una nuova) tramite il portale di sviluppo mentre è in esecuzione il servizio. È necessario scrivere codice aggiuntivo per rendere questo lavoro, anche se.

Il codice di default System.Diagnostics conoscenza impostazioni solo nel file app.config o web.config ma dei ruoli verranno visualizzato Runtime notifica delle modifiche in ServiceConfiguration.cscfg tramite gli eventi RoleEnvironmentChanging e RoleEnvironmentChanged. È possibile decidere se riciclare (riavvio) il ruolo o aggiornare semplicemente un valore di configurazione. Quest'ultimo è desiderato per l'analisi dei parametri. Riavviare il ruolo può nascondere problemi intermittenti. Il codice di esempio in questo articolo viene illustrato come eseguire questa operazione aggiungendo un paio di valori ServiceConfiguration.cscfg (si noti che è necessario modificare anche ServiceDefinition.csdef che fornisce lo schema) e aggiungendo codice per i ruoli.

Test sull'infrastruttura di sviluppo

Cosa test sull'infrastruttura di sviluppo, in cui non si dispone del portale Azure di Windows per modificare la configurazione come dei servizi distribuiti cloud? Determinare innanzitutto la distribuzione che Azure Windows ID assegnato al servizio di tessuto di sviluppo in esecuzione. È possibile notarlo mostrando il tessuto di sviluppo dell'interfaccia utente dalla barra delle applicazioni mentre il servizio è in esecuzione. Si tratta di un numero come 177.

1. Passare alla directory in cui sono stati inseriti i file binari del servizio dalla generazione, in genere bin\Debug o \bin\release nel codice del servizio. Troverete la copia di ServiceConfiguration.cscfg creato durante la generazione dell'applicazione.
2. Quindi, utilizzando un editor di testo, modificare questo file per utilizzare l'opzione di analisi desiderate. Ad esempio, nel codice di esempio, modificare WebTrace dall'esterno verbose.
3. Successivo in un prompt dei comandi di Windows Azure SDK (Start | tutti i programmi | Windows Azure SDK v1.1 | prompt dei comandi SDK di Windows Azure), eseguire questo comando:

csrun /update:NNN;ServiceConfiguration.cscfg

NNN rappresenta l'ID di distribuzione Windows Azure trovato in precedenza. Questa verrà eseguita nell'infrastruttura di sviluppo quali facendo clic sul pulsante Configura il portale di sviluppo Windows Azure viene distribuito cloud servizi, aggiornare le impostazioni di configurazione e attivare gli eventi.

Altre informazioni diagnostiche

Mentre in questo articolo è incentrato su Registra dati tabulari che i registri applicazione using System.Diagnostics, Windows Azure possono inoltre acquisire IIS e Impossibile Request Tracing (precedentemente noto come errore Request Buffering o FREB) Registra, tra gli altri. Alcuni di questi vengono inseriti in archiviazione blob Azure di Windows, in Windows Azure tabella di archiviazione. Figura 6 Elenca i registri disponibili e in cui è memorizzati. Si noti che per quelli non attivata per impostazione predefinita, è in genere necessario apportare una modifica nel file web.config o app.config per Windows Azure raccogliere questi registri. Analizza Let’s ad esempio non raccolto per impostazione predefinita mostra il funzionamento.

Figura 6 di Opzioni di registrazione standard azzurro

Tipo di registro	Formato Windows Storage azzurro	Raccolti per impostazione predefinita?	Note
Registri di Windows Azure generati dal codice	Tabella	4	Listener di analisi deve essere aggiunto al file web.config o app.config, come illustrato nell'esempio di codice. Memorizzati in WADLogsTable.
Registri di IIS 7.0	BLOB	4	Solo ruoli di Web. Memorizzati in un contenitore di Blob sotto il percorso wad-iis-logfiles\ < ID distribuzione > \ < nome ruolo web > \ < istanza del ruolo > \W3SVC1.
Registri di infrastruttura diagnostica Windows	Tabella	4	Informazioni sul servizio di diagnostica stesso. Memorizzati in WADDiagnosticInfrastructureLogsTable.
I registri delle richieste di non riuscita	BLOB		Solo ruoli di Web. Attivare impostando le opzioni di analisi system.WebServer le impostazioni nel file web.config. Memorizzati in un contenitore di blob sotto il percorso wad-iis-failedreqlogfiles\ < ID distribuzione > \ < nome ruolo web > \ < istanza del ruolo > \W3SVC1.
Registri eventi di Windows	Tabella		Attivare modificando DiagnosticMonitor Configuration.WindowsEventLog durante l'impostazione di configurazione iniziale. Memorizzati in WADWindowsEventLogsTable. Blog di Steve Marx (blog.smarx.com/posts/capturing-filtered-windows-events-with-windows-azure-diagnostics) viene illustrato come utilizzare questa opzione.
Contatori delle prestazioni	Tabella		Attivare modificando la configurazione DiagnosticMonitor. PerformanceCounters. Memorizzati in WADPerformanceCountersTable. Il ruolo del lavoro del codice di esempio imposta un contatore delle prestazioni.
Dump di arresto anomalo	BLOB		Attivare chiamando CrashDumps.EnableCollection. Memorizzati in un contenitore di blob sotto il percorso wad--dump di arresto anomalo. Poiché ASP.NET gestisce la maggior parte delle eccezioni, è in genere utile solo per un ruolo di lavoro.
Log degli errori personalizzati	BLOB		Esulano dall'ambito di questo articolo, ma vedere blog di Neil Mackenzie (nmackenzie.spaces.live.com/blog/cns!B863FF075995D18A!537.entry) per un esempio di come utilizzare questa utile.

Ad esempio, osservare let’s come attivare la registrazione FREB da IIS al ruolo del Web. Per vedere in azione, è possibile scaricare il codice di esempio per MSDNSampleLoggingService fornito con questo articolo. Aprire il file web.config per il LoggingWebRole e trovare la sezione denominata <system.webServer>. Si noti che le righe visualizzate in di Figura 7 sono state aggiunte al file Web.config Windows Azure predefinito. Il risultato della registrazione degli errori per le richieste che richiedono più tempo rispetto a 15 secondi o con i codici di stato tra 400 e 599 (elemento failureDefinitions).

Figura 7 Impossibile richiesta di LoggingWebRole

<tracing>

  <traceFailedRequests>

    <add path="*">

      <traceAreas>

        <add provider="ASP" verbosity="Verbose" />

        <add provider="ASPNET" 

             areas="Infrastructure,Module,Page,AppServices"

             verbosity="Verbose" />

        <add provider="ISAPI Extension" verbosity="Verbose" />

        <add provider="WWW Server"

             areas="Authentication,Security,Filter,StaticFile,CGI,Compression,Cache,RequestNotifications,Module" 

             verbosity="Verbose" />

      </traceAreas>

      <failureDefinitions timeTaken="00:00:15" statusCodes="400-599" />

    </add>

  </traceFailedRequests>

</tracing>

Se si apre about.aspx.cs nel progetto LoggingWebRole, si noterà che nel metodo PageLoad è stato aggiunto un intervallo di tempo arbitrario di 18 secondi con questa riga di codice:

System.Threading.Thread.Sleep(18000);

Questo impone il caricamento della pagina per essere considerata una richiesta non riuscita con la definizione specificata in precedenza.

Per visualizzare il registro FREB, ricostruire e distribuire l'applicazione nell'infrastruttura di sviluppo e trovare il controller di tessuto di sviluppo nell'area di notifica della barra delle applicazioni (potrebbe essere necessario fare clic sul pulsante Mostra icone nascoste della barra delle applicazioni perché spesso è nascosto come inattiva). Fare doppio clic su esso e selezionare Mostra interfaccia infrastruttura di sviluppo. Durante l'esecuzione dell'applicazione visualizzerà informazioni relative all'applicazione.

Espandere il ruolo Web e fare doppio clic sull'istanza del ruolo (0). Selezionare Apri archivio locale per aprire la cartella sul computer locale in cui i registri vengono salvati (vedere di Figura 8). All'interno di tale cartella, i registri si trovano nella cartella \directory\DiagnosticStore. Questo avviene perché il ruolo Web nel codice di esempio è configurato per archiviare le informazioni di diagnostica nello sviluppo di memorizzazione. Se invece si imposta il DiagnosticsConnectionString a un account di archiviazione cloud, registri persistenti sarà dell'archiviazione blob associati a tale account di archiviazione. È possibile utilizzare area archiviazione Studio per esaminare i contenitori di archiviazione blob per visualizzare i registri.

Figura 8 di apertura registri salvati archiviazione infrastruttura di sviluppo locale

Gestione di diagnostica per il servizio in esecuzione

Mentre profondamente possibile instrumentare il codice di registrazione, è in genere Don ’t desidera che tutte le informazioni di registrazione mantenute in memoria durante l'esecuzione del servizio di produzione. È possibile solo errore e informazioni critiche per passare i registri persistenti, mentre ulteriori informazioni (registrate come Verbose o Information) sono state eliminate.

Ma cosa succede se si verifica un problema? Non si desidera ridistribuire una nuova versione del servizio o del problema Model-View potrebbe passare immediatamente, è noto come efficace il riavvio può essere a rendere elusivi problemi scompaiono.

È invece più efficacia aumentare la quantità di informazioni per le tabelle di registrazione o blob archiviazione consentendo il codice anomalo di continuare l'esecuzione. Questo è più probabile scoprire la causa del problema nell'applicazione mentre opera attualmente.

Precedente è stato descritto come modificare i dettagli di quali registrazione viene passata alla diagnostica Windows Azure per un particolare TraceSource. È una specie di upstream modifica delle informazioni che ottiene l'accesso. In questa sezione verrà illustrato le impostazioni di diagnostica Windows Azure generali che determinano come informazioni che passa attraverso un TraceSource ottiene in archiviazione persistente.

I cmdlet di Windows PowerShell consente di gestire molti aspetti dei servizi Azure di Windows in esecuzione, inclusi la diagnostica. Esecuzione dal computer locale e si connettono da Internet ai server Windows Azure cloud che esegue il servizio, fornendo informazioni e la modifica dei parametri. Windows PowerShell viene installato con Windows 7 e possono essere scaricati per Windows Vista da microsoft.com/powershell . Scaricare i cmdlet di Windows Azure Service Management code.msdn.microsoft.com/azurecmdlets e seguire le istruzioni per eseguirne l'installazione. Di Figura 9 vengono visualizzati i comandi relativi alla diagnostica Windows Azure.

Figura 9 di cmdlet di diagnostica di gestione azzurro di Windows

Nome	Descrizione
Get ActiveTransfers	Restituisce l'insieme di trasferimenti di diagnostici attivi con informazioni sul trasferimento associato.
Get CommonConfigurationLogs	Ottiene i valori di configurazione comune per tutti i buffer di registrazione. Ciò include l'intervallo di tempo le modifiche di configurazione sono polling per e la dimensione del buffer allocato per i registri in memoria.
Get DiagnosticAwareRoleInstances	Restituisce un elenco di ID di istanze del ruolo attivo che dispone di un monitor di diagnostico in esecuzione.
Get DiagnosticAwareRoles	Elenca l'insieme di ruoli che hanno avviato almeno un monitor di diagnostico.
Get DiagnosticConfiguration	Ottiene la configurazione di buffer per il nome di buffer specificato (registri, directory, PerformanceCounters, WindowsEventLogs o DiagnosticInfrastructureLogs).
Set CommonConfigurationLogs	Imposta i valori di configurazione comune per tutti i buffer di registrazione.
Set FileBasedLog	Imposta la configurazione di buffer per registri basati su file.
Set InfrastructureLog	Imposta la configurazione di buffer per i registri generati da infrastruttura diagnostica Windows Azure sottostante. Registri di diagnostica dell'infrastruttura sono utili per il sistema di diagnostica per la risoluzione dei problemi.
Set PerformanceCounter	Imposta la configurazione di buffer per i dati del contatore delle prestazioni raccolti dal provider di servizi.
Set WindowsAzureLog	Imposta la configurazione di buffer di base Windows Azure registri generati dal provider di servizi.
Set WindowsEventLog	Imposta la configurazione di buffer per i registri eventi di Windows generato dal servizio.
Inizio OnDemandTransfer	Avvio di un trasferimento su richiesta del buffer di dati specificato. I dati verranno spostati Windows Azure archiviazione (storage tabella o blob).
Stop ActiveTransfer	Trasferimento su richiesta attiva si interrompe, assegnato un ID di trasferimento.

Ad esempio, per trovare il trasferimento corrente parametri per un'istanza del ruolo particolare, passare l'ID di installazione (dal portale sviluppatore Windows Azure in cui distribuire il servizio) e il nome di account archiviazione e la chiave utilizzata per DiagnosticsConnectionString nel file app.config o web.config per il ruolo del servizio (vedere di Figura 10). Si noti che Windows PowerShell richiede un paio di parametri obbligatori mancanti, ovvero l'istanza del ruolo e il nome del buffer desiderata. Registri è i registri Windows Azure standard. Il risultato indica che il livello di filtro è dettagliato e un trasferimento è pianificato ogni minuto.

Figura 10 di configurazione della diagnostica di un servizio in esecuzione con Windows PowerShell

Per modificare la configurazione per questo ruolo, utilizzare il cmdlet DiagnosticConfiguration Set, come illustrato in di Figura 11. Si noti che dopo aver modificato l'intervallo di tempo di trasferimento da un minuto a due minuti e il filtro da Verbose Error, vale a dire che verranno inviati solo gli eventi registrati come errore e critico per l'archiviazione permanente.

Figura 11 Modifica configurazione della diagnostica di Windows PowerShell

La cosa più utile che è possibile eseguire in modalità remota da Windows PowerShell è probabilmente per imporre immediatamente un trasferimento di informazioni di registro. Figura 12 viene illustrato come eseguire questa operazione.

Figura 12 utilizzando Windows PowerShell per avviare un trasferimento di registri IIS

Innanzitutto, query qualsiasi trasferimento su richiesta esistente dei registri. È presente una limitazione nell'implementazione di diagnostica Windows Azure corrente che solo un trasferimento su richiesta di un determinato tipo può essere eseguita contemporaneamente. Visto che nessuno è in corso, è possibile richiedere uno, passando l'ID della distribuzione del servizio, il ruolo e istanza, il tipo di registro da trasferire e l'intervallo di dati da trasferire. (Per il tipo di registro Directory significa registri basati su file, inclusi i registri di IIS. Registri sarebbe Windows Azure basato su tabella log inviati tramite TraceSource.)

È possibile passare anche un nome di coda notifica, ovvero dove diagnostica Windows Azure invia una notifica di completamento del trasferimento. Attraverso la sperimentazione, ho scoperto che se una coda di notifica non passo, il trasferimento sembrava non verificarsi. È possibile ottenere un GUID che identifica la richiesta di trasferimento. È possibile ricercare lo stato della richiesta e vedere che viene pubblicato, ovvero in corso.

La versione corrente di Windows Azure Service Management cmdlet non sembra da visualizzare quando la richiesta è stata completata, ma se viene richiesta l'archiviazione blob per l'archiviazione di diagnostica che si vedrà i registri pop up nella gerarchia di contenitori poco (o nell'archiviazione tabella Windows Azure) se la richiesta di trasferimento delle informazioni archiviate nella tabella di archiviazione.

Conclusioni

Utilizzando una combinazione di regolazione dei parametri di configurazione per TraceSources definire nel codice e utilizzare i cmdlet di Windows Azure Service Management per spostare le informazioni in un archivio permanente, deve essere in grado di controllare completamente l'output di diagnostica da servizi Windows Azure.

La cosa più importante da eseguire per risolvere i problemi del codice di produzione consiste nello sviluppare una strategia efficace per la diagnostica di output nelle prime fasi di sviluppo, quindi seguire tale strategia in tutta la codifica. L'utilizzo di TraceSources e gli strumenti disponibili Windows Azure per configurare il livello di dettaglio dell'output di diagnostica che passa dall'applicazione di archiviazione consente di toccare in cui ottenere solo la quantità di informazioni che necessarie quando si verifica un problema.

Non c'è niente inferiori a quelle sensazione come una casella nera opaca a è il codice funziona non funziona correttamente su un server. Codice diagnostica a tinta unita e gli strumenti descritti di seguito saranno possibile aprire le copertine di tale casella e peer all'interno.

Mike Kelly  è un consulente incentrata sullo sviluppo di software e consentono di integrare le acquisizioni di aziende di dimensioni maggiori. Precedentemente lavorato per 15 anni presso Microsoft in un'ampia gamma di ruoli di sviluppo del prodotto e come direttore del team Engineering Excellence Practices emergenti. Contattarlo al himself@mikekellyconsulting.com.

Grazie ai seguenti esperti tecnici per la revisione di questo articolo:  Sumit Mehrotra, Michael Levin e Matthew Kerner da Microsoft, nonché Neil Mackenzie e Steven Nagy