Este artigo foi traduzido por máquina.

Diagnóstico de nuvem

Assuma o controle do registro em log e do rastreamento no Windows Azure

Mike Kelly

Baixe o código de exemplo

Como muitos programadores, quando comecei a escrita de código usei as instruções de impressão para depuração. Não sei como usar um depurador e as instruções de impressão foram um bruto, mas foi executado de maneira eficaz para ver como ele estava fazendo meu programa. Posteriormente, aprendeu a usar um depurador de real e descartado as instruções de impressão como uma ferramenta de depuração.

Avançar para quando comecei a escrever código que é executado em servidores. Descobri que aqueles imprimir demonstrativos Ir agora sob mais sofisticados do título de “ log e rastreamento, ” técnicas essenciais para qualquer programador de aplicativo do servidor.

Mesmo que você pode anexar um depurador a um aplicativo de servidor de produção — não que muitas vezes é possível devido a restrições de segurança em computadores que hospeda o aplicativo — os tipos de problemas de aplicativos de servidor deparar não são facilmente revelaram com depuradores tradicionais. Muitos aplicativos de servidor distribuídos, que executam o em várias máquinas, e depuração que está acontecendo em uma única máquina nem sempre é suficiente para diagnosticar problemas do mundo real.

Além disso, os aplicativos de servidor geralmente são executados sob o controle de uma equipe de operações não teria idéia de como usar um depurador tradicional — e a chamada de um desenvolvedor para cada problema não é desejável ou prático.

Este artigo explicarei básico algum registro em log, rastreamento e depuração técnicas usadas para aplicativos de servidor. Em seguida, vai me aprofundar em como essas técnicas podem ser empregadas para projetos Windows Azure. Ao longo do processo você verá como o registro em log e rastreamento são usados com alguns aplicativos do mundo real e mostrarei como usar o Windows PowerShell para gerenciar o diagnóstico de um serviço em execução.

Uma estratégia de registro em log

O ideal é que qualquer aplicativo do servidor — e basicamente qualquer aplicativo da Web, inclusive aqueles em execução sob Windows Azure — tem um registro em log e rastreamento de estratégia projetados no desde o início. As informações de registro devem ser robustas o suficiente para descrever a quase tudo o que está acontecendo em cada componente. No entanto, assim como aqueles imprimir demonstrativos, adicionei a Meus programas primeiro podem produzir um lote de saída, então, muito possível o log. O rastreamento de log bem projetado e, portanto, inclui maneiras de ajustar o volume de log a partir de qualquer componente e o tipo. Isso permite que desenvolvedores concentrar-se em um determinado componente com comportamento inadequado e equipe operacional talvez até mesmo em um determinado computador obter mais informações sobre 
what exatamente do acontecendo dentro dele — sem gerar uma grande quantidade de ruído no log que pode ser distração e talvez lento ao aplicativo significativamente.

Além disso, como aplicativos de servidor de aplicativos distribuídos com freqüência, as informações devem ser coletadas e agregadas de várias máquinas (talvez em funções diferentes do aplicativo) para obter uma imagem completa do que estava acontecendo em quando um determinado problema. Portanto, uma maneira de identificar um thread de transação por meio das máquinas é importante, permitindo a agregação após o fato.

Os logs disponíveis no Windows Azure amadureceu com as versões CTP (Community Technology Preview). O registro inicial não era muito mais sofisticado do que uma instrução de impressão capturada como texto em um armazenamento de tabela Azure do Windows. Windows Azure começando com a versão PDC09, começou a oferecer um log muito mais completo e uma infra-estrutura de rastreamento, com base na estrutura do evento de rastreamento para Windows (ETW).

Essa estrutura ETW é compatível com asp.net por meio de classes no namespace System. Diagnostics. O namespace Microsoft.WindowsAzure.Diagnostics, que herda do e estende o padrão de classes de System. Diagnostics, permite o uso de System. Diagnostics, como uma estrutura de log no ambiente Windows Azure. A Figura 1 mostra como o ETW foi implementado pela Azure o diagnóstico do Windows.

A Figura 1 Visão geral de alto nível do Windows diagnóstico Azure

ETW fornece um modelo em que os logs de código para um ou mais TraceSources. O nível de log permitido por meio de cada fonte é controlado por um SourceSwitch. Por sua vez, fontes estão conectados aos consumidores uma ou mais que manter o registro de informações de maneiras diferentes.

Windows Azure fornece um padrão de consumidor ou de escuta para manter as informações de registro em log gerar tanto para o armazenamento de tabela Windows Azure ou blob de armazenamento. Você também pode escrever seu próprios consumidor se você deseja fazer algo diferente com os dados do evento, ou usar um consumidor disponíveis no mercado (embora algumas talvez precisem ser modificadas para trabalhar no ambiente Windows Azure).

A estrutura do ETW associa um TraceEventType cada evento, conforme mostrado no do Figura 2. As primeiras linhas de cinco gravidade são os valores usados com mais freqüência e elas indicam a importância relativa da saída do rastreamento. Observe que os tipos de transferência, Suspend e resume são usados pelo Windows Communication Foundation (WCF).

