Esporta (0) Stampa
Espandi tutto

Procedure consigliate di risoluzione dei problemi per lo sviluppo di applicazioni Azure

Aggiornamento: novembre 2014

Autore: William Bellamy, Microsoft Principal Escalation Engineer

Collaboratori:

  • Bryan Lamos, Microsoft Senior Program Manager, qualità prodotti

  • Kevin Williamson, Microsoft Senior Escalation Engineer, supporto per sviluppatori Azure

  • Pranay Doshi, Microsoft Senior Program Manager, servizi di produzione Azure

  • Tom Christian, Microsoft Senior Escalation Engineer, supporto per sviluppatori Azure

Data pubblicazione: gennaio 2012

La priorità di base di Microsoft è quella di consentire ai clienti di Azure di mantenere operative e in esecuzione le proprie applicazioni. I contratti di servizio di Azure definiscono una disponibilità del 99,95% di connettività esterna quando si distribuiscono due o più istanze di ruolo. La connettività esterna garantisce tuttavia la possibilità di raggiungere l'applicazione dall'esterno dei data center Microsoft, situazione diversa rispetto alla disponibilità di un sito operativo. Alla maggior parte dei servizi Azure sono associate più dipendenze, ad esempio SQL Azure, memorizzazione nella cache, rete per la distribuzione di contenuti, risorse interne (tramite Azure Connect) e così via. Un comportamento non corretto di una di tali dipendenze può provocare un funzionamento non previsto del servizio Azure.

Nel presente documento vengono descritte le diverse modalità di risoluzione dei problemi e gli approcci consigliati per la progettazione e lo sviluppo di applicazioni più compatibili con la piattaforma Azure. Quando (e non se) si verifica un problema, il fattore tempo è fondamentale. Una pianificazione corretta consente di trovare e risolvere i problemi senza che sia necessario contattare Microsoft per richiedere supporto tecnico. L'approccio consigliato nel presente documento accelera inoltre la risoluzione dei problemi che richiedono l'intervento di Microsoft.

Il presente documento è destinato a un pubblico di tecnici software, ovvero progettisti e architetti software, professionisti IT, integratori di sistemi, sviluppatori e tester che progettano, compilano e distribuiscono soluzioni Azure.

Si presuppone una conoscenza di base del processo di sviluppo delle applicazioni Azure, ad esempio la terminologia e i diversi componenti dell'ambiente di sviluppo e di runtime di Azure.

Si presuppone inoltre che vengano seguite le linee guida di base per Azure, ad esempio l'uso della versione più recente di Azure SDK e l'esecuzione di test sulle modifiche del codice prima della distribuzione in produzione.

Il documento è organizzato in due sezioni:

  • Panoramica delle risorse di diagnostica di Azure:

    • risorse di Azure

    • Risorse di terze parti

  • Procedure consigliate per progettazione, sviluppo e distribuzione compatibili

    • Attività preliminari allo sviluppo dell'applicazione

    • Progettazione e monitoraggio in base alla modalità di errore immediato

    • Operazioni da eseguire quando si verifica un problema

Nessun sviluppatore si aspetta che la propria applicazione non funzioni una volta distribuita in produzione. Anche se l'impegno messo in atto per testare il codice durante lo sviluppo in modo che sia abbastanza affidabile per essere eseguito senza errori mentre si passa al progetto successivo è notevole, sfortunatamente talvolta il codice non funziona in modo corretto. In un ambiente distribuito gli errori di entità minore possono diventare estremamente gravi a causa delle complessità inerenti alla separazione dei componenti dell'applicazione. Per questo motivo è necessario predisporre una strategia di registrazione e di traccia nell'applicazione fin dall'inizio. Idealmente, tale strategia include l'esecuzione del provisioning per effettuare modifiche dinamiche senza la necessità di ricompilare o ridistribuire il tipo o il volume della registrazione a livello di un componente. La disponibilità di una grande quantità di log non garantisce una risoluzione rapida né una quantità maggiore è necessariamente migliore perché un numero elevato di dati richiede molto tempo per la decrittazione e potrebbe potenzialmente rallentare le prestazioni dell'applicazione. La registrazione modificabile controlla sia le dimensioni che il costo di archiviazione dei dati di log.

Le applicazioni distribuite come quelle eseguite nella piattaforma Azure sono costituite da più componenti che interagiscono tra loro quando l'utente usa l'applicazione. Tramite una registrazione coerente e frequente del flusso del codice con una speciale attenzione rivolta alle chiamate ai servizi esterni, chiunque è virtualmente in grado di seguire il flusso di esecuzione dell'applicazione. Questo aspetto può essere di importanza fondamentale tra un anno o due quando si verifica un problema in produzione. Idealmente il livello di registrazione deve essere modificabile nel file ServiceConfiguration.cscfg in modo che sia possibile cambiarlo senza eseguire una ridistribuzione.

Durante lo sviluppo è conveniente usare una compilazione di debug per ottenere la quantità massima di informazioni sugli errori. Gli sviluppatori in genere aggiungono istruzioni di debug e talvolta una qualche forma di registrazione di errori. È necessario tuttavia tenere presente che le istruzioni di debug vengono rimosse nella compilazione di produzione e questo può rappresentare un aspetto negativo quando si verifica un problema. La maggior parte dei clienti non desidera infatti eseguire la ridistribuzione con una compilazione di debug per risolvere un problema in produzione. Mike Kelly pone l'accento su quattro tipi di output di dati diagnostici che gli sviluppatori devono configurare:

  • Output di debug - Solo in modalità debug la compilazione include istruzioni Assert

  • Traccia - Output che registra il flusso di controllo durante l'esecuzione

  • Registrazione eventi - Eventi principali

  • Registrazione errori - Situazione eccezionale o pericolosa

Per sfruttare i livelli di traccia diversi, molti dei messaggi di debug devono essere realizzati in istruzioni di traccia. Diagnostica Azure consente inoltre di configurare la diagnostica e di disabilitare i trasferimenti in modo che sia possibile controllare il momento in cui le informazioni vengono scritte nell'archiviazione permanente.

Nelle sezioni seguenti vengono descritte alcune risorse per la risoluzione dei problemi disponibili agli sviluppatori che compilano applicazioni in Azure.

Prima di esaminare Azure, esaminiamo il processo di risoluzione dei problemi corrente per applicazioni Windows Server. Quando si verifica un problema in fase di produzione, gli sviluppatori in genere esaminano i log. I log IIS e i registri eventi sono attivati per impostazione predefinita e rimangono invariati anche dopo le operazioni di riavvio (purché non si verifichi un errore del disco).

Lo stesso processo si applica a un'applicazione Azure se Desktop remoto è abilitato dato che gli sviluppatori possono connettersi a ogni istanza per raccogliere dati di diagnostica. Per effettuare la raccolta, è possibile copiare i log nell'archiviazione o configurare RDP in modo che sia possibile copiare i log nel computer locale. Questo processo può richiedere molto tempo e non viene eseguito in modo corretto se viene ricreata l'immagine dell'istanza, operazione che determina l'avvio di un ruolo di lavoro o di una nuova versione del Web, priva naturalmente di tutti i log precedenti. Un'immagine può essere ricreata nel caso di un aggiornamento del sistema operativo dell'host o della macchina virtuale guest e tale operazione è normale nell'architettura di Azure.

Azure SDK 1.0 include funzionalità per la raccolta di dati diagnostici e la relativa archiviazione in Azure, denominate collettivamente Diagnostica Azure. Questo software, basato sul framework Event Tracing for Windows (ETW), soddisfa due requisiti di progettazione introdotti dall'architettura a scalabilità orizzontale Azure:

  1. Salvare i dati di diagnostica che potrebbero essere persi durante una ricreazione dell'immagine dell'istanza.

  2. Fornire un repository centrale per la diagnostica da più istanze.

Lo spazio dei nomi Microsoft.WindowsAzure.Diagnostic estende lo spazio dei nomi System.Diagnostics in modo che sia possibile usare il framework ETW in un'applicazione Azure.

Microsoft Azure - Diagramma del flusso diagnostico

Dopo aver incluso Diagnostica di Azure nel ruolo (file ServiceConfiguration.cscfg e ServiceDefinition.csdef), tale funzionalità raccoglie i dati di diagnostica da tutte le istanze del ruolo specifico. I dati possono quindi essere usati per il debug, la risoluzione dei problemi, la valutazione delle prestazioni, il monitoraggio dell'uso delle risorse, l'analisi del traffico, la pianificazione della capacità e il controllo. I trasferimenti nell'account di archiviazione di Azure per la persistenza possono essere pianificati o su richiesta.

Diagnostica di Azure modifica il paradigma server in quattro modi importanti:

  1. La diagnostica deve essere abilitata al momento della creazione dell'applicazione.

  2. Per visualizzare i risultati di diagnostica, sono necessari passaggi e strumenti specifici.

  3. Gli arresti anomali determineranno la perdita dei dati diagnostici se questi non sono scritti in un archivio durevole (Archiviazione di Azure anziché nelle singole istanze).

  4. L'archiviazione diagnostica comporta un costo mensile se avviene in Archiviazione di Azure.

L'aspetto relativo al costo è di particolare importanza perché uno dei vantaggi chiave della piattaforma Azure è la riduzione dei costi. L'unico modo per eliminare il costo legato all'uso di WAD è attualmente quello di lasciare i dati nella macchina virtuale. Questa soluzione può funzionare in una distribuzione di dimensioni non elevate, ma è impraticabile in presenza di numerose istanze. Di seguito vengono indicati alcuni modi possibile per ridurre l'impatto finanziario.

  1. Verificare che l'account di archiviazione si trovi nello stesso data center dell'applicazione. In caso contrario, scegliere in modo opportuno l'intervallo dei trasferimenti pianificati. Tempi di trasferimento più brevi aumentano la rilevanza dei dati, ma tale compromesso potrebbe non essere sufficiente per giustificare l'ulteriore larghezza di banda e il sovraccarico di elaborazione.

  2. Copiare e cancellare periodicamente i dati di diagnostica da Archiviazione di Azure. I dati di diagnostica transiteranno nell'archiviazione di Azure, senza risiedervi inutilmente. Per effettuare questa operazione, sono disponibili strumenti diversi, Monitoring Pack di System Center per Azure, Azure Diagnostics Manager di Cerebrata e i cmdlet di PowerShell per Azure.

  3. Scegliere solo dati di diagnostica necessari per risolvere i problemi e monitorare l'applicazione. Oltre a determinare costi significativamente più elevati, l'acquisizione di un numero troppo elevato di dati può rendere più difficile la risoluzione dei problemi.

  4. Controllare la raccolta e le dimensioni dei dati di diagnostica implementando un'opzione a richiesta nell'applicazione.

  5. Usare il livello di registrazione (dettagliato, informativo, di avviso o di errore) in modo che tutte le informazioni siano disponibili, quindi usare la configurazione di WAD post-distribuzione per raccogliere in dati in modo selettivo.

L'archiviazione di Azure è la base di ogni applicazione compatibile e idealmente questa funzionalità dovrebbe essere configurata e attiva per ogni applicazione.

Analisi archiviazione di Azure consente di registrare e generare dati di metrica per un account di archiviazione. È possibile usare tali dati per tenere traccia delle richieste di archiviazione, analizzare le tendenze di uso ed eseguire la diagnostica dei problemi relativi all'account di archiviazione.

Per scrivere codice SQL Azure compatibile, è fondamentale esaminare i codici restituiti e verificare di disporre di un codice tentativi affidabile per gestire gli errori.

Questo Monitoring Pack permette di usare Microsoft System Center Operations Manager per monitorare la disponibilità e le prestazioni delle applicazioni Azure:

  • Individuazione di applicazioni Azure.

  • Restituzione dello stato di ogni istanza del ruolo.

  • Raccolta e monitoraggio di informazioni sulle prestazioni.

  • Raccolta e monitoraggio di eventi di Windows.

  • Raccolta e monitoraggio dei messaggi di traccia di .NET da ogni istanza del ruolo.

  • Gestione dei dati su prestazioni ed eventi e dei dati di traccia di .NET Framework dall'account di archiviazione di Azure.

  • Modifica del numero delle istanze del ruolo.

Microsoft System Center Operations Manager 2007 rappresenta la soluzione ottimale per monitorare l'integrità di un'applicazione Azure.

Attualmente Azure non fornisce una soluzione completa che consenta ai clienti di monitorare e gestire il proprio servizio ospitato. Per informazioni sulle funzionalità di rete, speedtest.net fornisce uno strumento che misura i tempi, la larghezza di banda e la qualità complessiva della connessione. La latenza tra i diversi data center Microsoft può essere visualizzata grazie alle statistiche di Azure di Matthew Rosoff. Quando si usa Azure, può essere utile sfruttare un certo numero di strumenti disponibili. L'elenco seguente non vuole raccomandare né consigliare alcuno strumento d terze parti specifico.

Cmdlet di PowerShell per Azure

Il modo migliore per gestire i problemi di diagnostica in modalità remota è quello di usare i cmdlet di PowerShell per Azure. I cmdlet si basano sulle API di gestione e di diagnostica di Azure e il codice sorgente completo è disponibile tramite il progetto CodePlex in modo che le API sottostanti siano più facilmente comprensibili. La versione 2.0 consente di configurare, scaricare ed esaminare tutti gli aspetti di Diagnostica Azure. Nel blog di Michael Washam vengono forniti alcuni script di esempio.

