Diagnóstico e logging

Suporte a log na nuvem é uma das maiores preocupações da comunidade de desenvolvimento, com IDE (Integrated Development Enviroment) de alta interatividade como o Visual Studio e runtime como o Framework .NET você pode identificar um problema em seu código mesmo em ambientes de produção locais (on-premise). No entando, o domínio do Visual Studio é limitado para o acesso que ele possui para a runtime de execução.

O Visual Studio se comunica com o ambiente a runtime do ambiente em execução para recuperar dados de debug da aplicação, a aplicação por sua vez, deve ter informações de debug na runtime para o Visual Studio realizar o debug.

A fábrica de implantação do Windows Azure precisa ter acesso o runtime do ambiente local, assim você pode realizar o debug da sua aplicação Windows Azure local, como qualquer outra aplicação .NET adicionando breakpoints (pontos de parada).

Essa seria uma ótima notícia, mas infelizmente o Visual Studio não pode acessar a runtime do Windows Azure diretamente. Uma vez que o serviço é implantado no Windows Azure, ele é totalmente gerenciado pelo Windows Azure e você não tem acesso a runtime dele.  O time de desenvolvimento percebeu essa limitação e acrescentou a capacidade de log para a runtime do Windows Azure, assim como suporte a IntelliTrace (somente disponível no Visual Studio Ultimate edition).

O serviço de diagnóstico é executado ao longo da instância da sua Role, coletando dados de diagnóstico que podem ser salvos utilizando o serviço de armazenamento do Windows Azure (necessita configuração), assim ficando a uma chamada REST de distância. Você pode também comunicar com o serviço de diagnóstico remotamente de uma aplicação local, ou ainda configurar para armazenar os dados de acordo com um período pré-determinado.

Os serviços de diagnósticos suportam realizar log dos os seguintes tipos de dados:

  • Windows Azure Trace logs: Estes são os logs gerados a partir da aplicação, e podem conter qualquer      tipo de mensagem enviado do seu código.
  • Logs de diagnóstico de infraestrutura: logs de infraestrutura recuperados pelo serviço de      diagnósgtico;
  • Logs de eventos do Windows: Estes são os logs de eventos do Windows gerado na máquina que a instância      da Role está executando.
  • Contadores de performance do Windows: Estes se referem aos contadores de performance da máquina que a instância da Role está sendo executada;
  • IIS Logs e trace de falhas de requisições: Logs gerados pelo IIS da instância da Role;
  • Dumps de quebra da aplicação: São os dados de dump gerado quando a aplicação quebra.

O serviço de diagnóstico agrega todos os tipos de logs citados anteriormente juntos e depois os transferem para o local de armazenamento apropriado. Não se esqueça que as instância das roles são stateless e por essa razão, você pode perder dados armazenados localmente durante operação de reciclagem.

 Veja abaixo uma tabela com a lista de dados de log disponíveis nas instâncias das roles do Windows Azure e seus respectivos locais de armazenamento.

 

 Fonte de dados

 Tipo de destino no Windows Azure Storage

 Windows Azure   trace Logs

 Table Storage

 Logs de   diagnóstico de infraestrutura   

 Table Storage

 IIS Logs

 Blog Storage

 Contadores de   performance

 Table Storage

 Windows event log

 Table Storage

 IIS falhas de   requisição

 Blob Storage

 Dumps de quebra de   aplicação

 Blob Storage

 

Habilitando o serviço de diagnóstico em sua aplicação

  1. No arquivo ServiceDefinition.csdef, adicione o elemento import  do módulo de Diagnóstico. Veja exemplo de XML abaixo.

 

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

<ServiceDefinition name="MyHostedService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">

  <WebRole name="WebRole1">

    <Imports>

      <Import moduleName="Diagnostics" />

    </Imports>

  </WebRole>

</ServiceDefinition>

  1. Abra o arquivo ServiceConfiguration.cscfg e adicione as seguintes linhas de código XML.

 

<ConfigurationSettings>

   <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString"

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

</ConfigurationSettings>

Onde AccountName é o nome da conta de armazenamento do Windows Azure, e AccountKey é a chave de acesso da conta de armazenamento. Se você estiver usando o emulador de armazenamento, defina o valor como UseDevelopmentStorage=true

Rastreando o fluxo do seu aplicativo

Se você pretende recuperar as mensagens de trace incluídos no código do seu código, você vai precisar incluir um novo listener (TraceListener) na configuração do seu aplicativo.

Quando é utilizado Trace, Debug e TraceSource, você precisa de um mecanismo para coletar e armazenar as mensagens que são enviadas. As mensagens de Trace são recebidas por listeners, a função de um listener é de coletar, armazenar, e direcionar mensagens de trace. Listeners direcionam a saída do trace para um determinado local, como log, janela, ou ainda um arquivo texto. No Windows Azure Diagnostics, a classe DiagnosticMonitorTraceListener é utilizada, mas antes para utilizá-la é necessário ter habilitado o serviço de diagnóstico do Windows Azure, veja tópico anterior.

Para configurar o listener de trace, realiza a seguinte configuração no seu arquivo Web.config ou App.config.

<system.diagnostics>
   <trace>
      <listeners>
         <add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener,
            Microsoft.WindowsAzure.Diagnostics,
            Version=1.0.0.0,
            Culture=neutral,
            PublicKeyToken=31bf3856ad364e35"
            name="AzureDiagnostics">
            <filter type="" />
         </add>
      </listeners>
   </trace>
</system.diagnostics>

Espero que você tenha compreendido o funcionamento do mecanismo de diagnóstico do Windows Azure, um excelente exercício seria aplicar essas alterações no projeto de migração abordado no módulo 3 do curso de Azure no MVA - Microsoft Virtual Academy.
 

Obrigado,

Vinícius.

Tags:

Follow the Discussion

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.