Share via


Visão geral completa dos diagnósticos do Windows Azure 1.4

Artigo original publicado quarta-feira, dia 24 de agosto de 2011

Sei que há várias postagens e artigos sobre como usar os diagnósticos no Windows Azure. Isso, na verdade, foi parte do problema quando tentei precisar os detalhes do que havia sido disponibilizado recentemente. Encontrei muitos artigos diferentes, mas espalhados em muitas versões diferentes do Azure e, por isso, demorava muito para descobrir o que funcionaria com a versão mais recente do SDK do Azure (1.4). Portanto, esta postagem reunirá os principais pontos para o uso dos diagnósticos do Azure com a versão 1.4 do SDK.

 

Para começar, como muitos de vocês provavelmente sabem, o Azure inclui uma escuta de rastreamento integrada que pegará seus comandos Trace.* (como Trace.Write, Trace.WriteLine, Trace.TraceInformation etc.) e os armazenará na memória. No entanto, você precisa “fazer algo” para movê-los da memória para o armazenamento persistente. Esse "algo" pode ser uma transferência manual dos dados ou a configuração de uma agenda para as transferências. Além disso, também é possível escolher mover informações dos logs de evento, capturar contadores de desempenho, mover logs de IIS e também logs personalizados.

 

Além das ferramentas típicas de registro em log e de depuração mencionadas acima, é possível configurar suas implantações a fim de permitir a aplicação do RDP no servidor do Azure que está hospedando seu aplicativo e ativar o IntelliTrace para depuração limitada e solução de problemas em um aplicativo implantado. Vamos analisar cada uma dessas opções.

 

Para configurar os diferentes componentes de diagnóstico, como a frequência de persistência dos dados no armazenamento, quanto armazenamento deve ser alocado, quais contadores de perfmon capturar etc., basta escrever um código no arquivo WebRole.cs que acompanha um aplicativo Web Role Azure padrão (e eu acredito que a maioria dos recursos do Azure, além da função de VM, tem algo análogo a uma classe WebRole, como o arquivo WorkerRole.cs com um projeto Worker Role). Antes de partirmos para o código, acesse seu projeto Azure Role e marque a caixa na guia Configuração que mostra “Especificar as credenciais da conta de armazenamento para os resultados do Diagnóstico:”. Use o botão seletor para selecionar uma conta de armazenamento que você tenha no Azure; não use desenvolvimento local. Isso salvará uma nova cadeia de conexão no projeto chamada Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString.

 

Agora vamos analisar todo o bloco de código na classe web role e, em seguida, dividir algumas partes específicas:

 

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

}

 

Agora, vamos analisar o código com um pouco mais de detalhes. Começo obtendo o valor da cadeia de conexão usada para o diagnóstico, de modo que eu possa me conectar à conta de armazenamento que está sendo usada. Essa conta de armazenamento é usada para começar a considerar a classe de configuração do monitor de diagnóstico. Depois disso, posso começar a configurar os diversos componentes de registro em log.

 

O Windows Azure Logs é onde todas as chamadas de Trace.* são salvas. Eu o configuro para armazenar até 10 MB de dados na tabela usada e para persistir gravações na tabela a cada cinco minutos, pois todas as gravações Detalhadas são maiores. A propósito, para obter uma lista de tabelas e filas diferentes usadas pelo Windows Azure para armazenar esses dados de log, acesse – https://msdn.microsoft.com/pt-br/library/hh180875.aspx  – e acesse – https://msdn.microsoft.com/pt-br/library/microsoft.windowsazure.diagnostics.diagnosticmonitorconfiguration.aspx Os logs de Infraestrutura e os logs de Diagnóstico são praticamente idênticos.

 

Para as entradas do visualizador de eventos, preciso adicionar cada log que desejo capturar à lista de DataSources para a classe WindowsEventLog. Os valores que posso fornecer são Application!* , System!* ou UserData!* . As outras propriedades são as mesmas descritas para o Windows Azure Logs.

 

Para os contadores de perfmon, você precisa descrever quais contadores deseja capturar e com que frequência eles devem realizar uma amostragem de dados. No exemplo acima, adicionei um contador para CPU e o configurei para realizar uma amostragem de dados a cada 60 segundos.

 