Monitoraggio della rete: AlertBot, Gomez, Keynote, Pingdom

La soluzione di gestione delle prestazioni delle applicazioni Gomez di Compuware, Keynote, Pingdom e AlertBot sono soluzioni che consentono di monitorare l'applicazione Azure dall'esterno. verificandone la disponibilità e ottimizzando le prestazioni. Alcuni servizi, ad esempio Pingdom, consentono l'invio di una notifica tramite e-mail o SMS o tramite uno strumento sul desktop quando viene rilevato un errore. Per essere eseguito in modo corretto, questo tipo di monitoraggio deve simulare le operazioni effettuate da un utente perché talvolta un ruolo Web potrebbe visualizzare la home page senza essere completamente funzionale.

AzureCheck

AzureCheck di Apica è uno strumento che consente di monitorare l'applicazione Web Azure dall'esterno. Per usare lo strumento, è necessario scaricare il codice relativo e aggiungerlo alla propria distribuzione come attività di avvio. Lo strumento presenta il vantaggio di non dover archiviare i log nell'account di archiviazione dell'utente con una conseguente riduzione dei costi di monitoraggio.

Azure Diagnostics Manager

Azure Diagnostic Manager di Cerebrata è un client basato su per la gestione di Diagnostica Windows Azure che consente di visualizzare o scaricare i log raccolti da tale funzionalità. È inoltre possibile gestire la configurazione di WAD, mentre un dashboard consente di monitorare le prestazioni in tempo reale.

Strumenti di esplorazione dell'archiviazione di Azure

Esistono molti modi per esplorare gli archivi di Azure e il team di Archiviazione di Azure ha realizzato un elenco di strumenti di esplorazione dell'archiviazione. Alcuni di tali strumenti consentono di visualizzare file di WAD e file di Analisi archiviazione di Azure. Nella pagina relativa allo strumento di esplorazione per l'archiviazione BLOB di Azure nel sito CloudBerry Lab è disponibile un'interfaccia utente che consente di abilitare direttamente Analisi archiviazione nell'applicazione facendo clic sul pulsante relativo alle impostazioni di archiviazione.

IntelliTrace

Microsoft Visual Studio 2010 Ultimate contiene IntelliTrace, che può essere abilitato per eseguire il debug di applicazioni prima della distribuzione in produzione. IntelliTrace supporta applicazioni ASP.NET e WCF. IntelliTrace non è supportato quando viene abilitato in un servizio di produzione, ma può essere usato per ottenere le eccezioni per un'applicazione dopo la distribuzione in Azure. Il post del blog di Jim Nakashima descrive come usare IntelliTrace per eseguire il debug dei Servizi cloud di Azure.

AVIcode

In seguito all'acquisto da parte di Microsoft, AVIcode ora fa parte di Microsoft System Center. Grazie a una serie completa di funzionalità di monitoraggio delle applicazioni, AVIcode consente di verificare le prestazioni delle applicazioni .NET.

Fiddler

Fiddler è un proxy di debug Web che registra tutto il traffico HTTP o HTTPS tra il computer in uso e Internet. Fiddler consente di controllare il traffico, di impostare i punti di interruzione e di gestire i dati in ingresso e in uscita e risulta particolarmente utile per la risoluzione dei problemi di Archiviazione di Azure.

Per usare Fiddler nell'infrastruttura di sviluppo locale, usare ipv4.fiddler anziché 127.0.0.1:

  1. Avviare Fiddler.

  2. Avviare il servizio nell'infrastruttura di sviluppo.

  3. Accedere all'indirizzo http://ipv4.fiddler:/. Fiddler dovrebbe tenere traccia della richiesta.

Per usare Fiddler per l'archiviazione per sviluppo locale, è necessario modificare il file di configurazione del servizio per puntare a Fiddler:

  1. Aprire il file ServiceConfiguration.cscfg e modificare la stringa di connessione in

    Value=“UseDevelopmentStorage=true;DevelopmentStorageProxyUri=http://ipv4.fiddler”

  2. Avviare Fiddler.

  3. Avviare il servizio. Fiddler dovrebbe tenere traccia di ogni richiesta di archiviazione.

Profilatura delle prestazioni

È possibile profilare un'applicazione Azure quando viene eseguita in Azure per individuare eventuali problemi di prestazioni. Quando si pubblica l'applicazione Azure da Visual Studio, è possibile scegliere di profilare l'applicazione e selezionare le impostazioni di profilatura richieste.

VM Assistant di Azure

Lo strumento VM Assistant è un progetto CodePlex che consente di risparmiare tempo nella diagnosi di problemi grazie alla raccolta di tutti i dati rilevanti in un'unica posizione quando si usa Desktop remoto in un'istanza. Il pulsante relativo all'integrità della macchina virtuale consente di visualizzare lo stato corrente dell'istanza.

Nel caso di soluzioni basate sul cloud, per i progettisti e gli sviluppatori software è più importante prepararsi ai problemi in fase di progettazione rispetto al caso di software preconfezionato tradizionale distribuito in server di un data center aziendale. In questa sezione vengono illustrati alcuni scenari specifici del cui adattamento nel cloud sono responsabili gli sviluppatori e vengono fornite indicazioni per risolvere rapidamente eventuali problemi.

La differenza fondamentale rispetto a una distribuzione basata su server è l'impossibilità di accedere all'hardware del server. Nel componente Azure SDK 1.3 è stata inclusa la possibilità di usare Servizi Desktop remoto per accedere ai ruoli di Azure. L'uso del componente SDK più recente garantisce pertanto l'esperienza migliore. Per creare un servizio Azure supportabile, è necessario innanzitutto abilitare Desktop remoto. Questo passaggio può essere effettuato solo prima della distribuzione.

Uno dei passaggi necessari per abilitare Desktop remoto è rappresentato dalla scelta di un nome utente, di una password e di una data di scadenza dell'account. Questi tre elementi possono essere modificati nel portale di gestione di Azure e questa possibilità risulta particolarmente utile quando si dimentica la password impostata mesi prima al momento della prima distribuzione del servizio.

Quando si fa clic sul pulsante Configura nel portale per modificare uno dei tre parametri, in genere viene visualizzata la sequenza Aggiornamento in corso, Attesa dell'host, Aggiornamento ruolo completato. Attesa dell'host, Pronto. Tale sequenza indica che il ruolo ha ricevuto l'evento di modifica e può gestirlo. I clienti possono effettuare la sottoscrizione agli eventi RoleEnvironment e successivamente, quando ricevono l'evento RoleEnvironment.Changing, possono accettare le modifiche e continuare l'esecuzione (impostazione predefinita) oppure portare l'istanza offline, applicare le modifiche e tornare online (e.Cancel = true).

Se nel codice è previsto il riciclo del ruolo quando si verificano eventi di modifica, tutte le istanze di tutti i ruoli nel servizio ospitato specifico vengono riciclate. I servizi con più istanze per ruolo non subiranno tempi di inattività a causa dell'architettura del dominio di aggiornamento, ma le prestazioni potrebbero diminuire poiché ogni dominio viene riciclato. Un aspetto ancora più importante è legato a un problema che si ripresenti solo una volta al mese, perché in tal caso si perde la possibilità di acquisire lo stato dell'istanza. Si consiglia pertanto di verificare che sia abilitata una connessione a Desktop remoto con credenziali note, sicure e non scadute.

Successivamente, è necessario effettuare un test per verificare che la connessione funzioni. A tale scopo, fare clic sul pulsante Connetti nel portale. Nella maggior parte dei casi è necessario conservare una copia del file RDP in modo che sia possibile modificare la sezione Risorse locali per includere i dischi locali. In questo modo sarà possibile spostare facilmente i file da e nell'istanza. Per eseguire questa operazione, fare clic sulla scheda Risorse locali, quindi sul pulsante Altro. Le impostazioni di connessione nella scheda Generale consentono di salvare le impostazioni dell'utente in un file RDP.

Microsoft Azure - Finestre di dialogo per la connessione a desktop remoto

Come risolvere i problemi sulla macchina virtuale

Dopo aver effettuato la connessione a un'istanza, cosa è necessario cercare? Se si risolvono i problemi relativi a un ruolo che non si riesce ad avviare, vedere questo articolo in MSDN. È disponibile un eccellente post del blog di Kevin Williamson in cui sono contenute informazioni generali sulla posizione dei file di log e sui processi di cui eseguire il debug.

È inoltre possibile installare VM Assistant per esaminare tutti i file di log e ottenere informazioni utili sulla propria istanza nonché installare strumenti diversi, ad esempio Network Monitor o Fiddler, per monitorare la rete. Uno dei test più semplici consiste nell'eseguire Internet Explorer nella propria istanza e connettersi al proprio sito Web per visualizzare i dettagli relativi all'eccezione.

Debug di un Hosted Web Core

Se si esegue un ruolo Hosted Web Core, nella macchina virtuale è disponibile solo una finestra di comando ed è pertanto necessario aprirne una nuova. A tale scopo, eseguire il comando start dal prompt dei comandi per evitare un'esperienza Windows Server completa. Di seguito vengono elencati alcuni comandi di base:

  • Start - Apre una nuova finestra di comando

  • explorer - Apre Esplora risorse

  • eventvwr - Apre il visualizzatore del registro eventi

  • taskmgr - Apre Gestione attività

  • start iexplore - Esegue Internet Explorer

  • services.msc - Apre Service Manager

  • control - Apre il Pannello di controllo

  • certmgr.msc - Apre lo snap-in Gestione certificati

  • regedit - Apre l'editor del Registro di sistema

  • shutdown /r /t 0 - Riavvia l'istanza della macchina virtuale

  • Avvia Gestione attività - Utile se si perde il prompt dei comandi ed è necessario avviarne uno nuovo (in Gestione attività passare a File -> Esegui -> Cmd)

Desktop remoto è la base di un servizio Azure supportabile, ma presenta alcune limitazioni quando il numero di ruoli e di istanze aumenta. Può risultare difficile, ad esempio, conoscere l'istanza a cui è necessario connettersi quando il numero di istanze supera 100. L'uso di questo metodo di risoluzione dei problemi può aumentare effettivamente il tempo necessario per recuperare il proprio sito se non si conoscono gli elementi da cercare e la posizione in cui cercarli.

I punti chiave sono i seguenti:

  • Abilitare Desktop remoto su ogni ruolo durante la distribuzione.

  • Impostare una password complessa e verificare che le credenziali non scadano.

  • Verificare l'accesso per assicurarsi che funzioni prima che si verifichi un problema.

  • Salvare un file RDP per la connessione.

Per usare Diagnostica di Azure, sono necessarie quattro attività fondamentali:

  1. Configurazione di WAD

  2. Configurazione della raccolta dati

  3. Strumentazione del codice

  4. Visualizzazione dei dati

Configurazione di WAD

L'architettura di Diagnostica di Azure prevede innanzitutto di raccogliere i dati sull'istanza e in seguito di archiviarli in modo permanente in Archiviazione di Azure. È necessario pertanto accedere al portale di gestione di Azure per creare un account di archiviazione, ad esempio logpersonali. È consigliabile creare l'account di archiviazione nella stessa posizione geografica in cui si trova l'applicazione Azure per evitare di sostenere costi di larghezza di banda esterna e ridurre la latenza.

Una delle maggiori funzionalità di sviluppo di Strumenti di Azure per Visual Studio versione 1.4 (agosto 2011) e versioni successive è la possibilità di disporre di file di configurazione diversi (ServiceConfiguration.cscfg) per l'ambiente locale e il cloud. Come evidenziato da Nick Harris nel suo blog, l'uso di questa funzionalità presenta numerosi vantaggi. Più configurazioni di servizio possono risultare molto utili per la diagnostica perché semplificano l'uso gratuito dell'emulatore di archiviazione per eseguire test locali mantenendo nel contempo un file di configurazione separato per la produzione. In genere, le applicazioni non si avviano quando vengono pubblicate in Azure se si dimentica di modificare una stringa di connessione contenente UseDevelopmentStorage=true infalse.

Visual Studio semplifica l'abilitazione della diagnostica durante la fase di test tramite l'uso del pulsante Usa emulatore di archiviazione di Azure:

Microsoft Azure - Finestre di dialogo per la connessione ad account di archiviazione

Dopo aver testato l'applicazione e aver verificato che sia pronta per la pubblicazione, è necessario disporre di un account di archiviazione da configurare per il cloud (ServiceConfiguration.Cloug.cscfg). David Makogon indica nel suo blog tre motivi per cui è opportuno disporre di un account di archiviazione specifico per la diagnostica separato da quello di archiviazione dei dati dell'applicazione:

  1. La disponibilità di una chiave di accesso separata per la diagnostica consente di accedere ai log senza rischi per i dati dell'applicazione.

  2. La presenza di più account di archiviazione non prevede alcun costo aggiuntivo perché i costi sono basati sulle dimensioni dei dati.

  3. La disponibilità di un account separato consente di migliorare le prestazioni.

A questo punto impostare la stringa di connessione:

<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="DefaultEndpointsProtocol=https;AccountName=<name>;AccountKey=<key>" />

I valori AccountName e AccountKey sono disponibili nel portale di gestione nella sezione relativa agli account di archiviazione. AccountName è la prima parte dell'URL per gli endpoint di tabella e di archiviazione BLOB (la parte prima di ".table.core.windows.net"). AccountKey è la chiave di accesso primaria codificata a 64 bit per l'account di archiviazione.