A Figura 2 de tipos de eventos de rastreamento

TraceEventType	Valor	Significado
Crítica	0x0001	Erro fatal ou aplicativo falhar
Erro	0x0002	Erro recuperável
Aviso	0x0004	Problema de não-crítico — pode ser uma indicação de problemas mais graves por vir
Informações	0X0008	Mensagem informativa
Modo detalhado	0x0010	Rastreamento de depuração (como, por exemplo, informações de fluxo de execução detalhado, parâmetros e assim por diante)
Iniciar	0x0100	Iniciando uma operação lógica
Parar	0x0200	Interromper uma operação lógica
Suspender	0x0400	Suspensão de uma operação lógica
Currículo	0x0800	Retomar uma operação lógica
Transferir	0x1000	Transferir para uma nova atividade

Se você estiver procurando apenas coisas muito grave, você vai querer ter certeza de que capturar crítica e, provavelmente, os valores de erro. Se você quiser muitas informações sobre o que está acontecendo, procure em tudo, acima de modo detalhado.

Sua estratégia de log deve incluir a consistência no uso do tipo de evento e entradas de log copious com os valores ainda mais para baixo na hierarquia. Ele deve ser possível praticamente siga o fluxo de execução do seu aplicativo, se o registro para todos os valores realçados é ativado em seu aplicativo. Isso pode ser inestimável na solução de problemas de erros ou problemas na produção.

Você pode ligar ouvintes, fontes e opções para habilitar diferentes níveis de saída por meio de programação, mas isso geralmente é feito por meio de arquivos de configuração. Você pode configurar a saída no arquivo app. config (para as funções de trabalho do Windows Azure) ou Web. config (para as funções do Windows Azure em inglês). No entanto, como explicarei em detalhes posteriormente neste artigo, colocar isso em ServiceConfiguration.cscfg permite ajustar log e rastreamento opções enquanto estiver executando o serviço Windows Azure, sem precisar reimplantar todas as atualizações para a execução de código ou mesmo interromper o serviço. Windows Azure também expõe uma interface RESTful para permitir que o controle sobre algumas opções de log remotamente. O Windows PowerShell pode fazer com que usa o RESTful interface.

O log, rastreamento e saída de depuração

Os termos de log, rastreamento e depuração de saída pode às vezes, ser intercambiáveis. Neste artigo, vou para distinguir entre quatro tipos diferentes de possível o que geralmente ser chamado de diagnosticoutput no seu código. Esses aproximadamente são ordenados do mais detalhada para o menos detalhado.

• Saída de depuração: Estas são informações que aparece apenas em compilações de depuração do seu aplicativo e são excluídas no momento da compilação de compilações de versão (com base no que se o símbolo de pré-processador DEBUG está definido no momento da compilação, que define do Visual Studio, por padrão somente em compilações de depuração). Normalmente, a saída de depuração inclui itens como Asserts Adicionar para ajudar a localizar casos em que código é não obedecer pré-condições esperadas, levando a bugs ou até mesmo despejos de estruturas de dados. Adicionando esses ajuda a depurar algoritmos durante a depuração e testes.
• O rastreamento: Esses são declarações que se destinam a ajudar a controlar o fluxo de controle e o estado do programa enquanto ele está em execução. Imagine que executam um depurador, percorrendo ao longo de código e verificando os valores das variáveis importantes na janela Watch. Instruções de rastreamento destinam-se para replicar essa experiência em casos onde não é possível anexar um depurador. O ideal é que eles devem fornecer suficiente contexto, você pode ver qual caminho é executado em cada ponto de controle no aplicativo e classificação de acompanhar o código depois de ler as instruções de rastreamento. O rastreamento é ativado quando o símbolo de pré-processador TRACE é definido no momento da compilação e pode ser tanto a versão e compilações de depuração. (Por padrão, o Visual Studio define TRACE em depuração e versão compilações, mas você pode obviamente alterá-la.)
• O log de eventos: Esses são declarações que se destinam a capturar eventos importantes no decorrer da execução do aplicativo — por exemplo, o início de uma transação ou a adição de um item a um banco de dados. O log de eventos é diferente de rastreamento que captura de estados principais em vez de fluxo detalhado de controle.
• O log de erros: Estes são casos especiais de log de eventos em que você capture situações excepcionais ou potencialmente perigosas. Os exemplos incluem qualquer exceção identificada; os casos em que você Don conseguir acessar um recurso em outra máquina esperam ser capazes de acessar (e que, naturalmente, seu aplicativo manipulará corretamente, mas gostaria de observar); e os casos em que erros de voltar de APIs do qual você Don espera que erros.

O log de erros também pode ser úteis para a equipe de operações em situações em que ainda não estão ocorrendo problemas mas indicações são de que eles em breve estará — por exemplo, uma cota está se aproximando de seu máximo ou uma transação que está funcionando, mas levando mais tempo do que o normal. Esses tipos de log de eventos podem ajudá-lo as operações de sua equipe proativamente tratar os problemas antes que eles ocorram, evitando tempo de inatividade do aplicativo.

