Panoramica della diagnostica di Windows Azure 1.4
Articolo originale pubblicato mercoledì 24 agosto 2011
So che sono stati pubblicati numerosi post e articoli sull'uso della diagnostica in Windows Azure. Questo aspetto è stato in realtà un problema quando mi sono messo a spulciare tutto ciò che era stato pubblicato di recente. Ho trovato molti articoli diversi, divisi per varie versioni di Azure, pertanto ho impiegato molto tempo a capire cosa avrebbe funzionato con l'ultimo SDK (1.4) di Azure. Questo post mira a unire i diversi punti di vista sull'uso della diagnostica di Azure con la versione 1.4 dell'SDK.
Come probabilmente sapete, Azure include un listener di traccia incorporato che implementa i comandi Trace.* (ad esempio Trace.Write, Trace.WriteLine, Trace.TraceInformation e così via) e li memorizza. È tuttavia necessario spostarlo dalla memoria nell'archivio permanente. Per questo scopo potreste avviare un trasferimento manuale di dati o configurare una pianificazione su cui basare i trasferimenti. Potete anche scegliere di spostare informazioni dai registri eventi, acquisire dati dai contatori delle prestazioni, nonché spostare registri IIS e registri personalizzati.
In aggiunta a tutti gli strumenti comuni di registrazione e debug quali quelli menzionati in precedenza, potete anche configurare la distribuzione in modo che consenta la connessione RDP al server Azure che ospita l'applicazione e di abilitare IntelliTrace per il debug e la risoluzione dei problemi limitati per un'applicazione distribuita. Esaminiamo queste diverse parti.
Potete configurare agevolmente i diversi componenti diagnostici, ad esempio la frequenza di salvataggio in modo permanente dei dati nell'archivio, la quantità di spazio di archiviazione da allocare, quali contatori delle prestazioni da acquisire e così via, creando stringhe di codice nel file WebRole.cs incluso in un'applicazione Azure con ruolo Web standard (e penso che la maggior parte delle caratteristiche Azure, ad eccezione del ruolo VM, abbiano qualcosa di analogo a una classe WebRole, come il file WorkerRole.cs con un progetto di ruolo di lavoro). Prima di iniziare a esaminare il codice, dovete aprire il progetto di ruolo di Azure e selezionare la casella di controllo “Specificare le credenziali dell'account di archiviazione per i risultati di diagnostica:” nella scheda Configurazione. Utilizzate il pulsante di selezione per selezionare un account di archiviazione in Azure. Non utilizzate lo sviluppo locale. In questo modo nel progetto verrà salvata una nuova stringa di connessione denominata Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString.
Osserviamo ora l'intero blocco di codice nella classe WebRole e successivamente esaminerò alcuni aspetti specifici:
public override bool OnStart()
{
// For information on handling configuration changes
// see the MSDN topic at https://go.microsoft.com/fwlink/?LinkId=166357.
try
{
//initialize the settings framework
Microsoft.WindowsAzure.CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSetter) =>
{
configSetter(RoleEnvironment.GetConfigurationSettingValue(configName));
});
//get the storage account using the default Diag connection string
CloudStorageAccount cs =
CloudStorageAccount.FromConfigurationSetting(
"Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString");
//get the diag manager
RoleInstanceDiagnosticManager dm = cs.CreateRoleInstanceDiagnosticManager(
RoleEnvironment.DeploymentId,
RoleEnvironment.CurrentRoleInstance.Role.Name,
RoleEnvironment.CurrentRoleInstance.Id);
//get the current configuration
DiagnosticMonitorConfiguration dc = dm.GetCurrentConfiguration();
//if that failed, get the values from config file
if (dc == null)
dc = DiagnosticMonitor.GetDefaultInitialConfiguration();
//Windows Azure Logs
dc.Logs.BufferQuotaInMB = 10;
dc.Logs.ScheduledTransferLogLevelFilter = LogLevel.Verbose;
dc.Logs.ScheduledTransferPeriod = TimeSpan.FromMinutes(5);
//Windows Event Logs
dc.WindowsEventLog.BufferQuotaInMB = 10;
dc.WindowsEventLog.DataSources.Add("System!*");
dc.WindowsEventLog.DataSources.Add("Application!*");
dc.WindowsEventLog.ScheduledTransferPeriod = TimeSpan.FromMinutes(15);
//Performance Counters
dc.PerformanceCounters.BufferQuotaInMB = 10;
PerformanceCounterConfiguration perfConfig =
new PerformanceCounterConfiguration();
perfConfig.CounterSpecifier = @"\Processor(_Total)\% Processor Time";
perfConfig.SampleRate = System.TimeSpan.FromSeconds(60);
dc.PerformanceCounters.DataSources.Add(perfConfig);
dc.PerformanceCounters.ScheduledTransferPeriod = TimeSpan.FromMinutes(10);
//Failed Request Logs
dc.Directories.BufferQuotaInMB = 10;
dc.Directories.ScheduledTransferPeriod = TimeSpan.FromMinutes(30);
//Infrastructure Logs
dc.DiagnosticInfrastructureLogs.BufferQuotaInMB = 10;
dc.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter =
LogLevel.Verbose;
dc.DiagnosticInfrastructureLogs.ScheduledTransferPeriod =
TimeSpan.FromMinutes(60);
//Crash Dumps
CrashDumps.EnableCollection(true);
//overall quota; must be larger than the sum of all items
dc.OverallQuotaInMB = 5000;
//save the configuration
dm.SetCurrentConfiguration(dc);
}
catch (Exception ex)
{
System.Diagnostics.Trace.Write(ex.Message);
}
return base.OnStart();
}
Esaminiamo ora il codice in maggior dettaglio. Inizio ottenendo il valore della stringa di connessione utilizzata per la diagnostica, in modo da potermi connettere all'account di archiviazione utilizzato. Tale account viene quindi utilizzato per individuare la classe di configurazione per il monitor di diagnostica. A questo punto possono iniziare a configurare i vari componenti di registrazione.
Nei registri di Windows Azure vengono salvate tutte le chiamate a Trace.*. Io li configuro per contenere fino a 10 MB di dati nella tabella utilizzata e per salvare in modo permanente le scrittura nella tabella ogni 5 minuti, poiché le scritture dettagliate sono più voluminose. Per un elenco di tutte le diverse tabelle e code utilizzate da Windows Azure per archiviare questi dati di registrazione, consultate questa pagina https://msdn.microsoft.com/en-us/library/hh180875.aspx e quest'altra https://msdn.microsoft.com/en-us/library/microsoft.windowsazure.diagnostics.diagnosticmonitorconfiguration.aspx. I registri dell'infrastruttura e i registri diagnostici sono praticamente identici.
Per le voci del visualizzatore eventi devo aggiungere ogni registro che desidero acquisire all'elenco di origini dati per la classe WindowsEventLog. I valori che posso specificare sono Application!* , System!* o UserData!* . Le altre proprietà corrispondono a quelle descritte per i registri di Windows Azure.
Per i contatori delle prestazioni, dovete descrivere quali contatori desiderate acquisire e con quale frequenza devono campionare i dati. Nell'esempio precedente ho aggiunto un contatore per ogni CPU e l'ho configurato per campionare i dati ogni 60 secondi.
Le ultime operazioni che ho eseguito sono state abilitare l'acquisizione dei dump di arresto anomalo del sistema, modificare la quota generale per tutti i dati di registrazione impostandola su 5 GB circa e infine salvare le modifiche. È molto importante aumentare la quota generale, altrimenti è probabile che venga generata un'eccezione per uno spazio di archiviazione insufficiente per eseguire le modifiche descritte sopra. Finora 5 GB mi sembrano un valore appropriato, ma ovviamente dipende dai casi.
A questo punto siamo pronti per pubblicare l'applicazione. Quando pubblicate l'applicazione da Visual Studio, dovete tenere presente alcuni aspetti:
Nella finestra di dialogo Impostazioni di pubblicazione dovete selezionare la casella Abilita IntelliTrace. Ne parlerò più approfonditamente in seguito. Vi consiglio inoltre di fare clic sul collegamento Configura connessioni Desktop remoto, poiché in alcuni casi questo si è rivelato l'unico modo per risolvere un problema. Poiché la documentazione su Desktop remoto è diventata un po' datata, vi suggerisco di utilizzare questa finestra di dialogo anziché modificare manualmente i file di configurazione. Viene visualizzata una finestra di dialogo simile alla seguente:
Gli aspetti principali da notare in questo caso sono i seguenti:
- Potete utilizzare senza problemi qualsiasi certificato per il quale disponete di un file PFX. Tenete presente che dovete assolutamente caricare questo certificato nel servizio ospitato prima di pubblicare l'applicazione.
- Nel campo Nome utente potete specificare qualsiasi nome, verrà creato un account locale con tale nome utente e password.
Completate ora entrambe le finestre di dialogo e pubblicate l'applicazione. Accedete una volta all'applicazione per attivarla e verificare che il codice del vostro ruolo Web venga eseguito correttamente. A questo punto dovreste essere in grado di esaminare le impostazioni diagnostiche per l'applicazione e osservare le personalizzazioni implementate, come illustrato qui (NOTA: sto utilizzando gli strumenti gratuiti CodePlex per la gestione di Azure che possono essere scaricati dal sito https://wapmmc.codeplex.com/):
Dopo aver eseguito il codice e aver aspettato il successivo periodo di trasferimento pianificato per i registri di Windows Azure, posso vedere le mie chiamate a Trace.* visualizzate in WADLogsTable come mostrato di seguito:
Poiché ho configurato il supporto di RDP nell'applicazione, quando faccio clic sul ruolo Web, l'opzione che consente di stabilire una connessione RDP viene abilitata nella barra degli strumenti in Azure Developer Portal:
Ora ho a disposizione tutti i registri e le tracce dell'applicazione e posso stabilire una connessione RDP ai server per ulteriori indagini. L'altra fantastica caratteristica che ho abilitato è IntelliSense. Descrivere IntelliSense non rientra nell'ambito di questo post, ma potete trovare eccellenti informazioni in proposito in questa pagina https://blogs.msdn.com/b/jnak/archive/2010/06/07/using-intellitrace-to-debug-windows-azure-cloud-services.aspx e in quest'altra https://blogs.msdn.com/b/ianhu/archive/2010/03/16/intellitrace-what-we-collect.aspx. Se IntelliTrace è abilitato, risulta quando visualizzo il servizio ospitato in Esplora server di Visual Studio:
Posso quindi fare clic con il pulsante destro del mouse su un'istanza nell'applicazione e scegliere la voce di menu Visualizza log IntelliTrace. In questo modo vengono scaricati i registri IntelliTrace da Azure e vengono aperti in Visual Studio, come mostrato di seguito:
Come potete notare dall'immagine, posso vedere i thread che sono stati utilizzati, eventuali eccezioni, System Info, i moduli caricati e così via. Ho simulato un'eccezione per verificare questo aspetto impostando l'allocazione complessiva di spazio di archiviazione per le informazioni diagnostiche su 5 MB. Ricorderete che vi ho indicato che è necessario uno spazio molto maggiore, intorno ai 5 GB. Ho apportato la modifica, pubblicato l'applicazione e alcuni minuti dopo ho scaricato i registri IntelliTrace. Chiaramente ho trovato l'errore evidenziato nella seconda pagina dei registri:
Ecco a voi una buona panoramica della diagnostica in Windows Azure 1.4. In questo modo stiamo acquisendo eventi di traccia, registri eventi, contatori delle prestazioni, registri IIS, dump di arresto anomalo del sistema e qualsiasi file di registro diagnostico personalizzato. Se necessario, posso stabilire una connessione RDP al server per altre opzioni di risoluzione dei problemi. Posso scaricare i registri IntelliTrace dall'applicazione e avere un'esperienza di debug limitata nell'istanza locale di Visual Studio 2010.
Questo è un post di blog localizzato. L'articolo originale è disponibile in Windows Azure 1.4 Diagnostics All Up Overview