Per impostazione predefinita, solo i log di Azure sono abilitati anche se non archiviati in modo permanente. Di conseguenza, in seguito sarà necessario decidere la quantità di dati da raccogliere e il momento in cui trasferire i log. Queste decisioni non sono irrilevanti perché influenzano le prestazioni dell'applicazione e determinano i costi mensili correlati all'archiviazione.

È necessario innanzitutto determinare lo spazio totale di archiviazione necessario per i dati raccolti da Diagnostica di Azure. Questo valore è limitato dalle dimensioni del disco in relazione alle dimensioni dell'istanza/macchina virtuale in uso e dalla proprietà OverallQuotaInMB della classe DiagnosticMonitorConfiguration. Se ad esempio il modello del servizio è stato configurato per usare dimensioni della macchina virtuale molto piccole, la quantità massima di spazio di archiviazione locale disponibile è di 20 GB. Per impostazione predefinita, la proprietà OverallQuotaInMB è impostata su 4 GB, pertanto lo spazio totale di archiviazione locale disponibile è di 16 GB, quantità che potrebbe non essere sufficiente per l'applicazione e i file temporanei. La proprietà OverallQuotaInMB imposta le dimensioni di un buffer circolare riscrivibile. D'altra parte, se nel sito Web è presente una quantità elevata di traffico e se sono stati configurati molti contatori delle prestazioni, i dati di diagnostica potrebbero venire sovrascritti soprattutto se non li si trasferisce periodicamente in un'archiviazione permanente.

Dopo che la macchina virtuale è stata impostata, può essere necessario disporre di una quantità di spazio maggiore di 4 GB. A tale scopo, è possibile aggiungere un elemento <LocalStorage> per DiagnosticStore con l'attributo sizeInMB impostato sulla nuova dimensione nel file ServiceDefinition.csdef e modificare il valore OverallQuotaInMB di conseguenza:

<LocalResources>
      <LocalStorage name="DiagnosticStore" sizeInMB="8192" cleanOnRoleRecycle="false" />
    </LocalResources>

Quando si imposta il valore dell'attributo cleanOnRoleRecycle su false, assicurarsi che la risorsa di archiviazione locale "DiagnosticStore" non venga eliminata nel momento in cui il ruolo viene riciclato. Per il codice completo del file ServiceDefinition.csdef, vedere l'Appendice D: ServiceDefinition.csdef. Questa impostazione non garantisce che i dati vengano conservati se si sposta l'istanza (per problemi hardware e così via). È importante ricordare che le impostazioni di diagnostica sono specifiche di un ruolo ed è pertanto necessario aggiungere una risorsa DiagnosticStore per ciascun ruolo singolarmente.

Il calcolo delle dimensioni complessive dei dati di diagnostica configurati è estremamente importante perché Diagnostica di Azure non verrà eseguito in modo corretto se il totale supera il valore di OverallQuotaInMB. L'unico modo per visualizzare questo errore consiste nell'associare un debugger o nell'aggiungere un blocco try/catch al metodo OnStart. Se il codice catch scrive un evento, nel registro eventi dell'applicazione viene visualizzato un messaggio analogo al seguente:

Microsoft Azure - Registro eventi

Come è possibile calcolare il totale delle quote secondarie richieste? A ogni tipo di raccolta elementi (registri eventi, contatori delle prestazioni e così via) è associato un buffer dei dati il cui valore predefinito è zero. La proprietà BufferQuotaInMB può essere lasciata sul valore predefinito zero, ovvero un valore minore di quello della proprietà OverallQuotainMB, oppure può essere impostata in modo esplicito. Il valore della proprietà OverallQuotaInMB deve essere minore della somma di tutti i valori delle proprietà BufferQuotaInMB.

Quando viene raggiunta la quota massima, i dati meno recenti vengono eliminati man mano che vengono aggiunti nuovi dati. Questi criteri di eliminazione si applicano anche se è stato configurato un intervallo di trasferimento per il buffer. Dopo il trasferimento, i dati rimangono nell'archiviazione locale e vengono eliminati in base ai criteri precedenti.


// Set an overall quota of 8GB.
config.OverallQuotaInMB = 8192;

// Set the sub-quotas and make sure it is less than the OverallQuotaInMB set above
config.Logs.BufferQuotaInMB = 1024;
config.Directories.BufferQuotaInMB = 0; // Use the rest of the storage here
 config.WindowsEventLog.BufferQuotaInMB = 1024;
config.PerformanceCounters.BufferQuotaInMB = 1024;
config.DiagnosticInfrastructureLogs.BufferQuotaInMB = 1024;

Le quote secondarie relative alle directory sono impostate su zero in modo da usare la parte rimanente della quota di archiviazione disponibile. Se si imposta un valore specifico, tale valore deve essere maggiore o uguale a quello delle altre quote perché deve essere sufficientemente grande da contenere i log IIS (ruolo Web) e i dump di arresto anomalo del sistema. Per impostazione predefinita, il valore della proprietà Directory.QuotaInMB è 1024 MB e di conseguenza se un dump di arresto anomalo del sistema è maggiore di un gigabyte non sarà possibile eseguirne la scrittura in modo corretto. I minidump rappresentano l'unico modo per ridurre le dimensioni dei dump.

I file di dump completi contengono una memoria di processo (byte virtuali) al momento dell'arresto anomalo del sistema. Poiché è in esecuzione una versione di Windows a 64 bit, il limite superiore della memoria è costituito dalla memoria fisica del computer. Questo valore è disponibile nella colonna relativa alla memoria nella tabella delle dimensioni dell'istanza/macchina virtuale. Le dimensioni di un dump di arresto anomalo del sistema di un'istanza molto grande possono arrivare fino a 14 GB. Ovviamente questo è lo scenario peggiore, nel quale il processo usa tutta la memoria disponibile, ma è anche quello che si verifica quando si desidera acquisire il file di dump.

Una volta stabilita la quantità di dati di diagnostica da raccogliere, è necessario determinare una strategia per archiviarli in modo permanente.

Un'opzione potrebbe essere quella di non iniziare a raccogliere i dati fino a quando non è stato stabilito che si è verificato un problema. Questa opzione presenta tuttavia due aspetti negativi:

  1. Come si viene a conoscenza che si è verificato un problema? Anche se i clienti possono affidarsi alla segnalazione di un problema principale, come rilevare problemi più insidiosi come la perdita di memoria?

  2. Qual è la linea di base prima che un problema inizi? L'applicazione usa costantemente l'80% della capacità della CPU o si tratta di un sintomo del problema?

Sorprendentemente, questa opzione è la più popolare perché non è soggetta a costi né richiede alcuna pianificazione o azione, anche se è senza dubbio l'opzione peggiore.

La seconda opzione prevede di configurare tutti i contatori necessari, ma di non archiviare in modo permanente i dati in Archiviazione di Window Azure. Quando si verifica un problema, è possibile esaminare i dati oppure avviare manualmente un trasferimento. Sebbene questa opzione sembri una soluzione ideale perché non è soggetta ad alcun costo fino a quando non si verifica un problema, in realtà presenta gli stessi aspetti negativi della prima opzione e il tempo di ripristino aumenta.

La terza opzione prevede di impostare le diverse proprietà ScheduledTransferPeriod su valori abbastanza piccoli per garantire che i dati di diagnostica non vengano sovrascritti nell'istanza, ma sufficientemente grandi da non influire negativamente sulle prestazioni dell'applicazione. Il periodo di trasferimento minore che è possibile impostare è pari a un minuto. Fortunatamente, qualsiasi valore inferiore viene arrotondato a 1, pertanto il salvataggio permanente non viene disattivato. Verificare pertanto che i dati di diagnostica vengano trasferiti prima che siano effettivamente necessari.

Un problema comune che si verifica in numerosi esempi di codice è costituito dal fatto che il valore di ScheduledTransferPeriod è impostato su un minuto, condizione che può influire negativamente sulle prestazioni dell'applicazione in produzione. Negli esempi viene usato il valore minimo per consentire all'utente di verificare rapidamente il funzionamento. La maggior parte degli sviluppatori non desidera attendere 30 minuti per verificare che i log siano stati trasferiti. Per risolvere il problema, è possibile modificare sistematicamente la configurazione WAD dopo la distribuzione tramite uno degli Altri strumenti utili oppure aggiungere codice più un'impostazione al file ServiceConfiguration.cscfg sfruttando la possibilità di disporre di più file di configurazione del servizio citata in precedenza in questa sezione. Tale impostazione viene creata in modo analogo al seguente nel file ServiceConfiguration.Local.cscfg:

<ConfigurationSettings>
      <Setting name="ScheduledTransferPeriod" value="1" />

Nel file ServiceConfiguration.Cloud.cscfg l'impostazione è invece analoga alla seguente:

<ConfigurationSettings>
      <Setting name="ScheduledTransferPeriod" value="30" />

Il codice del metodo OnStart e dell'evento RoleEnvironmentChanging è analogo al seguente:

// Get ScheduledTransferPeriod setting from ServiceConfiguration.cscfg and then set it 
var myScheduledTransferPeriod = RoleEnvironment.GetConfigurationSettingValue("ScheduledTransferPeriod");
TimeSpan myTimeSpan = TimeSpan.FromMinutes(Convert.ToDouble(myScheduledTransferPeriod));
config.Logs.ScheduledTransferPeriod = myTimeSpan;
config.Directories.ScheduledTransferPeriod = myTimeSpan;
config.WindowsEventLog.ScheduledTransferPeriod = myTimeSpan;
config.PerformanceCounters.ScheduledTransferPeriod = myTimeSpan;
config.DiagnosticInfrastructureLogs.ScheduledTransferPeriod = myTimeSpan;

L'altra variabile che influisce sulla quantità di dati raccolti è il livello di registrazione. Una delle più importanti origini dati da cui eseguire la raccolta è il registro eventi dell'applicazione, che risulta particolarmente utile con il registro eventi di sistema. I registri eventi di sicurezza non sono disponibili in WAD. Le dimensioni di tali file possono essere modificate tramite i valori di filtro seguenti che specificano il livello delle voci di log:

  • Critico

  • Error

  • Warning

  • Informazioni

  • Verbose

Il livello di registrazione è cumulativo, pertanto se il filtro è impostato su Warning verranno trasferite anche le voci impostate su Error e Critical. È possibile usare il metodo precedente per configurare livelli LogLevelFilter specifici per le configurazioni locali e cloud. Il file ServiceConfiguration.Local.cscfg è analogo al seguente:

<Setting name="LogLevelFilter" value="Information" />

Il file ServiceConfiguration.Cloud.cscfg è analogo al seguente:

      <Setting name="LogLevelFilter" value="Error" />

Il codice del metodo OnStart e dell'evento RoleEnvironmentChanging è analogo al seguente:

// Get LogLevelFilter setting from ServiceConfiguration.cscfg and then set it
var LogLevelFilter = RoleEnvironment.GetConfigurationSettingValue("LogLevelFilter");
var myLogLevel = LogLevel.Undefined;
switch (LogLevelFilter)
{
    case ("Information"):
        myLogLevel = LogLevel.Information;
        break;
    case ("Verbose"):
        myLogLevel = LogLevel.Verbose;
        break;
    case ("Warning"):
        myLogLevel = LogLevel.Warning;
        break;
    case ("Critical"):
        myLogLevel = LogLevel.Critical;
        break;
    case ("Error"):
        myLogLevel = LogLevel.Error;
        break;
    default:
        break;
} 

// Filter what will be sent to persistent storage.
config.Logs.ScheduledTransferLogLevelFilter = myLogLevel;
config.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter = myLogLevel;
config.WindowsEventLog.ScheduledTransferLogLevelFilter = myLogLevel;

Il codice consigliato può anche non soddisfare le esigenze dell'utente. Per coloro che non desiderano aggiungere alcun codice e preferiscono mantenere l'ultima configurazione nota anziché le impostazioni definite nel codice, è prevista un'altra soluzione.

Uso di un file di configurazione

Nel componente Azure SDK 1.3 è stata aggiunta la possibilità di inserire la configurazione in un file XML anziché scrivere codice. David Hardin sostiene che questo è il modo più efficiente per configurare la diagnostica per tutti i tipi di ruolo di Azure. Rispetto alla scrittura di codice, questo metodo presenta numerosi vantaggi:

  1. WAD viene avviato prima dell'esecuzione del metodo OnStart in modo che vengano rilevati eventuali errori nelle attività di avvio.

  2. Eventuali modifiche apportate alla configurazione in fase di esecuzione verranno mantenute anche dopo un riavvio.

  3. Viene avviato automaticamente un agente di diagnostica configurato senza la necessità di codice aggiuntivo che può generare un'eccezione e quindi il mancato avvio del ruolo.

  4. Questo è l'unico metodo per ottenere diagnostica da un ruolo di macchina virtuale in versione beta.

  5. Le modifiche alla configurazione non richiedono la ricompilazione del codice.