A maioria dos desenvolvedores bom ter chegado usado para incluindo a saída de depuração em seus aplicativos para ajudar a diagnosticar problemas durante o desenvolvimento e muitos desenvolveram algum tipo de solução para o log de erros.

No entanto, você precisa ter certeza de que você está pensando em não apenas a saída de depuração e o erro opções de log, mas também tem uma estratégia sólida de rastreamento e o log de eventos, o que realmente pode ajudar a diagnosticar problemas que ocorrem somente sob cargas estressantes em ambientes de produção.

Além disso, considere cuidadosamente se grande parte o que você agora pensar como saída de depuração em vez disso, não deve estar disponível em lançamento e de depuração e de rastreamento se baseia. Um aplicativo com comportamento inadequado de produção normalmente executando a compilação de lançamento. Se você tiver o rastreamento de instruções presente, mas desativado (conforme explicarei como fazer mais tarde), você pode ativar seletivamente-los para a obtenção de resultados de semelhante a depuração muito avançados da versão de compilação, ajudá-lo a diagnosticar problemas.

Rastreamento e registro no Windows Azure

Você pode usar o log direita fora da caixa de Azure Windows — ele da parte do SDK do Windows de Azure. Há algumas vantagens no uso de uma estrutura de log como Logger.NET, a Enterprise Library, log4net ou Ukadc.Diagnostics. Esses adicionar estrutura adicional às suas mensagens de log e também podem ajudar a fornecer alguns dos configurabilidade mencionada anteriormente. No entanto, a maioria não tenha sido ajustada para funcionar no ambiente Windows Azure e alguns são muito mais do que apenas uma estrutura de log.

O código de exemplo neste artigo, decidi usar apenas o padrão Windows Azure log e rastreamento de APIs com uma camada fina na parte superior para fornecer configuração dinâmica. Você provavelmente será útil criando algumas classes auxiliares e uma estrutura para o registro em log e rastreamento de estratégia de isso ou Assista a outras estruturas fornecer as versões do Windows Azure.

Quando você cria um novo serviço no Azure do Windows usando o Visual Studio, já permitiu fazer log básico. O código de função de trabalho e da função clichê gerado pelos modelos do Windows Azure tem o ouvinte de diagnósticos já configuradas e ativadas.