Por fim, minhas últimas ações foram habilitar a captura de despejos de memória, mudar a cota geral de todos os dados de registro em log para aproximadamente 5 GB e salvar as alterações. É muito importante que você aumente a cota geral ou causará uma exceção afirmando que não há espaço de armazenamento suficiente disponível para fazer as alterações descritas acima. Até o momento, 5 GB parece um valor seguro, mas é claro que seu raio de ação pode variar.

 

Pronto, agora é hora de publicar o aplicativo. Ao publicar o aplicativo a partir do Visual Studio, há algumas outras coisas a serem observadas:

 

 

Na caixa de diálogo Publicar configurações, marque a caixa para Habilitar IntelliTrace; explicarei mais sobre isso posteriormente. Além disso, eu recomendaria clicar no link para Configurar as conexões da área de trabalho remota…; em alguns momentos, eu percebi que essa é a única maneira de solucionar um problema. Como a documentação sobre área de trabalho remota ficou um pouco desatualizada, deixe-me sugerir que você use essa caixa de diálogo em vez de editar manualmente os arquivos de configuração. Ela mostra uma caixa de diálogo parecida com a seguinte:

 

 

As principais coisas a serem observadas aqui são:

  1. Aparentemente, você pode usar qualquer certificado para o qual tenha um arquivo PFX. Observe que você DEVE carregar esse certificado em seu serviço hospedado antes de publicar o aplicativo.
  2. O campo Nome de usuário pode receber o que você quiser; uma conta local com esse nome de usuário e senha será criada.

 

Complete as duas caixas de diálogo e publique seu aplicativo. Acesse seu aplicativo uma vez para iniciá-lo e certifique-se de que seu código de web role seja executado. Depois de fazer isso, será possível examinar as configurações de diagnóstico do aplicativo e ver suas personalizações implementadas, conforme aparece aqui (OBSERVAÇÃO: estou usando as ferramentas gratuitas do CodePlex para gerenciar o Azure. É possível baixá-las em https://wapmmc.codeplex.com/):

 

 

Após a execução de uma parte do código, e eu ter aguardado até o próximo Período de transferência agendado para o Windows Azure Logs, posso ver minhas chamadas de Trace.* em WADLogsTable, como mostra o seguinte:

 

 

Além disso, como eu configurei o suporte para RDP em meu aplicativo, quando clico na web role, a opção de estabelecer uma conexão RDP com ela é habilitada na barra de ferramentas no Azure Developer Portal:

 

 

Portanto, tenho todos os logs e rastreamentos de meu aplicativo disponíveis agora e posso aplicar o RDP nos servidores se precisar investigar mais. Outro recurso interessante que habilitei foi o IntelliSense. Descrever o IntelliSense está além do escopo desta postagem, mas é possível encontrar ótimas informações sobre ele aqui https://blogs.msdn.com/b/jnak/archive/2010/06/07/using-intellitrace-to-debug-windows-azure-cloud-services.aspx e aqui https://blogs.msdn.com/b/ianhu/archive/2010/03/16/intellitrace-what-we-collect.aspx Quando o IntelliTrace é habilitado, ele avisa quando visualizo meu serviço hospedado no Visual Studio Server Explorer:

 

 

Em seguida, posso clicar com o botão direito do mouse em uma instância em meu aplicativo e seleciono o item de menu Visualizar os logs do IntelliTrace. Isso baixa os logs do IntelliTrace do Azure e os abre no Visual Studio, com a seguinte aparência:

 

 

Como você pode ver na imagem, posso ver os threads que foram usados, quaisquer exceções emitidas, Informações do sistema, os módulos carregados etc. Simulei uma exceção para testar isso configurando minha alocação de armazenamento geral para informações de diagnóstico para 5 MB. Talvez você se lembre de que mencionei a necessidade de algo em torno de 5 GB. Fiz a alteração e publiquei meu aplicativo e, após alguns minutos, baixei os logs do IntelliTrace. Com certeza encontrei o erro destacado aqui na segunda página de logs:

 

 

Portanto, aí está – uma boa visão geral dos diagnósticos no Windows Azure 1.4. Estamos capturando eventos de rastreamento, logs de evento, contadores de desempenho, logs de IIS, despejos de memória e quaisquer arquivos de log de diagnóstico personalizado. Posso aplicar o RDP no servidor para obter soluções adicionais de problema, se for necessário. Posso baixar os logs do IntelliTrace a partir de meu aplicativo e ter uma experiência de depuração limitada em minha instância local do Visual Studio 2010.

Esta é uma postagem de blog traduzida. Encontre o artigo original em Windows Azure 1.4 Diagnostics All Up Overview