Un esempio del file diagnostics.wadcfg è disponibile nell'Appendice F: diagnostics.wadcfg. Il file di configurazione denominato diagnostics.wadcfg deve essere inserito nei percorsi seguenti ed è necessario verificare che l'opzione Copia in directory di output sia impostata su Copia sempre:

  • Per i ruoli di lavoro, il file di configurazione si trova nella directory radice del ruolo.

  • Per i ruoli Web, il file di configurazione si trova nella directory bin nella directory radice del ruolo.

  • Per i ruoli di macchina virtuale in versione beta, il file di configurazione deve trovarsi nella cartella %Programmi%\Azure Integration Components\<NumeroVersione>\Diagnostics dell'immagine server caricata nel portale di gestione di Azure. <NumeroVersione> è la versione di Azure SDK in uso. Nella cartella è presente un file predefinito che è possibile modificare o sovrascrivere con un file personalizzato.

Il formato di tale file è descritto nel documento MSDN seguente. Il file con estensione wadcfg viene ignorato se è già presente una configurazione XML nel contenitore di archiviazione BLOB wad-control-container. È inoltre necessario verificare che ogni elemento del file sia corretto. In caso contrario, non verrà raccolto alcun dato di diagnostica.

A questo punto è possibile decidere le informazioni da raccogliere.

Configurazione della raccolta dati

Se non si desidera usare un file di configurazione, il modo migliore per avviare la diagnostica è usare il metodo OnStart con un blocco try/catch. Il blocco garantisce la possibilità di gestire in modo efficiente un eventuale problema, evitando in tal modo che il ruolo si blocchi durante il riciclo. L'aspetto negativo dell'inserimento di codice nel metodo OnStart è la mancata possibilità di gestire tutte le eccezioni, pertanto durante l'operazione di riciclo il ruolo potrebbe entrare in un ciclo di cui è difficile eseguire il debug. In questo metodo invece l'istanza del ruolo è impostata sul valore Occupato e non è disponibile tramite il bilanciamento del carico di Azure. Se il metodo OnStart restituisce false o se si verifica un'eccezione, l'istanza del ruolo viene immediatamente arrestata. Se il metodo restituisce true, Azure avvia il ruolo chiamando il metodo Run.

Se si esegue il wrapping del codice OnStart in un blocco try/catch, è possibile evitare che il ruolo entri in un ciclo, ovvero che nel portale di gestione il ruolo non sia mai nello stato di pronto, quando si verifica un'eccezione. Il codice catch può contenere una chiamata al metodo Trace.WriteLine (esempio MSDN) oppure è possibile inserire un errore nel registro eventi (blog sul debug in ASP.NET). Se si inserisce un errore nel registro eventi, è più semplice visualizzare il motivo per cui il ruolo non si avvia. Una lieve modifica a questo codice è stata proposta da Tom Christian e prevede la registrazione dell'eccezione nel registro eventi dell'applicazione come indicato di seguito:

catch (Exception e)  
    {
            string sSource;
            string sEvent;
            sSource = "WaAppAgent";
            sEvent = "WorkerRole OnStart Event: " + e.Message;
            EventLog.WriteEntry(sSource, sEvent, EventLogEntryType.Error, 0);
    }

Il codice completo è disponibile nell'Appendice B: esempio di codice per un ruolo Web. Il metodo più potente per configurare la diagnostica consiste nell'usare sia un file di configurazione che codice che consenta di modificare dinamicamente la configurazione nel portale di gestione.

Ora che la diagnostica di Azure è configurata, è possibile iniziare a raccogliere dati. I dati che possono essere raccolti sono di cinque tipi:

  • Dump di arresto anomalo del sistema

  • Registro eventi di Windows

  • Contatori delle prestazioni

  • Log IIS

  • Log FREB

Nella tabella seguente viene fornita una panoramica dei dati raccolti localmente per impostazione predefinita e dei dati che è necessario configurare in modo esplicito.

 

Origine dati configurazione predefinita Descrizione

DiagnosticInfrastructureLogs

Abilitata, dati archiviati localmente, nessun trasferimento nell'archiviazione locale definito. Trasferimenti nella tabella di archiviazione WADDiagnosticInfrastructureLogsTable.

Log specifici dell'infrastruttura di diagnostica. In genere non risultano molto utili.

Logs

Abilitata, dati archiviati localmente, nessun trasferimento nell'archiviazione locale definito. Trasferimenti nella tabella di archiviazione WADLogsTable.

Log System.Diagnostics.Trace disponibili nel codice dell'applicazione.

Directory

Oggetti BLOB wad-iis-failedreqlogfiles, wad-iis-logfiles e wad-crash-dumps vengono creati automaticamente per impostazione predefinita, ciascuno con la proprietà DirectoryQuotaInMB impostata su 1024 MB. È inoltre possibile configurare directory aggiuntive.

I dati del log verranno trasferiti nell'intervallo di trasferimento definito da ScheduledTransferPeriod.

PerformanceCounters

Disabilitata. Quando i contatori vengono aggiunti, il nome della tabella di archiviazione è WADPerformanceCountersTable.

I contatori delle prestazioni devono essere specificati in modo esplicito.

WindowsEventLog

Disabilitata. Quando i registri eventi vengono aggiunti, il nome della tabella di archiviazione è WADWindowsEventLogsTable.

Nessun oggetto DataSources viene specificato per i registri eventi di Windows.

CrashDumps

I minidump di arresto anomalo del sistema vengono raccolti in locale. È possibile abilitare dump completi. wad-crash-dumps è il nome creato nell'archiviazione BLOB.

Chiamare il metodo EnableCollection(true) per ottenere dump di arresto anomalo del sistema completi.

Dati di traccia delle richieste non riuscite di IIS 7.0

Disabilitata. Quando tali dati vengono aggiunti, il nome dell'archiviazione BLOB è wad-iis-failedreqlogfiles.

Questo elemento deve essere abilitato nel file Web.config.

  • Dump di arresto anomalo del sistema

    Diagnostica di Azure non raccoglie dump di arresto anomalo del sistema in modo automatico. La sintassi è poco chiara, perché per raccogliere minidump è necessario aggiungere il codice seguente:

    // Enable crash mini dump collection.
                    CrashDumps.EnableCollection(false);
    
    Il codice per raccogliere dumo completi è analogo al seguente:

                    // Enable full crash dump collection.
                    CrashDumps.EnableCollection(true);
    
    Come indicato nella sezione relativa all'impostazione della proprietà Directory.QuotaInMB, se sono presenti dump completi è necessario allocare spazio di archiviazione locale e totale sufficiente per salvare un dump completo.

  • Registri eventi

    I registri eventi rappresentano lo strumento migliore per trovare errori nelle applicazioni. Di seguito viene indicato come è possibile aggiungere eventi di sistema e dell'applicazione:

    // Add in configuration settings for Windows Event logs           config.WindowsEventLog.DataSources.Add("Application!*");
    config.WindowsEventLog.DataSources.Add("System!*");
    
    Verranno raccolti solo gli eventi che si verificano dopo l'avvio di Diagnostica di Azure, aspetto che rende inutili i registri eventi per diagnosticare i problemi di avvio a meno che non si usi il metodo consigliato per avviare e configurare la diagnostica.

    È inoltre possibile applicare un filtro per raccogliere solo determinati eventi. Nel blog di Steve Marx viene descritto come creare una query XPath per ottenere solo le informazioni utili. Se ad esempio si usa la query XPath seguente con il metodo Add, vengono raccolti solo i messaggi WaAppAgent:

    ("Application!*[System[Provider[@Name='WaAppAgent']]]")
    
  • Contatori delle prestazioni

    I contatori delle prestazioni devono essere aggiunti in modo esplicito. La difficoltà nell'impostazione di tali contatori consiste nel fatto che il funzionamento non corretto di uno dei contatori si ripercuote su quello di tutti i contatori del ruolo specifico. Nella finestra di output dell'emulatore di calcolo viene visualizzato l'errore seguente:

    [MonAgentHost] Error:  PdhExpandWildCardPath(\Process(_Total)) failed
    
    I ruoli Web e di lavoro possono usare più linguaggi. Per tutti i tipi di ruolo, questi sono i contatori delle prestazioni di base consigliati. Il nome del processo nell'esempio seguente (WaWorkerHost) deve essere modificato in WaIISHost per un ruolo Web. Il codice specifico per un ruolo di lavoro che non esegue codice .NET è disponibile in Appendice C: esempio di codice per un ruolo di lavoro:

    • @"\Process(WaWorkerHost)\% Processor Time "

    • @"\Process(WaWorkerHost)\Private Bytes "

    • @"\Process(WaWorkerHost)\Thread Count"

    • @"\Processor(_Total)\% Processor Time"

    • @"\Memory\Available Bytes"

    Per un ruolo Web o un ruolo di lavoro che esegue codice in linguaggio .NET, sono disponibili contatori aggiuntivi che devono essere monitorati. Anche in questo caso, il nome del processo nell'esempio seguente (w3wp) deve essere modificato in WaWorkerHost se il ruolo è di lavoro e in WaIISHost se si usa un ruolo Web in modalità IIS completa. I contatori delle prestazioni per un ruolo Web che esegue codice in linguaggio .NET sono disponibili in Appendice B: esempio di codice per un ruolo Web:

    • @"\Process(w3wp)\% Processor Time "

    • @"\Process(w3wp)\Private Bytes "

    • @"\Process(w3wp)\Thread Count "

    • @"\Processor(_Total)\% Processor Time"

    • @"\Memory\Available Bytes"

    • @"\ASP.NET\Applications Running"

    • @"\.NET CLR Interop(_Global_)\# of marshalling"

    • @"\.NET CLR Jit(_Global_)\% Time in Jit"

    • @"\.NET CLR Loading(_Global_)\% Time Loading"

    • @"\.NET CLR LocksAndThreads(_Global_)\Contention Rate / sec"

    • @"\.NET CLR Memory(_Global_)\# Bytes in all Heaps"

    • @"\.NET CLR Networking(_Global_)\Connections Established"

    • @"\.NET CLR Remoting(_Global_)\Remote Calls/sec"

    La stringa WaIISHost deve essere modificata in w3wp se non viene usata la modalità IIS completa. Come indicato in precedenza, il valore ScheduledTransferPeriod determina se e quando i contatori vengono archiviati in modo permanente.

  • Log IIS

    I ruoli Web di Azure vengono eseguiti in IIS con registrazione abilitata per impostazione predefinita e vengono scritti in formato W3C con codifica UTF-8 nella cartella delle risorse per l'applicazione (ad esempio, C:\Resources\directory\c5c31518818e46569fa68f0809b5a6aa.fm_WebRole.DiagnosticStore\LogFiles\Web) con Aggiornamento file di registro impostato su Ogni ora. È presente un file di log per sito. Se si accede in modalità remota a una delle istanze e si apre Gestione Internet Information Services, è possibile visualizzare le impostazioni seguenti:

    Microsoft Azure - Finestra di dialogo per la registrazione

    Le opzioni di registrazione predefinite possono essere modificate per soddisfare le esigenze specifiche dell'utente. Lo stratagemma consiste nel fatto che tutte le modifiche dovranno essere incorporate in un'attività di avvio in modo che al riavvio di ogni istanza le modifiche non vadano perse. Per registrare solo errori, ad esempio, è possibile usare Appcmd.exe che fa parte di IIS7 in un'attività di avvio che contiene il comando seguente:

    appcmd set config /section:httpLogging /dontLog:False /selectiveLogging:LogError
    
  • Traccia delle richieste non riuscite

    Se si dispone di un ruolo Web, si desidera certamente raccogliere i log delle tracce delle richieste non riuscite (in precedenza buffering delle richieste non riuscite o FREB, Failed Request Buffering). Questa operazione viene eseguita nel file Web.config aggiungendo le righe seguenti alla sezione <system.webServer> in modo analogo al seguente:

    <tracing>
          <traceFailedRequests>
            <add path="*">
              <traceAreas>
                <add provider="ASP" verbosity="Verbose" />
                <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
                <add provider="WWW Server" areas="Authentication, Security, Filter, StaticFile, CGI, Compression, Cache, RequestNotifications,Module" verbosity="Verbose" />
              </traceAreas>
              <failureDefinitions timeTaken="00:00:20" statusCodes="400-599" />
            </add>
          </traceFailedRequests>
        </tracing>
    
    In questo modo vengono registrati gli errori relativi a ogni richiesta che supera i 15 secondi o con codice di stato compreso tra 400 e 599 (elemento failureDefinitions). Una volta creato, il log FREB viene automaticamente archiviato in modo permanente.

  • Altre directory

    Può essere opportuno inoltre raccogliere altri file scritti nell'istanza, in particolare file di agente guest. Tali file possono fornire informazioni sulle interazioni tra l'agente guest e il controller di infrastruttura di Azure. A tale scopo, è necessario impostare una directory che verrà copiata da Diagnostica di Azure:

              // Add a custom directory transfer
              DirectoryConfiguration directoryConfiguration = new DirectoryConfiguration();
              directoryConfiguration.Container = "wad-custom-logs";
              directoryConfiguration.DirectoryQuotaInMB = 0;
              directoryConfiguration.Path = @"c:\logs\WaAppAgent.log";
              config.Directories.DataSources.Add(directoryConfiguration);
    
    La stessa avvertenza si applica qui in relazione alla situazione che si può verificare se la configurazione non riesce. Per eseguire il test nell'emulatore di calcolo, è necessario creare questa cartella e verificare che più ruoli non eseguano questo codice per evitare una violazione della condivisione. Questo errore non si verifica nella configurazione cloud perché ogni istanza è separata.