Para habilitar o log simples em um serviço do Windows Azure, inicie um novo projeto no Visual Studio usando o modelo de serviço do Windows Azure Cloud (Visual c#). Nomeie o projeto. Para o meu exemplo, usei MSDNSampleLoggingService. Clique em OK.

O Assistente de novo projeto de serviços de nuvem será executado. No assistente, adicione uma função de trabalho e a função de uma Web para o projeto. Renomeie a função de operador para LoggingWorkerRole e a função da Web para LoggingWebRole, clique em OK. O Visual Studio criará o projeto.

Neste ponto, você poderá explorar o código gerado. Examine o arquivo app. config no projeto LoggingWorkerRole e observe o código a seguir é exibida:

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

<configuration>

  <system.diagnostics>

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

      <listeners>

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

      </listeners>

    </trace>

  </system.diagnostics>

</configuration>

Isso conecta o Azure padrão do Windows ouvinte de diagnóstico para o seu código, o que significa que qualquer registro em log e rastreamento que você fazem da função de operador será direcionado para o ouvinte de Windows Azure (DiagnosticMonitorTraceListener), a menos que você alterá-la. Você encontrará uma entrada semelhante na Web. config para a função da Web criada para esse serviço.

Se você examinar o arquivo WorkerRole.cs no projeto de função de operador, você também verá essa linha no método OnStart:

DiagnosticMonitor.Start("DiagnosticsConnectionString");

E o método Run, você verá uma chamada de rastreamento:

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

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

Finalmente, se você olhar no arquivo ServiceConfiguration.cscfg na raiz do serviço, você verá essa linha para a função de trabalho e a função da Web:

<Setting name="DiagnosticsConnectionString" 

         value="UseDevelopmentStorage=true" />

Isso indica que o ouvinte Windows Azure qual conta de armazenamento a ser usado para manter o registro em log e informações de rastreamento. Nesse caso, as informações de log serão armazenadas no armazenamento de desenvolvimento em sua máquina local. Alternando isso para uma conta de armazenamento de nuvem Azure do Windows, você pode fazer com que os logs de ir para o armazenamento de nuvem. Aqui está um exemplo do formato para que a partir do código de exemplo fornecido neste artigo:

<Setting name="DiagnosticsConnectionString" 

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

Os valores AccountName e AccountKey precisam ser personalizados para sua conta Azure específica e a chave. Para obter essas informações do portal do armazenamento de conta para o serviço de windows.azure.com. AccountName é a primeira parte da URL para as tabela e o blob de armazenamento pontos de extremidade (a parte antes “. table.core.windows. net ”). AccountKey é codificado em base 64 Primary Key do Access para sua conta de armazenamento.

Observe que, porque não há uma conta de armazenamento distintos usada para fins de diagnóstico, você pode optar por armazenar suas informações de diagnóstico separadas dos dados de aplicativos. Para fazer isso, configure uma conta de armazenamento separado, clicando em novo serviço na página de portal, selecionando o armazenamento de conta e dar a ele um nome (MyAppLogs, por exemplo). Você talvez queira configurar um grupo de afinidade, portanto, o armazenamento de seus logs é na mesma região, como seu serviço.

Agora que você tenha levado um tour rápido do código de rastreamento em Windows Azure services, você pode executar o projeto da função simples que você criou. Observe que o ouvinte padrão fornecido pelo Windows Azure também direciona a saída para a janela de saída no Visual Studio para depuração cria, por isso, você verá OnStart mensagem aparecer na janela de depuração:

Information: LoggingWorkerRole entry point called

E se você deseja examinar os logs, depois que o serviço é executado? Por padrão, o Windows Azure não persiste os logs de armazenamento. Você pode informá-lo para fazê-lo adicionando algumas linhas de código para o método OnStart de sua função:

TimeSpan tsOneMinute = TimeSpan.FromMinutes(1);

DiagnosticMonitorConfiguration dmc =

DiagnosticMonitor.GetDefaultInitialConfiguration();



// Transfer logs to storage every minute

dmc.Logs.ScheduledTransferPeriod = tsOneMinute;

// Transfer verbose, critical, etc. logs

dmc.Logs.ScheduledTransferLogLevelFilter = LogLevel.Verbose;    

// Start up the diagnostic manager with the given configuration

DiagnosticMonitor.Start("DiagnosticsConnectionString", dmc);

Adicionar este código WorkerRole.cs e executar novamente fará com que o Windows Azure para os logs de transferência para o armazenamento de desenvolvimento a cada minuto. Você também pode optar por fazer uma transferência de demanda de logs (consulte o código admin.aspx.cs no meu aplicativo de exemplo de como fazer isso) ou usar os comandos do Windows PowerShell descritos neste artigo. Lembre-se de que depois de você transferir os logs para armazenamento, você será cobrado o espaço de armazenamento e cabe a você para excluir as informações quando ele não é mais necessária.

Depois que você tiver chegado os logs no armazenamento do Windows Azure, você precisará de uma ferramenta para examinar as tabelas de armazenamento para ver os logs. Eu usei o Studio de armazenamento de nuvem do Cerebrata (cerebrata.com). Cerebrata desde então tem surgem com uma ferramenta chamada Gerenciador de diagnóstico Azure e há também ferramentas gratuitas disponíveis no CodePlex (codeplex.com) para observar a nuvem de armazenamento e diagnóstico. Os logs são colocados em uma tabela chamada WADLogsTable, que pode ser visto no do Figura 3.

De logs de persistidas no armazenamento de desenvolvimento, a Figura 3

 

Quando você examinar os logs de armazenamento, você observará algumas coisas. Em primeiro lugar, Windows Azure associa automaticamente algumas informações de cada log de eventos: um carimbo de hora, uma contagem de tiques (que fornece mais detalhadas de temporização com granularidade de 100 nanossegundos) e informações sobre a ocorrência de implantação, a função e a função. Isso permite restringir os logs para instâncias específicas, se você desejar.

Em segundo lugar, há um nível e um Id_evento associados com cada evento. Nível corresponde aos valores do Figura 2 — os eventos de rastreamento registrados como informação terá um valor de nível 4, enquanto aqueles registrados como erro terão um nível 2. Eventos genéricos enviados por meio de Trace.WriteLine (como o código clichê) terá o nível 5 (verbose).

O Id_evento é um valor que você especificar. A chamada de Trace.WriteLine básica mostrada anteriormente não permitirá que você especifique-o; é necessário usar outros métodos de rastreamento para passar o Id_evento.

Ativar seletivamente Tracing e log

Um aplicativo típico consiste em vários componentes de lógicos. Por exemplo, você pode ter um componente de banco de dados que lida com o modelo de dados no armazenamento do Windows Azure. Sua função na Web por sua vez pode ser dividida em um componente administrativo e um componente do usuário (e que podem ser divididos ainda mais em componentes lógicos com base nas necessidades do seu aplicativo).

É possível vincular o registro em log e as opções de rastreamento — o tipo de registro em log está ativado e, em que nível de detalhe – a esses componentes. Isso permite que você ative seletivamente o rastreamento nos componentes para os quais você precisa, evitando muita confusão.

A abordagem de chave aqui é não chamar o traço diretamente, mas usar várias instâncias de TraceSource, normalmente um por espaço para nome. Um TraceSource tem um SourceSwitch associada que controla se a fonte está ativada, bem como o nível de saída for desejado. Importante: os valores de SourceSwitch não estão definidos em tempo de compilação, mas em tempo de execução. Como resultado, pode ativar ou desativar saída de diagnóstico de várias partes do seu aplicativo sem ter que recompilá-lo ou até mesmo reimplantar uma versão diferente.

WorkerDiagnostics.cs e WebDiagnostics.cs contêm a configuração do rastreamento de origens e opções no código de exemplo. Eis um trecho:

// Trace sources

public TraceSource ConfigTrace;

public TraceSource WorkerTrace;

// Add additional sources here



// Corresponding trace switches to control 

// level of output for each source

public SourceSwitch ConfigTraceSwitch { get; set; }

public SourceSwitch WorkerTraceSwitch { get; set; }

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

Em seguida, no arquivo de configuração para sua função, você conectar esses para ouvintes, conforme mostrado na Figura 4 de . Primeiro configura o ouvinte de diagnóstico padrão Windows Azure como ouvinte compartilhado para que ele possa ser referido nos itens de <sources>. Em seguida, configura o duas fontes: uma fonte WorkerTrace e uma fonte ConfigTrace. Ele também define os switches correspondentes para que você possa ajustar o nível de saída. ConfigTrace lhe dá a saída mais detalhada, WorkerTrace lhe erros apenas.

Figura 4 de Configurar fontes de rastreamento e ouvintes

<configuration>

  <system.diagnostics>

    <sharedListeners>

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

        name="AzureDiagnostics">

        <filter type="" />

      </add>

    </sharedListeners>

    <sources>

      <source name="ConfigTrace">

        <listeners>

          <add name="AzureDiagnostics" />

        </listeners>

      </source>

      <source name="WorkerTrace">

        <listeners>

          <add name="AzureDiagnostics" />

        </listeners>

      </source>

    </sources>

    <switches>

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

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

    </switches>

    <trace>

      <listeners>

        <add name="AzureDiagnostics" />

      </listeners>

    </trace>

  </system.diagnostics>

</configuration>

Você Don precise nomear os switches o mesmo que as fontes, mas ele facilita a vida. Se eles não são iguais, você adicionar um atributo de switchName para o elemento de origem para indicar o nome da opção que controla a saída para essa fonte. Isso permite que você compartilhe uma única opção em várias fontes de rastreamento. Observe que os nomes de fonte e a opção de rastreamento diferenciam maiúsculas de minúsculas e devem coincidir exatamente com o caso, que você passa ao construtor no seu código.

Você pode evitar que a opção se você desejar simplesmente adicionando um atributo switchValue o elemento de origem especificando o valor da opção desejada para esta fonte ao mesmo tempo. Os valores de opção que é usar, na verdade, são analisados a partir do arquivo de configuração como um dos SourceLevels definido em Figura 5 , que também mostra como TraceEventType você passar para chamadas de TraceSource interage com o SourceLevel definido para a fonte para determinar o que passa pelo.

De rastreamento TraceEventType e níveis de código-fonte, a Figura 5

Você talvez tenha percebido que a SourceLevel é apenas um bitmask é ANDed em tempo de execução com TraceEventType para determinar se deve registrar o evento. Para obter as combinações como aviso e a atividade de rastreamento, especifique o valor numérico para o bitfield como o valor de opção em vez de usar os valores de simbólicos mostrados.

Além dos switches, uma escuta pode ter TraceFilter, o que adiciona mais sofisticada lógica de tempo de execução como para se uma determinada mensagem é permitida através do. Escrever um personalizado TraceFilter está além do escopo deste artigo, mas você encontrará um exemplo útil na documentação do projeto Ukadc.Diagnostics no CodePlex (ukadcdiagnostics.codeplex.com/wikipage?title=LoggingPrimer).

Alterando o que é registrado em tempo de execução

Esta é a maneira como o padrão que funciona de rastreamento do asp.net e ela funcionará bem com os serviços implantados Azure do Windows. O problema é que você gostaria de poder alterar os valores de opção em tempo de execução e Azure do Windows não permite que você apenas substitua o arquivo app. config ou Web. config sem reimplantar o serviço. A solução genérica do asp.net para que isso é usar WebConfiguationManager para alterar valores de configuração, mas Windows Azure atualmente não permite que você faça isso para os serviços implantados de nuvem, tanto.

A solução é espelhar os valores para essas opções em ServiceConfiguration.cscfg. Windows Azure permite editar esse arquivo (ou carregar um novo) por meio do portal de desenvolvimento enquanto o serviço está sendo executado. Você terá de escrever um código adicional para que isso funcione, porém.

O código padrão do System. Diagnostics sabe sobre as configurações apenas no arquivo app. config ou Web. config, mas suas funções terá tempo de execução de notificação de alterações no ServiceConfiguration.cscfg através dos eventos RoleEnvironmentChanging e RoleEnvironmentChanged. Você pode decidir se reciclar (reiniciar), em seguida, a função ou simplesmente atualizar o valor de configuração. O segundo é o que você deseja para opções de rastreamento. Reiniciando a função pode ser que problemas intermitentes desapareça. O código de exemplo deste artigo mostra como fazer isso, a adição de alguns dos valores ServiceConfiguration.cscfg (Observe que você tenha também editar ServiceDefinition.csdef, que fornece o esquema) e adicionar algum código para suas funções.

Estrutura de desenvolvimento de teste

Que tal testes na estrutura de desenvolvimento, onde você Don tiver o portal Azure do Windows para editar a configuração, como você faz para os serviços implantados de nuvem? Primeiro, determine a implantação do que ID do Windows Azure tenha atribuído ao seu serviço de estrutura de desenvolvimento em execução. Você pode ver, mostrando a estrutura de desenvolvimento da interface do usuário da bandeja do sistema enquanto o serviço está sendo executado. Esse será um número como 177.

1. Vá para o diretório onde seus binários de serviço tiverem sido colocados por compilação — geralmente \bin\debug ou \bin\release em seu código de serviço. Você encontrará a cópia do ServiceConfiguration.cscfg foi criado quando você criou o aplicativo.
2. Em seguida, usando um editor de texto, edite esse arquivo para usar a opção de rastreamento que você deseja. Por exemplo, no código de exemplo, altere WebTrace desativado de modo detalhado.
3. Em seguida, em um prompt de comando do SDK do Windows Azure (Iniciar | todos os programas | SDK do Windows Azure V1. 1 | prompt de comando do Windows Azure SDK), execute este comando:

csrun /update:NNN;ServiceConfiguration.cscfg

NNN é a identificação de implantação do Windows Azure você encontrou anteriormente. Isso fará a estrutura de desenvolvimento que clicar no botão de configurar o portal de desenvolvimento Windows Azure faz para os serviços implantados de nuvem, atualize as definições de configuração e acionar os eventos.

Outras informações de diagnóstico

Embora este artigo se concentrou em dados tabulares que seus logs de aplicativo usando System. Diagnostics, Windows Azure também possível capturar o IIS registra e Failed Request Tracing (anteriormente conhecido como Falha na solicitação de armazenamento em buffer ou FREB) faz logon, entre outros. Algumas delas são colocadas no armazenamento de blob Azure do Windows, alguns no armazenamento de tabela Azure do Windows. Figura 6 relaciona os logs disponíveis e onde estão armazenados. Observe que para aqueles que não é habilitado por padrão, você geralmente precisa fazer uma alteração no Web. config ou no arquivo app. config para o Windows Azure coletar esses logs. Let’s analisar detalhadamente um exemplo que não são coletado por padrão, para mostrar como isso funciona.

Figura 6 do Opções de log padrão Azure

Tipo de log	Formato de armazenamento Azure do Windows	Coletados por padrão?	Anotações
Logs do Windows Azure gerados a partir do seu código	Tabela	4	Ouvinte de rastreamento deve ser adicionado ao arquivo Web. config ou no arquivo app. config, conforme mostrado no exemplo de código. Armazenados em WADLogsTable.
Logs do IIS 7. 0	Blob	4	Somente funções da Web. Armazenado em um recipiente de blob sob o caminho wad-iis-logfiles\ < ID de implantação > \ < nome da função na web > \ < instância de função > \W3SVC1.
Logs de infra-estrutura de diagnóstico do Windows	Tabela	4	Informações sobre o serviço de diagnóstico. Armazenados em WADDiagnosticInfrastructureLogsTable.
Falha na solicitação de logs	Blob		Somente funções da Web. Ative a configuração de opções de rastreamento em configurações de system.WebServer na Web. config. Armazenado em um recipiente de blob sob o caminho wad-iis-failedreqlogfiles\ < ID de implantação > \ < nome da função na web > \ < instância de função > \W3SVC1.
Logs de eventos do Windows	Tabela		Habilite alterando DiagnosticMonitor Configuration.WindowsEventLog durante a configuração de configuração inicial. Armazenados em WADWindowsEventLogsTable. Blog de Steve Marx (blog.smarx.com/posts/capturing-filtered-windows-events-with-windows-azure-diagnostics) explica como usá-lo.
Contadores de desempenho	Tabela		Habilite alterando DiagnosticMonitor Configuration. PerformanceCounters. Armazenados em WADPerformanceCountersTable. O código de exemplo de função de operador define um contador de desempenho.
Despejos de memória	Blob		Habilite chamando CrashDumps.EnableCollection. Armazenado em um recipiente de blob sob os caminho wad--despejos de memória. Porque asp.NET manipula a maioria das exceções, isso geralmente só é útil para uma função de trabalho.
Logs de erro personalizadas	Blob		Além do escopo do artigo, mas consulte blog de Neil Mackenzie (nmackenzie.spaces.live.com/blog/cns!B863FF075995D18A!537.entry) para obter um exemplo útil de como usá-lo.

Por exemplo, let’s veja como habilitar o log de FREB do IIS na sua função na Web. Para ver isso em ação, baixe o código de exemplo para MSDNSampleLoggingService que acompanha este artigo. Abra a Web. config para o LoggingWebRole e localize a seção denominada <system.webServer>. Observe que as linhas mostradas no do Figura 7 foram adicionadas para Web. config padrão Azure do Windows. Isso resulta em falha no registro para todas as solicitações que levam mais tempo do que 15 segundos ou com os códigos de status entre 400 e 599 (o elemento failureDefinitions).

A Figura 7 de Falha na solicitação de registro de LoggingWebRole

<tracing>

  <traceFailedRequests>

    <add path="*">

      <traceAreas>

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

        <add provider="ASPNET" 

             areas="Infrastructure,Module,Page,AppServices"

             verbosity="Verbose" />

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

        <add provider="WWW Server"

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

             verbosity="Verbose" />

      </traceAreas>

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

    </add>

  </traceFailedRequests>

</tracing>

Se você abrir about.aspx.cs no projeto LoggingWebRole, você observará que, no método PageLoad eu acrescentei um atraso arbitrário de 18 segundos com esta linha de código:

System.Threading.Thread.Sleep(18000);

Isso forçará o carregamento dessa página para ser considerado uma solicitação com falha na definição especificada anteriormente.

Para ver o log FREB, reconstrua e implantar o aplicativo na malha de desenvolvimento e, em seguida, localizar o controlador de malha de desenvolvimento na área de notificação da barra de tarefas (talvez seja necessário clicar no botão Mostrar ícones ocultos na barra de tarefas porque ele é normalmente oculto como inativa).Clique com o botão direito-lo e selecione Mostrar UI da estrutura de desenvolvimento.Enquanto seu aplicativo é executado, isso mostrará informações sobre o aplicativo.

Expandir a função da Web e o botão direito do mouse na instância de função (0).Selecione Abrir armazenamento local para abrir a pasta na máquina local em que os logs estão sendo salvos (consulte do Figura 8).Dentro dessa pasta, os logs estão na pasta \directory\DiagnosticStore.Isso ocorre porque a função da Web no código de exemplo é configurada para armazenar informações de diagnóstico no armazenamento de desenvolvimento.Se em vez disso, você deve definir o DiagnosticsConnectionString para uma conta de armazenamento de nuvem, os logs persistentes será no blob de armazenamento associado com uma conta de armazenamento.Você pode usar a nuvem armazenamento Studio para examinar os recipientes de armazenamento de blob para ver os logs.

A Figura 8 do salvos para armazenamento de estrutura de desenvolvimento local de logs de abertura

Gerenciando o diagnóstico de um serviço em execução

Enquanto você profundamente pode instrumentar seu código com registro em log, você normalmente Don quer que todas as informações de log são mantidas no armazenamento durante a execução do seu serviço de produção.Talvez seja necessário apenas o erro e informações críticas para ir para os logs de persistidas enquanto (registradas como as informações ou verbose) de informações mais detalhadas serão suprimidas.

Mas e se ocorrer um problema?Você Don deseja reimplantar uma nova versão do seu serviço ou o problema magicamente pode desaparecer — você provavelmente já sabe como eficaz a reinicialização é possível fazer com que problemas enganosos desaparecem.

Em vez disso, é mais eficaz aumentar a quantidade de informações para as tabelas de log ou blob armazenamento ao mesmo tempo, permitindo o continuar a execução de código com comportamento inadequado.Isso é mais provável revelar a causa do problema em seu aplicativo enquanto ele está funcionando no momento.

Anteriormente, descrevi como ajustar os detalhes do que o log é passado para o diagnóstico do Windows Azure para um determinado TraceSource.Essa é uma espécie de edição upstream dos quais informações são registradas.Nesta seção, mostrarei a você as definições de diagnóstico Windows Azure gerais que determinam como as informações que passam por um TraceSource obtém no armazenamento persistente.

Cmdlets do Windows PowerShell pode gerenciar muitos aspectos de seus serviços do Windows Azure em execução, incluindo diagnósticos.Execute esses da sua máquina local e que se conectam através da Internet aos servidores Windows Azure nuvem que esteja executando o serviço, fornecendo informações e ajustando parâmetros.O Windows PowerShell é instalado com o Windows 7 e pode ser baixado para o Windows Vista em microsoft.com/powershell de .Fazer o download de CmdLets de gerenciamento do Windows Azure Service de code.msdn.microsoft.com/azurecmdlets e siga as instruções para instalá-los.Os comandos de diagnóstico relacionados Windows Azure são mostrados no do Figura 9.

A Figura 9 de de Cmdlets de diagnóstico Azure de gerenciamento do Windows

Nome	Descrição
Get ActiveTransfers	Retorna o conjunto de transferências de diagnóstico ativas com as informações de transferência associadas.
Get CommonConfigurationLogs	Obtém os valores de configuração comum para todos os buffers de log.Isso inclui o intervalo de tempo no quais as alterações de configuração são pesquisou e o tamanho do buffer alocado para logs de memória.
Get DiagnosticAwareRoleInstances	Retorna uma lista das identificações de instâncias de função ativa que têm um monitor de diagnóstico em execução.
Get DiagnosticAwareRoles	Lista o conjunto de funções de ter iniciado com êxito pelo menos um monitor de diagnóstico.
Get DiagnosticConfiguration	Obtém a configuração de buffer para o nome do buffer especificado (logs, diretórios, PerformanceCounters, WindowsEventLogs ou DiagnosticInfrastructureLogs).
Conjunto CommonConfigurationLogs	Define os valores de configuração comum para todos os buffers de log.
Conjunto FileBasedLog	Define a configuração de buffer de logs com base em arquivo.
Conjunto InfrastructureLog	Define a configuração de buffer para os logs gerados pela infra-estrutura subjacente de diagnósticos do Windows Azure.Os logs de infra-estrutura de diagnóstico são úteis para o sistema de diagnósticos para solução de problemas.
Contador de desempenho de conjunto	Define a configuração de buffer de dados do contador de desempenho coletados pelo serviço.
Conjunto WindowsAzureLog	Define a configuração de buffer para Azure básico do Windows registra sendo gerada pelo seu serviço.
Conjunto WindowsEventLog	Define a configuração de buffer para logs de eventos do Windows que está sendo gerada pelo seu serviço.
Início OnDemandTransfer	Inicia uma transferência de demanda do buffer de dados especificado.Isso move os dados para o armazenamento do Windows Azure (armazenamento de uma tabela ou blob).
Stop ActiveTransfer	Paradas de transferência sob demanda ativa, dada uma identificação de transferência.

Por exemplo, para localizar a transferência atual de parâmetros para uma instância de função em particular, passar a identificação de implantação (a partir do portal do desenvolvedor de Windows Azure onde você pode implantar o serviço) e o nome da conta de armazenamento e a chave é usada para DiagnosticsConnectionString no App. config ou Web. config para a função de serviço (consulte do Figura 10).Observe que o Windows PowerShell solicitará que forneça algumas ausência de parâmetros necessários — a instância de função e o nome do buffer que desejo.Os logs é os logs padrão do Windows Azure.O resultado mostra que o nível de filtro é detalhada e uma transferência for agendada a cada minuto.

A Figura 10 do Diagnóstico de configuração para um serviço em execução usando o Windows PowerShell

Para alterar a configuração para essa função, use o cmdlet Set-DiagnosticConfiguration, conforme mostrado no do Figura 11.Observe que eu Alterei o período detransferência de um minuto para dois minutos e o filtro de modo detalhado para erros, o que significa que somente os eventos registrados como crítica e de erros serãoenviados para o armazenamento persistente.

De alteração de configuração de diagnóstico do Windows PowerShell, a Figura 11

Talvez a coisa mais úteis, que você pode fazer remotamente no Windows PowerShell é forçar uma transferência de informações de log imediatamente.A Figura 12 mostra como fazer isso.

A Figura 12 de usar o Windows PowerShell para iniciar uma transferência de logs do IIS

Em primeiro lugar, posso consultar qualquer transferência de demanda existente de logs.Há uma restrição na implementação atual de diagnósticos de Windows Azure que apenas uma demanda de um determinado tipo pode ocorrer a transferência ao mesmo tempo.Vendo que nenhuma está em andamento, posso solicitar um, passando a identificação de implantação do serviço, a função e instância, o tipo de log que deseja transferir e o intervalo de dados para transferir.(Para o tipo de log, diretórios significa logs baseados em arquivo, incluindo os logs do IIS.Os logs seria os logs com base em tabela Windows Azure enviados por meio de TraceSource.)

Eu também passar um nome de fila de notificação, que é onde o diagnóstico do Windows Azure enviará uma notificação de que a transferência for concluída.Através de experimentos, descobri que se eu não passar uma fila de notificação, a transferência parecia não acontecer.Novamente, eu obtenho um GUID que identifica a solicitação de transferência.Eu, em seguida, consultar o status da solicitação e ver o que é publicado, significando que ele está em andamento.

A versão atual de CmdLets de gerenciamento do Windows Azure Service parece que não aparecem quando a solicitação foi concluída, mas se você consultar o blob de armazenamento para o armazenamento de diagnóstico, você verá os logs de pop-up na hierarquia de recipientes, daqui a pouco (ou no armazenamento de tabela Windows Azure) se você solicitou a transferência das informações armazenadas no armazenamento de tabela.

Resumo

Usando uma combinação de ajustando parâmetros de configuração para TraceSources você define no seu código e usando os CmdLets de gerenciamento de serviço do Windows Azure mover as informações no armazenamento persistente, você deve ser capaz de controlar totalmente a saída de diagnóstico que você obtiver de seus serviços do Windows Azure.

Obviamente, o mais importante para solucionar o seu código de produção é desenvolver uma estratégia sólida de diagnóstico de saída no início do desenvolvimento, em seguida, siga essa estratégia em toda a codificação.O uso de TraceSources e as ferramentas Windows Azure fornece para configurar a verbosidade de saída de diagnóstico que flui de seu aplicativo para o armazenamento irá ajudá-lo a aproveitar em que, para obter a quantidade de informações que precisa quando surge um problema.

Não há nada pior do que a sensação de forma que o código que está se comportando de forma incorreta em um servidor é uma caixa preta, opaca para você.Código de diagnóstico sólidas e as ferramentas descritas aqui permitirá que você abra os bastidores da caixa e dentro de mesmo nível.

Mike Kelly* é consultor voltada para o desenvolvimento de software e para ajudar a integrar aquisições para as empresas maiores.Anteriormente trabalhou por 15 anos na Microsoft em uma variedade de funções de desenvolvimento do produto e como diretor de práticas emergentes da equipe Engineering Excellence.Ele pode ser contatado em himself@mikekellyconsulting.com.*

Graças aos seguintes especialistas técnicos para revisar este artigo:  Sumit Mehrotra, Michael Levin e Matthew Kerner da Microsoft, bem como Neil Mackenzie e Steven Nagy