Risoluzione dei problemi relativi a WAD

Ora che la configurazione è completata, è necessario eseguirne il test sia nell'emulatore di calcolo che nella distribuzione in Azure. Se i dati di diagnostica non vengono visualizzati, controllare gli elementi elencati di seguito.

  1. Verificare i BLOB nel contenitore BLOB wad-control-container nell'account di archiviazione di diagnostica. Il BLOB da cercare è quello denominato con <ID distribuzione>/<Nome ruolo>/<Istanza ruolo>, ad esempio 3981bcff0eb743ddb9b7574a8821e955/WebRole1/WebRole1_IN_0.

    1. Aprire il file XML e verificare che sia configurato nel modo previsto. Se viene visualizzato <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes> per un'origine dati specifica, la diagnostica non è configurata per trasferire alcun dato.

    2. Se sono presenti più istanze e qualche istanza sta trasferendo dati di diagnostica a differenza di altre, confrontare i file XML per verificare che tutte le istanze siano configurate in modo corretto.

    3. Se si configura la diagnostica dopo la distribuzione e il funzionamento relativo si interrompe in modo casuale, la causa può essere il riciclo del ruolo o il riavvio dell'istanza. Quando un'istanza viene riavviata, le impostazioni di post-distribuzione personalizzate vanno perdute e viene usata la diagnostica configurata nel codice. Uno dei vantaggi principali correlati all'uso del file con estensione wadcfg è che la configurazione non viene sovrascritta al momento del riciclo del ruolo.

  2. Verificare i log nella tabella WADDiagnosticInfrastructureLogsTable nell'account di archiviazione di diagnostica. È possibile applicare un filtro in base all'ID distribuzione, ad esempio ID distribuzione uguale a 'bd9e149f76e8413aba8865c77326e449'. Cercare eventuali eccezioni o messaggi di errore che potrebbero indicare i motivi per cui i dati di diagnostica non vengono trasferiti.

  3. Se l'informazione Diagnostics.Trace non viene raccolta, verificare che DiagnosticMonitorTraceListener sia configurato nel file web.config o app.config. Il file è configurato per impostazione predefinita nei progetti cloud, ma talvolta può subire modifiche e di conseguenza le istruzioni di traccia non vengono raccolte dalla diagnostica.

  4. Un problema comune è rappresentato dall'esecuzione non corretta di query sull'archiviazione di diagnostica e di conseguenza non viene restituito alcun risultato e si presuppone che i dati di diagnostica non vengano acquisiti. Eseguire le query sulle tabelle di diagnostica, applicando filtri su ID distribuzione e verificare se i dati vengono trasferiti in modo corretto o meno. Gli errori relativi alle query si possono verificare in genere qualora non si applichi un filtro a ID distribuzione e non si seguano i token di continuazione.

  5. Se dopo la distribuzione l'istanza non si avvia, verificare che l'account di archiviazione configurato nel file ServiceConfiguration.cscfg non sia impostato su "UseDevelopmentStorage=true". Se si usa una versione di Strumenti di Azure per Visual Studio 2011 successiva ad agosto 2011, verrà visualizzato un messaggio di avviso. In caso contrario, è necessario usare RDP nell'istanza e verificare che il file di configurazione del ruolo si trovi nella cartella C:\Config.

  6. Quando si è connessi all'istanza, è necessario inoltre verificare che DiagnosticsAgent.exe e MonAgentHost.exe siano in esecuzione. In tal caso, è possibile installare e collegare WinDBG per verificare se vengono generate eccezioni.

  7. È inoltre possibile controllare che i dati di diagnostica vengano scritti in locale.

    • Per l'ambiente di sviluppo, il file con estensione tsf files viene scritto nella directory seguente:

      c:\Utenti\<nomeutente>\AppData\Local\dftmp\Resources\<ID distribuzione>\directory\DiagnosticStore\Monitor\Tables

    • In un'istanza in esecuzione i file vengono scritti nella directory seguente:

      c:\Resources\<ID distribuzione>.<ruolo>\directory\DiagnosticStore\Monitor\Tables

    Per leggere tali file, attualmente è necessario creare un caso di supporto tecnico e inviarli a Microsoft.

  8. Se sono presenti più istanze e solo alcune di esse non trasferiscono i dati di diagnostica in modo corretto, provare a ricreare l'immagine del ruolo nel portale di gestione. Questa soluzione deve essere usata come ultima risorsa per non perdere la possibilità di determinare la causa radice per cui si è verificato il problema.

Strumentazione del codice

È probabile che i dati di diagnostica più importanti siano i messaggi di traccia che gli sviluppatori aggiungono al codice. I dati di sistema, infatti, possono restituire eccezioni o registrare messaggi di errore. È possibile tenere traccia persino di specifiche chiamate a sistemi dipendenti. La procedura consigliata consiste nell'aggiungere un messaggio di traccia durante la chiamata a un sistema dipendente che può non riuscire; ad esempio, a un servizio di autenticazione di terze parti.

Il framework ETW associa un elemento TraceEventType a ogni evento:

 

TraceEventType Livello Valore Significato

Critico

1

0x0001

Errore irreversibile o arresto anomalo dell'applicazione

Error

2

0x0002

Errore reversibile

Warning

3

0x0004

Problema non critico che può indicare problemi più seri in futuro

Informazioni

4

0x0008

Messaggio informativo

Verbose

5

0x0010

Traccia di debug (ad esempio informazioni dettagliate di flusso di esecuzione, parametri e così via)

Avvia

0x0100

Avvio di un'operazione logica

Stop

0x0200

Arresto di un'operazione logica

Dopo aver definito un piano per instrumentare il codice, è possibile aggiungere lo spazio dei nomi System.Diagnostics e successivamente i messaggi di traccia, in modo analogo al codice C# seguente:

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

Poiché Azure è stato avviato per essere eseguito in modalità IIS completa (SDK 1.3), il codice dell'applicazione Web viene eseguito in un dominio di applicazione e in un processo diversi da RoleEntryPoint. Questo significa che i messaggi di traccia non vengono visualizzati nell'emulatore di calcolo a meno che non si aggiunga un altro listener di traccia al file Web.Config in Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener:

<add type="Microsoft.ServiceHosting.Tools.DevelopmentFabric.Runtime.DevelopmentFabricTraceListener, Microsoft.ServiceHosting.Tools.DevelopmentFabric.Runtime, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="DevFabricListener">
    <filter type=""/>
</add>

Per applicazioni più complesse, la disponibilità di una metodologia EventId consente di filtrare i log in modo più efficiente e di risolvere pertanto i problemi in modo più rapido. Se si usa il metodo WriteLine di C#, EventId è sempre uguale a 0. Per specificare un oggetto EventId, è necessario usare il metodo TraceEvent, in cui l'elemento traceType è nella posizione indicata nella tabella seguente:

Trace.TraceEvent(traceType, eventId, message);

I messaggi di traccia vengono archiviati in modo permanente nella tabella WADLogsTable. A ogni evento registrato, Azure associa automaticamente un timestamp, un conteggio (che fornisce un intervallo più dettagliato con una granularità di 100 nanosecondi) e informazioni sulla distribuzione, sul ruolo e sull'istanza del ruolo. In questo modo è possibile circoscrivere i log a istanze specifiche. Il messaggio viene archiviato in un formato XML analogo al seguente:


<Properties>
 <EventTickCount>634402131502204503</EventTickCount>
 <DeploymentId>deployment(28)</DeploymentId>
 <Role>WebRole1</Role>
 <RoleInstance>deployment(28).Sample.WebRole1.0</RoleInstance>
 <Level>3</Level>
 <EventId>20</EventId>
 <Pid>10796</Pid>
 <Tid>7172</Tid>
 <Message>trace message; TraceSource 'Data' event</Message> 
</Properties>

Il livello corrisponde all'elemento TraceEventType. Nella tabella precedente si nota che il livello 3 corrisponde a Warning. Se non è specificato alcun elemento TraceEventType o se si usa Trace.WriteLine, il livello viene impostato su 5 (Verbose).

Nella maggior parte dei casi, la registrazione standard è sufficiente. Per tipi di registrazione più dettagliati, è possibile creare un listener di traccia personalizzato:

Azure Table Query è un progetto CodePlex di ruoli Web che consente di eseguire query su WADLogsTable tramite una query LINQ query.

Visualizzazione dei dati

Il motivo per cui è opportuno raccogliere i dati di diagnostica è la possibilità di averli disponibili quando si verifica un problema. È pertanto importante verificare il funzionamento corretto di ogni elemento prima che il problema si verifichi, in modo analogo a come è necessario verificare che un backup dei dati funzioni correttamente. Questa esigenza comporta non solo la visualizzazione dei dati di diagnostica durante la fase di test dell'applicazione e la verifica periodica del funzionamento, ma anche la creazione di una linea di base in modo che sia possibile rilevare le prestazioni anomale quando si verificano.

Tutti i dati di Diagnostica di Azure vengono memorizzati nell'account di archiviazione specificato all'avvio di WAD. Per visualizzare tali dati, è possibile usare Esplora server di Visual Studio oppure uno dei numerosi storage explorers.

L'oggetto BLOB wad-control-container contiene la registrazione dell'infrastruttura di diagnostica e consente di visualizzare se i dati vengono trasferiti da una determinata istanza. L'identità dell'oggetto BLOB è nella forma seguente:

0aef2b51ad1d49ef915dd41d3ca01f24/WorkerRole1/WorkerRole1_IN_0

Tale identità è divisa in tre parti:

  1. Il numero lungo rappresenta l'ID distribuzione - 0aef2b51ad1d49ef915dd41d3ca01f24

  2. Nome ruolo - WorkerRole1

  3. Nome istanza - WorkerRole1_IN_0

Quando sono presenti più istanze, il suffisso in base zero viene incrementato, ad esempio WorkerRole1_IN_1 rappresenta la seconda istanza.

Nella tabella seguente viene indicata la posizione in cui ogni log viene scritto.

 

Tipo di log Formato di Archiviazione di Azure Note

Log di Azure generati dal codice

Tabella

È necessario aggiungere il listener di traccia al file web.config o app.config. I file vengono archiviati in WADLogsTable.

Log di IIS 7.0

BLOB

Solo ruoli Web. Archiviati in un contenitore BLOB nel percorso wad-iis-logfiles\<ID distribuzione>\<nome ruolo Web>\<istanza ruolo>\W3SVC1.

Log di Infrastruttura diagnostica Windows

Tabella

Informazioni sul servizio stesso di diagnostica. Archiviati nella tabella WADDiagnosticInfrastructureLogs.

Log delle richieste non riuscite

BLOB

Solo ruoli Web. Abilitati tramite le opzioni di traccia nelle impostazioni system.WebServer nel file web.config. Archiviati in un contenitore BLOB nel percorso wad-iis-failedreqlogfiles\<ID distribuzione>\<nome ruolo Web>\<istanza ruolo>\W3SVC1.

Registri eventi di Windows

Tabella

Abilitati tramite la modifica di DiagnosticMonitorConfiguration.WindowsEventLog durante la configurazione iniziale. Archiviati nella tabella WADWindowsEventLogs.

Contatori delle prestazioni

Tabella

Abilitati tramite la modifica di DiagnosticMonitorConfiguration.PerformanceCounters. Archiviati nella tabella WADPerformanceCounters. Nell'esempio di codice il ruolo di lavoro imposta un contatore delle prestazioni.

Dump di arresto anomalo del sistema

BLOB

Abilitati dalla chiamata a CrashDumps.EnableCollection. Archiviati in un contenitore BLOB nel percorso wad-crash-dumps. Poiché la maggior parte delle eccezioni viene gestita in ASP.NET, questa funzionalità in genere è utile solo per un ruolo di lavoro.

Log degli errori personalizzati

BLOB

Per un esempio sull'uso di questi log, vedere il blog di Neil Mackenzie.

Quando i dati dei dump di arresto anomalo del sistema vengono trasferiti nell'archiviazione permanente, vengono archiviati nel contenitore BLOB wad-crash-dumps. I log IIS vengono trasferiti nel contenitore BLOB wad-iis-logfiles, mentre le richieste non riuscite vengono archiviate nel contenitore BLOB wad-iis-failedreqlogfiles.

I registri eventi vengono trasferiti nella tabella WADWindowsEventLogs nell'archiviazione permanente, mentre i contatori delle prestazioni vengono trasferiti nella tabella WADPerformanceCounters in base all'intervallo specificato. Nella tabella WADDiagnosticInfrastructureLogs sono contenuti log relativi all'infrastruttura di diagnostica e i listener di traccia sono disponibili nella tabella WADLogsTable.

Per visualizzare i dati di diagnostica, è inoltre possibile usare LINQPad come indicato nell'esempio AzureLogsWithLINQPad di Jason Haley.

Gestione della diagnostica

Il salvataggio permanente di tutti i file di log descritti nell'archiviazione di Azure comporta un costo in termini economici e di tempo. La soluzione ideale è quella di abilitare la traccia nel momento esatto in cui è necessario risolvere un particolare problema. Quando si modificano dinamicamente le impostazioni di diagnostica, è necessario ricordare di ripristinare manualmente le impostazioni originali o di modificare queste ultime se alcuni elementi devono essere sempre presenti. Questo passaggio, eseguito in modo consapevole, è particolarmente importante se non si usa un file con estensione wadcfg perché, nel caso in cui l'istanza venga riavviata, le nuove impostazioni verranno sostituite con le impostazioni di diagnostica configurate nel codice.

cmdlet di PowerShell per Azure consentono di gestire numerosi aspetti dei servizi di Azure in esecuzione, ad esempio la diagnostica. I cmdlet vengono eseguiti nel computer locale e usano le API di gestione e di diagnostica di Azure per connettersi tramite Internet al servizio, fornendo informazioni e modificando parametri.

Windows PowerShell viene installato con Windows 7 e rappresenta la versione più evoluta dei cmdlet di Gestione servizio installati con lo strumento di gestione di Azure (MMC). Di seguito vengono elencati alcuni dei cmdlet più importanti:

  • Get-DiagnosticConfiguration - Ottiene la configurazione del buffer per il nome buffer specificato (Logs, Directories, PerformanceCounters, WindowsEventLogs o DiagnosticInfrastructureLogs).

  • Per modificare la configurazione per un ruolo, usare il cmdlet Set-DiagnosticConfiguration.

  • Start-OnDemandTransfer - Avvia un trasferimento su richiesta del buffer dei dati specificato. In questo modo i dati vengono spostati nell'archiviazione di Azure (tabella o archiviazione BLOB).

Nel blog di David Aiken è disponibile uno script per eliminare alcuni file di log (file di log IIS e file XML wad-control-container). Il cmdlet Clear-Container deve essere chiamato per ogni contenitore. È inoltre necessario verificare che i trasferimenti pianificati non si sovrappongano all'eliminazione nonché definire una strategia per i log archiviati in tabelle, ad esempio contatori delle prestazioni, registri eventi e così via. Alcuni utenti scaricano tutti i log dall'archiviazione di Azure e li inseriscono in un database di SQL Server in modo da non incorrere più in costi di archiviazione e da essere in grado di eseguire query sui dati più complesse.

Grazie alla conoscenza delle risorse di diagnostica di Azure, gli sviluppatori possono compilare applicazioni compatibili tramite le procedure di progettazione consigliate descritte di seguito.

L'integrità di un'applicazione deve essere misurata in relazione a una linea di base. Il semplice fatto che la home page venga visualizzata non significa necessariamente che l'applicazione sia integra. Per creare una linea di base completa rispetto alla quale valutare l'integrità, è necessario inoltre conoscere l'integrità e le prestazioni della logica di business.

Il passaggio successivo consiste nel comprendere come ottenere e mantenere l'integrità. L'elemento base su cui si basa l'integrità è la puntualità dei pagamenti relativi ad Azure. Una sottoscrizione non pagata determina progressivamente conseguenze negative, che provocano in definitiva l'eliminazione dell'applicazione.

Per ogni sottoscrizione, un servizio ospitato di Azure è caratterizzato da quattro livelli che possono influire sull'integrità dell'applicazione.

Microsoft Azure - Livelli di integrità

Un'istanza ad esempio può non essere eseguita in modo corretto a causa di un errore hardware o essere riavviata a causa di un aggiornamento software. Questa situazione non provoca tuttavia un errore del ruolo a meno non si disponga di un'unica istanza configurata. In modo analogo, ogni servizio ospitato si trova in un'area particolare, ad esempio Stati Uniti centro-meridionali. Queste informazioni critiche determinano se l'applicazione è interessata da un evento di interruzione del servizio. Gli errori ai livelli inferiori possono provocare errori a livello del servizio ospitato se in fase di progettazione dell'applicazione non è stata incorporata la ridondanza.

La maggior parte delle applicazioni Azure richiede architetture più complesse rispetto a quelle indicate nel diagramma precedente. L'applicazione in uso probabilmente ha un aspetto analogo al seguente:

Microsoft Azure - Esempio di architettura

La natura di un ambiente distribuito introduce più punti di errore possibili e la possibilità di documentare tali percorsi critici rende più efficiente la risoluzione dei problemi. In relazione al diagramma precedente, ad esempio, può essere utile conoscere il modo in cui eseguire il test se si verifica un errore durante il controllo di accesso.

Per comprendere gli errori che si sono verificati in un'applicazione, è necessario monitorarne e registrarne lo stato. In generale, è opportuno registrare quattro categorie di informazioni relative all'applicazione:

  • Informazioni a livello di codice - Eccezioni, valore delle variabili chiave e qualsiasi informazione necessaria per eseguire il debug dell'applicazione.

  • Processo aziendale - Controllo necessario per la sicurezza, il rilevamento delle modifiche e la conformità.

  • Stabilità del sistema - Prestazioni, scalabilità, velocità effettiva, latenze.

  • Convalida dei presupposti aziendali - Valutazione sulla corrispondenza tra l'uso effettivo dell'applicazione e quello previsto.

La caratteristica fondamentale degli umani è quella di bloccarsi in caso si verifichi un problema di grave entità. Formazione ed esercizio consentono di superare questo istinto naturale ed è per questo motivo che si praticano esercitazioni antincendio e che alcune linee aeree promuovono corsi di sicurezza in caso di incidente. La maggior parte delle grandi aziende investe un importo significativo del proprio budget per la pianificazione del ripristino di emergenza. Per informazioni sulle procedure consigliate, leggere l'articolo relativo all'implementazione IT del ripristino di emergenza nei data center Microsoft.

In questo ambito vengono semplicemente evidenziate le tecniche per velocizzare la risoluzione dei problemi. La consapevolezza che l'applicazione è compilata in modo da semplificare la risoluzione del problemi può ridurre la tensione quando si verifica un problema e diminuire contemporaneamente il tempo necessario per ripristinare l'operatività del sito. L'analisi dei vantaggi in termini di costo determina il livello di tolleranza di errore del sistema. Può essere utile ad esempio valutare il costo aggiuntivo relativo a un backup a caldo fornito da Gestione traffico per ridurre il tempo di inattività.

Gestione traffico di Azure consente di gestire e distribuire il traffico in ingresso nei servizi di Azure ospitati, in esecuzione sia nello stesso data center che in data center diversi in tutto il mondo. Questo componente consente inoltre di configurare un servizio di failover in modo che se si verifica un'interruzione nel servizio principale, il traffico viene inviato al servizio successivo nell'elenco. È disponibile anche software di terze parti, ad esempio Akamai o Limelight, che offre soluzioni di bilanciamento del carico.

Di seguito viene indicato un piano in cinque passaggi per accelerare il processo di risoluzione dei problemi.

Il primo passaggio del piano prevede di rilevare i problemi non appena si verificano. Più rapidamente si rileva un problema, più rapidamente è possibile iniziare a implementare una procedura di emergenza ed è per questo motivo che il monitoraggio è un fattore chiave.

Il secondo passaggio consiste nel rilevare se l'origine del problema risiede nella piattaforma Azure o nell'applicazione. Il primo elemento da esaminare è il dashboard servizi di Azure. Tale sito richiede che si conoscano tutti i servizi usati dall'applicazione e il data center in cui il servizio è distribuito. Viene rilevata solo la riduzione di un servizio che influisce sull'applicazione.

Un modo per monitorare gli eventi dei servizi della piattaforma Azure consiste nell'effettuare una sottoscrizione a tutti i feed RSS per l'applicazione. Se ad esempio l'applicazione era ospitata nel data center degli Stati Uniti centro-settentrionali, è possibile effettuare una sottoscrizione a questo feed RSS.

Archiviazione di Azure usa domini di errore (rack, switch di rete, unità di alimentazione) per limitare l'impatto dei guasti hardware. Secondo un preconcetto comune sull'archiviazione di Azure, per le repliche di dati dell'utente al di fuori di un'unica posizione, ad esempio Stati Uniti centro-meridionali, viene eseguito il failover in un'altra replica. Se si verifica un problema in una determinata posizione, l'accesso ai dati ne risentirà. Nel blog del team di archiviazione vengono forniti tutti i dettagli sulla nuova funzionalità di replica geografica.

Il terzo passaggio prevede la localizzazione del problema. Questo passaggio è probabilmente quello più difficile in un'applicazione complessa che usa più servizi di Azure. La creazione di un servizio senza stato consente di isolare le parti diverse dell'applicazione. Se tutti i servizi dipendenti sono in esecuzione normalmente, è necessario determinare l'integrità dei servizi di calcolo in uso. A tale scopo, nel portale di gestione aprire la sezione Servizi ospitati, account di archiviazione e CDN e scegliere la distribuzione desiderata. Nella finestra delle proprietà vengono visualizzate informazioni analoghe alle seguenti:

Microsoft Azure - Proprietà di distribuzione

In questo caso è possibile notare che negli ultimi otto giorni la distribuzione dell'utente è stata eseguita regolarmente come evidenziato dall'intervallo di tempo trascorso tra l'ora di completamento dell'ultima operazione e l'ultimo aggiornamento. Se invece si nota che la distribuzione si è interrotta o è stata riavviata di recente, è possibile determinare con precisione il punto in cui iniziare a cercare. Se tale punto sembra essere un evento di un servizio che influisce su tutta la distribuzione in un data center specifico, contattare immediatamente Microsoft al numero (866) 676-6546.

Il quarto passaggio consiste nell'eseguire operazioni standard di risoluzione dei problemi, ad esempio la verifica dei file di log o dei registri eventi, il collegamento di un debugger o l'uso di strumenti diversi, come Procmon o Network Monitor, per capire se è possibile trovare indicazioni del problema. Il primo elemento da esaminare in una distribuzione di servizi ospitati di Azure è il registro eventi dell'applicazione. Verificare che non siano presenti eccezioni generate dall'applicazione. Questa verifica può sembrare non necessaria perché attualmente tutto il supporto è gratuito, ma spesso è possibile trovare e risolvere i problemi più rapidamente di un tecnico specializzato Microsoft che non conosce l'intero ambito dell'applicazione. Se l'imperativo è l'operatività del sito, eseguire una ricerca preliminare è l'alternativa migliore.

Il quinto passaggio prevede di contattare il supporto Microsoft. Per velocizzare la risoluzione del problema, è necessario fornire l'ID federato (Windows Live ID) associato al proprietario dell'account della sottoscrizione. Tale ID è l'indirizzo e-mail usato per accedere al portale per i clienti di Microsoft Online Services per gestire le proprie sottoscrizioni. È necessario inoltre fornire il risultato dell'analisi eseguita sull'origine del problema e gli errori presenti nei file di log diversi. Il tecnico del supporto Microsoft può richiedere di essere aggiunto come co-amministratore della sottoscrizione in modo da visualizzare il portale di gestione esattamente come l'utente.

Le prestazioni vengono valutate a seconda dell'osservatore. Qual è la soglia oltre la quale le prestazioni diventano inaccettabili? Come si stabilisce il periodo di timeout di una pagina? Anche se si stabilisce un tempo di caricamento massimo, non è possibile garantire che le pagine verranno caricate per tutti clienti. Il routing DNS e l'affidabilità di rete sono due fattori fondamentali per stabilire i tempi di caricamento delle pagine. Può verificarsi ad esempio il caso in cui il provider di servizi Internet di un cliente di Memphis (Tennessee) invia prima a San Antonio (Texas) il traffico diretto a Chicago. In Microsoft Online Services è disponibile uno strumento per la valutazione delle prestazioni che consente di misurare i tempi di risposta, la larghezza di banda e la qualità complessiva della connessione. Se si desidera visualizzare la latenza tra i diversi data center di Microsoft, è possibile usare le statistiche di Azure di Matthew Rosoff.

Una discussione dettagliata delle prestazioni non rientra nell'ambito del presente documento. Per procedure consigliate per lo sviluppo di Azure, vedere l'articolo sulla guida relativa all'elasticità e alle prestazioni di SQL Azure sul sito TechNet. Prima di avviare una procedura di risoluzione dei problemi sulle prestazioni, è necessario stabilire una linea di base. Per questo motivo la raccolta di dati sulle prestazioni su un lungo periodo di tempo è un aspetto fondamentale. Una volta stabilita la linea di base, è possibile rilevare tendenze e anomalie.

Nella piattaforma Azure sono disponibili contratti di servizio che definiscono i livelli di disponibilità e di connettività per i diversi servizi. Cosa sono i contratti di servizio? Può accadere che il provider di servizi Internet comunichi all'utente che non può usare a livello aziendale la connessione di cui dispone perché il pacchetto acquistato non prevede un contratto di servizio. L'affidabilità è analoga alle prestazioni in quanto dipende in modo significativo dalla connessione di rete sottostante del cliente e può variare a seconda dell'osservatore. I collegamenti indicati in precedenza forniscono informazioni sulle prestazione della connessione di rete di cui si dispone.

Spesso si ritiene erroneamente che i contratti di servizio della piattaforma Azure garantiscano gli stessi livelli di servizio anche all'applicazione. Innanzitutto, alcuni utenti non leggono la frase che afferma:

Per il calcolo, Microsoft garantisce che, quando si distribuiscono due o più istanze di ruolo in domini di errore e di aggiornamento diversi, i ruoli con connessione Internet disporranno di connettività esterna per almeno il 99,95% del tempo.

In questa frase manca un qualificatore aggiuntivo di due parole: "due o più istanze di ruolo per ruolo". In altre parole, se si dispone di un ruolo Web e di un ruolo di lavoro, ciascuno con un'istanza, l'applicazione non sarà disponibile ogni volta che viene eseguito un aggiornamento del sistema operativo host o che viene eseguita una riparazione del sistema. Il servizio di calcolo di Azure usa domini di errore per garantire l'ottemperanza al contratto di servizio.

Un altro preconcetto è legato al fatto che se si sceglie una versione di un sistema operativo specifica, l'aggiornamento del sistema operativo non provocherà alcuna interruzione. Questa condizione è vera per i sistemi operativi guest in esecuzione nell'istanza, ma non lo è per il sistema operativo host installato nel computer fisico in esecuzione nel data center.

Per ottimizzare l'affidabilità, è necessario monitorare il sito sia internamente tramite i dati di Diagnostica Windows Azure che esternamente tramite gli strumenti AzureCheck di Apica, Gomez di Compuware o Pingdom. È inoltre necessario verificare di disporre delle patch di sicurezza più recenti e di aver definito un piano per la verifica delle modifiche del codice.

Quando si crea una nuova applicazione con Visual Studio, il comportamento predefinito prevede di impostare la versione del sistema operativo guest nel file ServiceConfiguration.cscfg in modo analogo al seguente:

osFamily="1" osVersion="*"

Questa è una buona opzione perché l'utente riceverà gli aggiornamenti automatici, aspetto che rappresenta uno dei vantaggi chiave delle strutture PaaS. L'opzione è poco meno che ottima perché non si usa la versione del sistema operativo più recente. Per usare la versione del sistema operativo più recente (Windows Server 2008 R2), l'impostazione deve essere analoga alla seguente:

osFamily="2" osVersion="*"

Sfortunatamente, molti clienti decidono di fermarsi a una versione particolare del sistema operativo nella speranza di aumentare il tempo di attività evitando gli aggiornamenti del sistema operativo guest. Questa è una strategia ragionevole solo per i clienti aziendali che eseguono sistematicamente il test di ogni aggiornamento nell'ambiente di gestione temporanea e quindi pianificano uno scambio di indirizzo VIP per le applicazioni di importanza cruciale in fase di produzione. Per tutti gli utenti che non eseguono il test di ogni aggiornamento del sistema operativo guest, la mancata configurazione degli aggiornamenti automatici comporta rischi per l'applicazione Azure.

Qual è il piano da seguire quando è necessario aggiornare il servizio, soprattutto in caso di emergenza? Questo passaggio, spesso ignorato, può rappresentare la differenza tra la condizione di inattività del sito e la possibilità di affrontare un problema di entità minore nell'ambiente di gestione temporanea. Mentre per la pianificazione iniziale di un'applicazione Azure e il successivo rilascio viene in genere spesa una notevole quantità di tempo e di energia, molte volte si presuppone che operazioni di test estese non siano necessarie per gli aggiornamenti perché la soglia per la correzione di una modifica è minore rispetto a un prodotto preconfezionato. Sebbene le regressioni possano essere corrette rapidamente, sfortunatamente possono anche causare problemi estremamente gravi.

Ogni modifica a un'applicazione in produzione deve essere testata prima della distribuzione definitiva. Considerate le possibili conseguenze di un errore, il maggior tempo speso è un buon investimento. Per altre informazioni, leggere la pagina relativa alla panoramica dell'aggiornamento di un servizio di Azure.

Grazie per il tempo dedicato alla lettura degli argomenti discussi nel presente documento. Sono graditi commenti e suggerimenti sui consigli adatti alle vostre esigenze. Il costo correlato al servizio inattivo deve essere valutato in relazione al costo della raccolta di dati di diagnostica e il calcolo deve essere effettuato prima della distribuzione in produzione. Il lavoro necessario per sviluppare applicazioni Azure affidabili non è nuovo né rivoluzionario né impegnativo dal punto di vista tecnico, ma richiede semplicemente che progettisti e sviluppatori prendano in considerazione i potenziali problemi che possono verificarsi nelle applicazioni e applichino le procedure consigliate nel presente documento.

  • Christian, Tom, "Help with Azure role stuck in Initializing/Busy/Stopped state", Blog, 25 febbraio 2011.

  • Cross, Andy, "Tracing to Azure Compute Emulator SDK V1.3", Blog, 22 gennaio 2011.

  • Haley, Jason, "How To: Query Azure Log Tables with LINQPad", Blog, 28 gennaio 2010 - 15.09.

  • Hardin, David, "Configuring WAD via the diagnostics.wadcfg Config File", Blog, 29 marzo 2011.

  • Kelly, Mike, "Take Control of Logging and Tracing in Azure", MSDN Magazine, giugno 2010.

  • Mackenzie, Neil, "Custom Diagnostics in Azure", Blog, 8 dicembre 2009.

  • Makogon, David, "Azure Tip of the Day: Separate Diagnostic Storage Account", Blog, 15 agosto 2010.

  • Marx, Steve, "Capturing Filtered Windows Events with Azure Diagnostics", Blog, 21 aprile 2010.

  • Mladenov, Toddy, "Collecting Event Logs in Azure", Blog, 2 maggio 2010.

  • Myers, Walter, "Setting Up Performance Counters In Your Azure Web and Worker Roles", Blog, 31 gennaio 2011.

  • Nakashima, Jim, "Using IntelliTrace to debug Azure Cloud Services", Blog, 7 giugno 2010.

  • O’Neil, Jim, "500 and Other Errors in Azure Deployments Blog", Blog, 11 aprile 2011 - 4.47

  • Stiefel, Michael, "Why Did My Azure Application Crash? Using the Azure Diagnostics API to Find Code Problems", Blog, 8 settembre 2011.

  • Washam, Michael, "Managing Log Files with Azure PowerShell Cmdlets 2.0", Blog, 20 settembre 2011.

  • Williamson, Kevin, " Azure Role Architecture", Blog, 5 maggio 2011.

  • Portale di gestione di Azure http://manage.windowsazure.com.

  • Corso di formazione per la piattaforma Azure - Esercizio 3 - Monitoraggio di applicazioni in Azure.

  • Portale di Azure http://www.microsoft.com/windowsazure/

 

Windows Azure

Cluster logico di computer che forniscono un ambiente di esecuzione dei ruoli in una macchina virtuale.

FREB

Traccia delle richieste non riuscite, in precedenza Failed Request Buffering (buffering delle richieste non riuscite)

Portale di gestione

Il portale di gestione di Azure è un portale di amministrazione per la gestione, la distribuzione e il monitoraggio dei servizi Azure. L'indirizzo di accesso al portale di gestione è http://manage.windowsazure.com.

REST

Acronimo di REpresentational State Transfer, una modalità di progettazione software che usa un'architettura client-server senza stato in cui i servizi Web vengono visualizzati come risorse e possono essere identificati dai relativi URL.

SLA

Contratto di servizio

Macchina virtuale

Emulazione software di un computer che esegue una partizione isolata di un computer reale.

WAD

Diagnostica di Azure

Ruolo Web

Un ruolo Web è un ruolo personalizzato per la programmazione di applicazioni Web come supportate da IIS 7 e da ASP.NET.

Ruolo di lavoro

Un ruolo di lavoro è utile per lo sviluppo generalizzato e consente di eseguire attività di elaborazione in background per un ruolo Web.

Questa appendice contiene il codice necessario per configurare Diagnostica di Azure. Il metodo RoleEntryPoint.OnStart viene chiamato per dare l'opportunità di personalizzare l'avvio dell'istanza del ruolo. È possibile fornire una propria implementazione di OnStart per eseguire il codice necessario per configurare WAD per il ruolo.

public override bool OnStart()
{
    string sSource = "WaAppAgent";
    string sEvent = null;

    try
    {
        DiagnosticMonitorConfiguration config = DiagnosticMonitor.GetDefaultInitialConfiguration();

        // Set an overall quota of 8GB.
        config.OverallQuotaInMB = 8192;

        // Set the sub-quotas and make sure it is less than the OverallQuotaInMB set above
        config.Logs.BufferQuotaInMB = 1024;
        config.Directories.BufferQuotaInMB = 0; // Use the rest of the storage here
        config.WindowsEventLog.BufferQuotaInMB = 1024;
        config.PerformanceCounters.BufferQuotaInMB = 1024;
        config.DiagnosticInfrastructureLogs.BufferQuotaInMB = 1024;

        // Get ScheduledTransferPeriod setting from ServiceConfiguration.cscfg and then set it 
        var myScheduledTransferPeriod = RoleEnvironment.GetConfigurationSettingValue("ScheduledTransferPeriod");
        TimeSpan myTimeSpan = TimeSpan.FromMinutes(Convert.ToDouble(myScheduledTransferPeriod));
        config.Logs.ScheduledTransferPeriod = myTimeSpan;
        config.Directories.ScheduledTransferPeriod = myTimeSpan;
        config.WindowsEventLog.ScheduledTransferPeriod = myTimeSpan;
        config.PerformanceCounters.ScheduledTransferPeriod = myTimeSpan;
        config.DiagnosticInfrastructureLogs.ScheduledTransferPeriod = myTimeSpan;

        // Get LogLevelFilter setting from ServiceConfiguration.cscfg and then set it
        var LogLevelFilter = RoleEnvironment.GetConfigurationSettingValue("LogLevelFilter");
        var myLogLevel = LogLevel.Undefined;
        switch (LogLevelFilter)
        {
            case ("Information"):
                myLogLevel = LogLevel.Information;
                break;
            case ("Verbose"):
                myLogLevel = LogLevel.Verbose;
                break;
            case ("Warning"):
                myLogLevel = LogLevel.Warning;
                break;
            case ("Critical"):
                myLogLevel = LogLevel.Critical;
                break;
            case ("Error"):
                myLogLevel = LogLevel.Error;
                break;
            default:
                break;
        } 

        // Filter what will be sent to persistent storage.
        config.Logs.ScheduledTransferLogLevelFilter = myLogLevel;
        config.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter = myLogLevel;
        config.WindowsEventLog.ScheduledTransferLogLevelFilter = myLogLevel;

        // Add in configuration settings for Windows Event logs
        config.WindowsEventLog.DataSources.Add("Application!*");
        config.WindowsEventLog.DataSources.Add("System!*");

        // Add a custom directory transfer
        DirectoryConfiguration directoryConfiguration = new DirectoryConfiguration();
        directoryConfiguration.Container = "wad-custom-logs";
        directoryConfiguration.DirectoryQuotaInMB = 0;
        directoryConfiguration.Path = @"c:\logs";
        config.Directories.DataSources.Add(directoryConfiguration);
 

        // Enable full crash dump collection.
        CrashDumps.EnableCollection(true);

        // Use 30 seconds for the perf counter sample rate.
        TimeSpan perfSampleRate = TimeSpan.FromSeconds(30D);

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Memory\Available Bytes",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Processor(_Total)\% Processor Time",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(w3wp)\% Processor Time",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(w3wp)\Private Bytes",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(w3wp)\Thread Count",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR Interop(_Global_)\# of marshalling",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
             CounterSpecifier = @"\.NET CLR Jit(_Global_)\% Time in Jit",
             SampleRate = perfSampleRate
         });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR Loading(_Global_)\% Time Loading",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR LocksAndThreads(_Global_)\Contention Rate / sec",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR Memory(_Global_)\# Bytes in all Heaps",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR Networking(_Global_)\Connections Established",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR Remoting(_Global_)\Remote Calls/sec",
            SampleRate = perfSampleRate
        });

        // Apply the updated configuration to the diagnostic monitor.
        // The first parameter is for the connection string configuration setting.
        DiagnosticMonitor.Start("Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString", config);

        sEvent = "Management OnStart called diagnostics";
        EventLog.WriteEntry(sSource, sEvent, EventLogEntryType. Information, 0);
    }
    catch (Exception e)
    {
        sEvent = "Management OnStart Event: " + e.Message;
        EventLog.WriteEntry(sSource, sEvent, EventLogEntryType.Error, 0);
    }

    return base.OnStart();
}

Questa appendice contiene il codice necessario per configurare Diagnostica di Azure in un ruolo di lavoro.

public override bool OnStart()
{
    // Set the maximum number of concurrent connections 
    ServicePointManager.DefaultConnectionLimit = 12;
    string sSource = "WaAppAgent";
    string sEvent = "WorkerRole OnStart Event: ";

    try
    {
        // For information on handling configuration changes
        // see the MSDN topic at http://go.microsoft.com/fwlink/?LinkId=166357.

        DiagnosticMonitorConfiguration config = DiagnosticMonitor.GetDefaultInitialConfiguration();

        // Set an overall quota of 8GB.
        config.OverallQuotaInMB = 8192;
        // Set the sub-quotas and make sure it is less than the OverallQuotaInMB set above
        config.Logs.BufferQuotaInMB = 1024;
        config.Directories.BufferQuotaInMB = 0; // Use the rest of the storage here
        config.WindowsEventLog.BufferQuotaInMB = 1024;
        config.PerformanceCounters.BufferQuotaInMB = 1024;
        config.DiagnosticInfrastructureLogs.BufferQuotaInMB = 1024;

        // Get ScheduledTransferPeriod setting from ServiceConfiguration.cscfg and then set it 
        var myScheduledTransferPeriod = RoleEnvironment.GetConfigurationSettingValue("ScheduledTransferPeriod");
        TimeSpan myTimeSpan = TimeSpan.FromMinutes(Convert.ToDouble(myScheduledTransferPeriod));
        config.Logs.ScheduledTransferPeriod = myTimeSpan;
        config.Directories.ScheduledTransferPeriod = myTimeSpan;
        config.WindowsEventLog.ScheduledTransferPeriod = myTimeSpan;
        config.PerformanceCounters.ScheduledTransferPeriod = myTimeSpan;
        config.DiagnosticInfrastructureLogs.ScheduledTransferPeriod = myTimeSpan;

        // Get LogLevelFilter setting from ServiceConfiguration.cscfg and then set it
        var LogLevelFilter = RoleEnvironment.GetConfigurationSettingValue("LogLevelFilter");
        var myLogLevel = LogLevel.Undefined;
        switch (LogLevelFilter)
        {
            case ("Information"):
                myLogLevel = LogLevel.Information;
                break;
            case ("Verbose"):
                myLogLevel = LogLevel.Verbose;
                break;
            case ("Warning"):
                myLogLevel = LogLevel.Warning;
                break;
            case ("Critical"):
                myLogLevel = LogLevel.Critical;
                break;
            case ("Error"):
                myLogLevel = LogLevel.Error;
                break;
            default:
                break;
        }

        // Filter what will be sent to persistent storage.
        config.Logs.ScheduledTransferLogLevelFilter = myLogLevel;
        config.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter = myLogLevel;
        config.WindowsEventLog.ScheduledTransferLogLevelFilter = myLogLevel;

        // Add in configuration settings for Windows Event logs
        config.WindowsEventLog.DataSources.Add("Application!*");
        config.WindowsEventLog.DataSources.Add("System!*");

        // Add a custom directory transfer
        DirectoryConfiguration directoryConfiguration = new DirectoryConfiguration();
        directoryConfiguration.Container = "wad-custom-logs";
        directoryConfiguration.DirectoryQuotaInMB = 0;
        directoryConfiguration.Path = @"c:\logs";
        config.Directories.DataSources.Add(directoryConfiguration);

        // Enable full crash dump collection.
        CrashDumps.EnableCollection(true);

        // Use 30 seconds for the perf counter sample rate.
        TimeSpan perfSampleRate = TimeSpan.FromSeconds(30D);

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Memory\Available Bytes",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Processor(_Total)\% Processor Time",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(WaWorkerHost)\% Processor Time",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(WaWorkerHost)\Private Bytes",
            SampleRate = perfSampleRate
        }); 
                
        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(WaWorkerHost)\Thread Count",
            SampleRate = perfSampleRate
        });

        // Apply the updated configuration to the diagnostic monitor.
        // The first parameter is for the connection string configuration setting.
        DiagnosticMonitor.Start("Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString", config);

    }
    catch (Exception e)  
        {
                sEvent += e.Message;
                EventLog.WriteEntry(sSource, sEvent, EventLogEntryType.Error, 0);
        } 
            
    return base.OnStart();   
}

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="Windows_Azure_Full_Diagnostics" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="WebRole1">
    <Sites>
      <Site name="Web">
        <Bindings>
          <Binding name="Endpoint1" endpointName="Endpoint1" />
        </Bindings>
      </Site>
    </Sites>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="http" port="8080" />
    </Endpoints>
    <Imports>
      <Import moduleName="Diagnostics" />
      <Import moduleName="RemoteAccess" />
      <Import moduleName="RemoteForwarder" />
    </Imports>
    <ConfigurationSettings>
      <Setting name="ScheduledTransferPeriod" />
      <Setting name="LogLevelFilter" />
    </ConfigurationSettings>
    <LocalResources>
      <LocalStorage name="DiagnosticStore" cleanOnRoleRecycle="false" sizeInMB="8192" />
    </LocalResources>
  </WebRole>
  <WorkerRole name="WorkerRole1" vmsize="Small">
    <Imports>
      <Import moduleName="Diagnostics" />
      <Import moduleName="RemoteAccess" />
    </Imports>
    <LocalResources>
      <LocalStorage name="DiagnosticStore" sizeInMB="8192" cleanOnRoleRecycle="false" />
    </LocalResources>
    <ConfigurationSettings>
      <Setting name="ScheduledTransferPeriod" />
      <Setting name="LogLevelFilter" />
    </ConfigurationSettings>
  </WorkerRole>
</ServiceDefinition>

noteNota
Questo file di configurazione è per uso locale con l'emulatore di calcolo.

<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName="Windows_Azure_Full_Diagnostics" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osFamily="2" osVersion="*">
  <Role name="WebRole1">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="ScheduledTransferPeriod" value="1" />
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
      <Setting name="LogLevelFilter" value="Verbose" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.Enabled" value="true" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountUsername" value="me" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountEncryptedPassword" value="MIIBnQYJKoZIhvcNAQcDoIIBjjCCAYoCAQAxggFOMIIBSgIBADAyMB4xHDAaBgNVBAMME1dpbmRvd3MgQXp1cmUgVG9vbHMCEDra5x6UQkuIRHdUChkiglEwDQYJKoZIhvcNAQEBBQAEggEAp8ADE0ov0pKTFo6V1AI94NmsUr8YcQ/dl4M63zbBQkrjSvqqzgofMcMwxYVO8gTwmr3eXawTNp2fbPdN68ZynNgRwEHBm67QP3y6lcAFvx8Amxvp8GZ6qxpAYGE8LhpqBNzoel55mot6IZg0I3qfXtl6SHyfLcyGuPv3nDEzhuYGuPSFR+UF82G2ZK0omLzSuI3KQcbFyTxaUYDIu/fSNOkHVOWwgpNND3SIvg+nSHfS38w+nskAA7bo7oN06LnC+3lLNRrpoKsPBaqogqfyhTkivc3+AJoQ6UAHIyyAJU6kfp4iP7gMl0ZU1mLVeqX5oDwmywf9FGRf7vSn2uEfiTAzBgkqhkiG9w0BBwEwFAYIKoZIhvcNAwcECAw305eQdOSogBA6i8i7rTruZOxAadm1g545" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountExpiration" value="2011-12-31T23:59:59.0000000-05:00" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteForwarder.Enabled" value="true" />
    </ConfigurationSettings>
    <Certificates>
      <Certificate name="Microsoft.WindowsAzure.Plugins.RemoteAccess.PasswordEncryption" thumbprint="D91092F38C839BE56787A0528591E49510FCC711" thumbprintAlgorithm="sha1" />
    </Certificates>
  </Role>
  <Role name="WorkerRole1">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
      <Setting name="ScheduledTransferPeriod" value="1" />
      <Setting name="LogLevelFilter" value="Verbose" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.Enabled" value="true" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountUsername" value="me" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountEncryptedPassword" value="MIIBnQYJKoZIhvcNAQcDoIIBjjCCAYoCAQAxggFOMIIBSgIBADAyMB4xHDAaBgNVBAMME1dpbmRvd3MgQXp1cmUgVG9vbHMCEDra5x6UQkuIRHdUChkiglEwDQYJKoZIhvcNAQEBBQAEggEAp8ADE0ov0pKTFo6V1AI94NmsUr8YcQ/dl4M63zbBQkrjSvqqzgofMcMwxYVO8gTwmr3eXawTNp2fbPdN68ZynNgRwEHBm67QP3y6lcAFvx8Amxvp8GZ6qxpAYGE8LhpqBNzoel55mot6IZg0I3qfXtl6SHyfLcyGuPv3nDEzhuYGuPSFR+UF82G2ZK0omLzSuI3KQcbFyTxaUYDIu/fSNOkHVOWwgpNND3SIvg+nSHfS38w+nskAA7bo7oN06LnC+3lLNRrpoKsPBaqogqfyhTkivc3+AJoQ6UAHIyyAJU6kfp4iP7gMl0ZU1mLVeqX5oDwmywf9FGRf7vSn2uEfiTAzBgkqhkiG9w0BBwEwFAYIKoZIhvcNAwcECAw305eQdOSogBA6i8i7rTruZOxAadm1g545" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountExpiration" value="2011-12-31T23:59:59.0000000-05:00" />
    </ConfigurationSettings>
    <Certificates>
      <Certificate name="Microsoft.WindowsAzure.Plugins.RemoteAccess.PasswordEncryption" thumbprint="D91092F38C839BE56787A0528591E49510FCC711" thumbprintAlgorithm="sha1" />
    </Certificates>
  </Role>
</ServiceConfiguration>

Esempio di un file diagnostics.wadcfg per un ruolo Web.

<?xml version="1.0" encoding="utf-8" ?>
<DiagnosticMonitorConfiguration xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration"
      configurationChangePollInterval="PT1M"
      overallQuotaInMB="4096">
  <DiagnosticInfrastructureLogs bufferQuotaInMB="0"
     scheduledTransferLogLevelFilter="Verbose"
     scheduledTransferPeriod="PT1M" />
  <Logs bufferQuotaInMB="0"
     scheduledTransferLogLevelFilter="Verbose"
     scheduledTransferPeriod="PT1M" />
  <Directories bufferQuotaInMB="0"
     scheduledTransferPeriod="PT1M">

    <!-- These three elements specify the special directories 
           that are set up for the log types -->
    <CrashDumps container="wad-crash-dumps" directoryQuotaInMB="0" />
    <FailedRequestLogs container="wad-frq" directoryQuotaInMB="0" />
    <IISLogs container="wad-iis" directoryQuotaInMB="0" />
  </Directories>

  <PerformanceCounters bufferQuotaInMB="0" scheduledTransferPeriod="PT1M">
    <!-- The counter specifier is in the same format as the imperative 
           diagnostics configuration API -->
    <PerformanceCounterConfiguration counterSpecifier="\Memory\Available Bytes" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\Processor(_Total)\% Processor Time" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\Process(w3wp)\% Processor Time" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\Process(w3wp)\Private Bytes" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\Process(w3wp)\Thread Count" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Interop(_Global_)\# of marshalling" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Loading(_Global_)\% Time Loading" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR LocksAndThreads(_Global_)\Contention Rate / sec" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Memory(_Global_)\# Bytes in all Heaps" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Networking(_Global_)\Connections Established" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Remoting(_Global_)\Remote Calls/sec" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Jit(_Global_)\% Time in Jit" sampleRate="PT30S" />
  </PerformanceCounters>
  <WindowsEventLog bufferQuotaInMB="0"
     scheduledTransferLogLevelFilter="Verbose"
     scheduledTransferPeriod="PT1M">
    <!-- The event log name is in the same format as the imperative 
           diagnostics configuration API -->
    <DataSource name="Application!*" />
    <DataSource name="System!*" />
  </WindowsEventLog>
</DiagnosticMonitorConfiguration>

Configurazione predefinita scritta per l'oggetto BLOB wad-control-container.

<?xml version="1.0"?>
<ConfigRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <DataSources>
    <OverallQuotaInMB>4080</OverallQuotaInMB>
    <Logs>
      <BufferQuotaInMB>0</BufferQuotaInMB>
      <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes>
      <ScheduledTransferLogLevelFilter>Undefined</ScheduledTransferLogLevelFilter>
    </Logs>
    <DiagnosticInfrastructureLogs>
      <BufferQuotaInMB>0</BufferQuotaInMB>
      <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes>
      <ScheduledTransferLogLevelFilter>Undefined</ScheduledTransferLogLevelFilter>
    </DiagnosticInfrastructureLogs>
    <PerformanceCounters>
      <BufferQuotaInMB>0</BufferQuotaInMB>
      <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes>
      <Subscriptions />
    </PerformanceCounters>
    <WindowsEventLog>
      <BufferQuotaInMB>0</BufferQuotaInMB>
      <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes>
      <Subscriptions />
      <ScheduledTransferLogLevelFilter>Undefined</ScheduledTransferLogLevelFilter>
    </WindowsEventLog>
    <Directories>
      <BufferQuotaInMB>0</BufferQuotaInMB>
      <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes>
      <Subscriptions>
        <DirectoryConfiguration>
          <Path>C:\Users\me\AppData\Local\dftmp\Resources\c95f5289-7d10-4bff-b105-198904c9ad93\directory\DiagnosticStore\FailedReqLogFiles</Path>
          <Container>wad-iis-failedreqlogfiles</Container>
          <DirectoryQuotaInMB>1024</DirectoryQuotaInMB>
        </DirectoryConfiguration>
        <DirectoryConfiguration>
          <Path>C:\Users\me\AppData\Local\dftmp\Resources\c95f5289-7d10-4bff-b105-198904c9ad93\directory\DiagnosticStore\LogFiles</Path>
          <Container>wad-iis-logfiles</Container>
          <DirectoryQuotaInMB>1024</DirectoryQuotaInMB>
        </DirectoryConfiguration>
        <DirectoryConfiguration>
          <Path>C:\Users\me\AppData\Local\dftmp\Resources\c95f5289-7d10-4bff-b105-198904c9ad93\directory\DiagnosticStore\CrashDumps</Path>
          <Container>wad-crash-dumps</Container>
          <DirectoryQuotaInMB>1024</DirectoryQuotaInMB>
        </DirectoryConfiguration>
      </Subscriptions>
    </Directories>
  </DataSources>
  <IsDefault>true</IsDefault>
</ConfigRequest>

Microsoft sta conducendo un sondaggio in linea per comprendere l'opinione degli utenti in merito al sito Web di MSDN. Se si sceglie di partecipare, quando si lascia il sito Web di MSDN verrà visualizzato il sondaggio in linea.

Si desidera partecipare?
Mostra:
© 2014 Microsoft