Exportar (0) Imprimir
Expandir Tudo

Práticas recomendadas de solução de problemas para desenvolver aplicativos do Azure

Atualizado: novembro de 2014

Autor: William Bellamy, Engenheiro de Escalonamento Principal da Microsoft

Colaboradores:

  • Bryan Lamos, Gerente de Programas Sênior da Microsoft, Qualidade do Produto

  • Kevin Williamson, Engenheiro de Escalonamento Sênior da Microsoft, Suporte Developer do Azure

  • Pranay Doshi, Gerente de Programas Sênior da Microsoft, Serviços de Produção do Azure

  • Tom Christian, Engenheiro de Escalonamento Sênior da Microsoft, Suporte Developer do Azure

Data de Publicação: Janeiro de 2012

A prioridade número um da Microsoft é ajudar os clientes do Azure a manter seus aplicativos em funcionamento. Os Contratos de Nível de Serviço do Azure definem uma disponibilidade de 99,95% de conectividade externa, quando duas ou mais instâncias de função forem implantadas. Entretanto, a conectividade externa garante a possibilidade de se alcançar o aplicativo de fora dos data centers da Microsoft, o que não é o mesmo que “site em funcionamento”. A maioria dos serviços do Azure tem diversas dependências: SQL Azure, Cache, Rede de Distribuição de Conteúdo, recursos internos (através do Connect do Azure) e assim por diante. Se alguma destas dependências falhar, o serviço do Azure poderá não funcionar como esperado.

Este documento se foca em diferentes desafios de solução de problemas e abordagens recomendadas para projetar e desenvolver aplicativos com maior suporte para a plataforma do Azure da Microsoft. Quando (e não se) um problema surge, resolver em curto tempo é essencial. O planejamento adequado pode ajudá-lo a encontrar e corrigir os problemas sem a necessidade de entrar em contato com a Microsoft para obter suporte. A abordagem proposta neste documento também acelerará a resolução de problemas que precisam da assistência da Microsoft.

Este documento destina-se a ser um recurso para o público técnico que trabalha com software: projetistas e arquitetos de software, profissionais de TI, integradores de sistemas, desenvolvedores e testadores que projetam, criam e implantam soluções do Azure.

Pressupõe-se que o leitor possui um entendimento básico do ciclo de vida de desenvolvimento de um aplicativo do Azure, incluindo a terminologia e os diversos componentes relativos ao seu ambiente de desenvolvimento e de tempo de execução.

Pressupõe-se também que as diretrizes básicas do Azure são seguidas, tal como usar a última versão do SDK do Azure e testar as alterações de código antes que elas sejam postas em produção.

Este documento está organizado em duas seções:

  • Visão geral dos recursos de diagnóstico do Azure:

    • Recursos do Azure

    • Recursos de terceiros

  • Práticas recomendadas para projeto, desenvolvimento e implantação com suporte:

    • Antes de implantar o aplicativo.

    • Projeto e monitoramento de fail-fast.

    • O que fazer quando surgir um problema.

Nenhum desenvolvedor espera que seu aplicativo falhe depois de ser posto em produção. Fazemos o nosso melhor para testar o código durante o desenvolvimento, para que esteja robusto o suficiente para ser executado sem erros, enquanto damos seguimento ao próximo projeto. Infelizmente, os códigos falham. Em ambientes distribuídos, pequenos erros podem se tornar catastróficos devido às complexidades inerentes ao processo de separação dos componentes do aplicativo. É por isso que uma estratégia de log e rastreamento deve ser projetada no aplicativo desde o começo. De modo ideal, esta estratégia engloba provisões para se ajustar dinamicamente sem a necessidade de recriar/reimplantar o tipo e o volume de logs em um nível de componente. Ter diversos logs não garante uma resolução rápida. Mais não é necessariamente melhor, porque dados em grande quantidade levam mais tempo a serem decifrados e podem desacelerar o desempenho do seu aplicativo. O log ajustável controla tanto o tamanho quanto o custo de armazenamento dos dados de log.

Os aplicativos distribuídos, como aqueles que são executados na Plataforma do Azure, possuem diversos componentes que interagem entre si, quando o usuário interage com o aplicativo. Ao fazer o log do fluxo do seu código de modo consistente e abundante, com cuidado especial para as chamadas a serviços externos, qualquer pessoa será capaz de seguir o fluxo de execução do seu aplicativo. Isso pode ser de grande valor daqui a um ou dois anos, quando surgir um problema na produção. De modo ideal, o nível de log deve ser ajustável a partir do arquivo ServiceConfiguration.cscfg, de modo que ele possa ser alterado sem a necessidade de uma reimplantação.

Convém usar uma compilação de depuração durante o desenvolvimento, a fim de se obter a maior quantidade possível de informações. Geralmente, os desenvolvedores adicionam instruções de depuração e, às vezes, algumas formas de log de erros. O obstáculo é que as instruções de depuração são removidas na compilação de produção, ou seja, você terá dificuldades quando surgir um problema. A maioria dos clientes não vai querer reimplantar o programa com uma compilação de depuração para resolver um problema de produção. Mike Kelly indica quatro tipos de saída de diagnóstico que os desenvolvedores devem configurar:

  • Saída de Depuração – Inclui Declarações somente na compilação de depuração

  • Rastreamento – Rastreia o fluxo de controle durante a execução

  • Log de Eventos – Eventos principais

  • Log de Erros – Situação excepcional ou perigosa

Muitas das mensagens de depuração provavelmente deveriam ser transformadas em instruções de rastreamento, a fim de se tirar vantagem dos seus diferentes níveis de rastreamento. O Diagnóstico do Azure permite também que sejam configurados diagnósticos e desabilitadas as transferências, de modo que seja possível controlar quando as informações são gravadas no armazenamento persistente.

As seguintes seções descrevem alguns dos recursos para resolução de problemas que estão disponíveis para os desenvolvedores que criam aplicativos no Azure.

Antes de explorar o Azure, vamos analisar o atual paradigma de solução de problemas dos aplicativos do Windows Server. Em geral, os desenvolvedores examinam os logs quando surge um problema de produção. Os logs de evento e IIS estão ativos por padrão e não são destruídos quando o sistema é reiniciado (contanto que não haja falha no disco).

Este mesmo processo funcionará em um aplicativo do Azure se a Área de Trabalho Remota estiver habilitada; os desenvolvedores podem se conectar a cada instância para coletar dados de diagnóstico. A coleta pode ser feita copiando-se os logs para o armazenamento ou configurando-se o RDP, de modo que eles possam ser copiados para a máquina local. Este processo é demorado e vai falhar caso a imagem da instância tenha sido recriada, o que causa a execução de uma versão limpa da função Web ou da função de trabalho. Obviamente, esta versão limpa não possui nenhum dos logs anteriores. A imagem poderá ser recriada se houver uma atualização no sistema operacional da máquina virtual host ou convidada. Recriar a imagem é um processo normal da arquitetura do Azure.

O SDK 1.0 original do Azure incluía a funcionalidade para coletar diagnósticos e armazená-los no armazenamento do Azure, coletivamente conhecido como Diagnóstico do Azure (WAD). Este software, criado a partir do framework do ETW (Rastreamento de Eventos para Windows), cumpre com dois requisitos de projeto introduzidos pela arquitetura escalável do Azure:

  1. Salvar os dados de diagnóstico que seriam perdidos quando a imagem da instância é recriada.

  2. Fornecer um repositório central de diversas instâncias para diagnóstico.

O namespace Microsoft.WindowsAzure.Diagnostic é uma extensão do namespace System.Diagnostic, de modo que é possível usar o framework do ETW dentro de um aplicativo do Azure.

Windows Azure - Diagrama de fluxo do diagnóstico

Após incluir o Diagnóstico do Azure na função (ServiceConfiguration.cscfg e ServiceDefinition.csdef), o WAD coletará os dados de diagnóstico de todas as instâncias desta função em particular. É possível usar os dados de diagnóstico para depurar e solucionar problemas, medir o desempenho, monitorar o uso de recursos, fazer a análise de tráfego e o planejamento de capacidade e fazer a auditoria. As transferências para a conta de armazenamento do Azure para persistência podem ser agendadas ou sob demanda.

O Diagnóstico do Azure altera o paradigma do servidor de quatro maneiras importantes:

  1. O diagnóstico deve estar habilitado no momento de criação do aplicativo.

  2. São necessárias ferramentas/etapas específicas para visualizar os resultados do diagnóstico.

  3. As falhas vão causar a perda de dados de diagnóstico, a não ser que eles estejam gravados em um armazenamento durável (no Armazenamento do Azure, em vez de estar em cada instância).

  4. O armazenamento de diagnósticos incorre em um custo mensal, quando feito no armazenamento do Azure.

O custo é de particular importância, porque um dos benefícios-chave da plataforma do Azure é a redução de custos. O único modo de se eliminar o custo de uso do WAD, atualmente, é deixar os dados na máquina virtual. Isso pode funcionar em uma implantação pequena, mas não é prático quando há diversas instâncias. A seguir estão algumas formas para minimizar o impacto financeiro:

  1. Certifique-se de que a conta de armazenamento está no mesmo data center que o aplicativo. Se por alguma razão eles não estiverem no mesmo data center, escolha o intervalo de transferências agendadas cuidadosamente. Transferências com tempos menores aumentarão a relevância dos dados, porém esta troca pode não justificar a largura de banda adicional e a sobrecarga de processamento.

  2. Periodicamente, copie e limpe todos os dados de diagnóstico do Armazenamento do Azure. Os dados de diagnóstico vão passar pelo armazenamento do Azure, mas não permanecer lá desnecessariamente. Há diversas ferramentas para esta tarefa: Pacote de Monitoramento do System Center para Azure, Azure Diagnostics Manager da Cerebrata e cmdlets do PowerShell do Azure.

  3. Escolha somente os dados de diagnóstico que serão necessários para a solução de problemas e monitoramento do seu aplicativo. Capturar dados em excesso pode dificultar a solução de problemas, além de aumentar os custos significativamente.

  4. Controle a coleta e a extensão dos dados de diagnóstico através de implantação de um switch sob demanda no aplicativo.

  5. Use o nível de log (detalhado, informativo, de alerta, de erros) de modo que todas as informações estejam disponíveis. Em seguida, utilize a configuração de pós-implantação do WAD para reunir os dados seletivamente.

O armazenamento do Azure é a base para qualquer aplicativo com suporte. De modo ideal, todo aplicativo deveria ter esta funcionalidade configurada e ativa.

A Análise de Armazenamento do Azure executa logs e fornece dados de métrica para uma conta de armazenamento. É possível usar esses dados para rastrear solicitações, analisar tendências de uso e diagnosticar problemas com a conta de armazenamento.

A chave para escrever códigos com suporte para o SQL Azure é examinar os códigos de retorno e certificar-se de ter um código de repetição sólido para lidar com falhas.

Este Pacote de Monitoramento permite o uso do Operations Manager do Microsoft System Center para monitorar a disponibilidade e o desempenho dos Aplicativos do Azure:

  • Descobre os aplicativos do Azure.

  • Fornece o status para cada instância de função.

  • Coleta e monitora informações de desempenho.

  • Coleta e monitora eventos do Windows.

  • Coleta e monitora as mensagens de rastreamento do .NET Framework para cada instância de função.

  • Limpa o desempenho, eventos e dados de rastreamento do .NET Framework a partir da conta de armazenamento do Azure.

  • Altera a quantidade de instâncias de função.

Usar o Operations Manager 2007 do Microsoft System Center é a melhor maneira de monitorar a integridade de um aplicativo do Azure.

Atualmente, o Azure não fornece uma solução completa para que os clientes monitorem e gerenciem o seu serviço hospedado. Para obter informações de rede, visite o site speedtest.net, que fornece uma ferramenta usada para medir tempos de resposta, largura da banda e a qualidade geral da conexão. Diversas ferramentas são úteis ao trabalhar com o Azure. A lista a seguir não promove nem recomenda nenhuma ferramenta de terceiros em particular.

Cmdlets do PowerShell do Azure

A melhor maneira de gerenciar diagnósticos remotamente é através dos Cmdlets do PowerShell do Azure. Os cmdlets são baseados nas APIs de Diagnóstico e Gerenciamento do Azure e o código-fonte completo está disponível no projeto CodePlex, para proporcionar melhor compreensão das APIs fundamentais. A versão 2.0 possibilita a configuração, o download e a limpeza de todos os aspectos do Diagnóstico do Azure. O blog de Michael Washam dá bons exemplos de scripts.

Monitoramento de Rede: AlertBot, Gomez, Keynote, Pingdom

O Gerenciamento do Desempenho do Aplicativo Gomez da Compuware, o Keynote, o Pingdom e o AlertBot são soluções para monitorar o aplicativo do Azure externamente. Elas possibilitam o monitoramento da disponibilidade do aplicativo e a otimização do desempenho. Alguns serviços, como o Pingdom, possibilitam notificações por email, SMS ou uma nota na área de trabalho, quando for detectado um erro. Este tipo de monitoramento precisa simular o que o usuário final faz, a fim de monitorar com sucesso, porque às vezes uma função web pode exibir a página inicial sem que ela esteja totalmente funcional.

Azure Check

O AzureCheck da Apica é uma ferramenta que monitora um aplicativo Web do Azure “de fora”. Para poder usar esta ferramenta, é necessário fazer o download de seu código e adicioná-lo à implantação como uma tarefa de inicialização. A vantagem oferecida por esta ferramenta é que ela não exige o armazenamento de logs na conta de armazenamento, reduzindo portanto os custos de monitoramento.

Azure Diagnostics Manager

O Azure Diagnostic Manager da Cerebrata é um cliente baseado em Windows usado para gerenciar o Diagnóstico do Azure. Ele exibe ou faz o download dos logs coletados pelo WAD. É possível também gerenciar a configuração do WAD e, através de um painel de controle, monitorar o desempenho em tempo real.

Pesquisadores de Armazenamento do Azure

Existem diversas maneiras de explorar o armazenamento do Azure. A equipe do Armazenamento do Azure criou uma lista de pesquisadores de armazenamento. Qualquer um deles possibilita a visualização dos arquivos do WAD e dos arquivos da Análise do Armazenamento do Azure. O Pesquisador do Armazenamento de Blob do Azure da Cloudberry Lab fornece uma interface do usuário, que possibilita a Análise de Armazenamento diretamente no aplicativo, clicando em Configurações de Armazenamento.

IntelliTrace

O Microsoft Visual Studio 2010 Ultimate contém o IntelliTrace, que pode ser habilitado para depurar aplicativos antes de implantá-los na produção. O IntelliTrace suporta aplicativos ASP.NET e WCF. O IntelliTrace não é suportado quando está habilitado em um serviço de produção, porém ele pode ser usado para obter exceções para um aplicativo após a implantação no Azure. A postagem no blog de Jim Nakashima descreve como usar o IntelliTrace para depurar os Serviços de Nuvem do Azure.

AVIcode

A Microsoft comprou o AVIcode e ele é agora parte do Microsoft System Center. O AVIcode fornece capacidades de monitoramento de desempenho para aplicativos .NET, através de um pacote abrangente de capacidades de monitoramento de aplicativos.

Fiddler

O Fiddler é um Proxy de Depuração Web que registra todo o tráfego HTTP(S) entre o computador e a Internet. O Fiddler permite a inspeção do tráfego, a definição de pontos de interrupção e a manipulação de dados de entrada ou saída. O Fiddler é especialmente útil para solucionar problemas da solução de problemas do Armazenamento do Azure.

Para usar o Fiddler com a malha de desenvolvimento local, use ipv4.fiddler em vez de 127.0.0.1:

  1. Inicie o Fiddler.

  2. Inicie o serviço na malha de desenvolvimento.

  3. Vá para http://ipv4.fiddler:/. O Fiddler deve rastrear a solicitação.

Para usar o Fiddler em um armazenamento de desenvolvimento local, é necessário modificar o arquivo de configuração do serviço para que ele aponte para o Fiddler:

  1. Abra o arquivo ServiceConfiguration.cscfg e altere a cadeia de conexão para:

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

  2. Inicie o Fiddler.

  3. Inicie o serviço. O Fiddler deve rastrear qualquer solicitação de armazenamento.

Criação de Perfil de Desempenho

Você pode analisar seu aplicativo do Azure quando ele é executado no Azure para determinar eventuais problemas de desempenho. Quando você publica o aplicativo do Azure do Visual Studio, pode analisar o aplicativo e selecionar as configurações de criação de perfil necessárias.

Assistente da VM do Azure

A ferramenta VM Assistant é um projeto do CodePlex que economiza tempo ao diagnosticar problemas, coletando todos os dados relevantes em um único lugar, ao usar a Área de Trabalho Remota em uma instância. O botão Integridade VM fornece o status atual da instância.

Quando se trata de soluções baseadas na nuvem, é mais importante ainda que os projetistas de software e desenvolvedores se preparem para enfrentar problemas durante a fase de projeto, diferentemente dos produtos de software tradicionais, vendidos em caixas, implantados em servidores de data centers empresariais. Esta seção destaca alguns cenários específicos, que os desenvolvedores são responsáveis por eliminar na nuvem, e descreve como se preparar para que os problemas sejam resolvidos rapidamente assim que surgirem.

A diferença fundamental em relação à implantação tradicional baseada em servidor é que não é mais possível acessar o hardware do servidor. O SDK 1.3 do Azure agregou a capacidade de usar os Serviços da Área de Trabalho Remota para acessar as funções do Azure. O uso do SDK mais recente proporcionará a melhor experiência. Habilitar a área de trabalho remota é uma primeira etapa obrigatória ao criar um Serviço com suporte do Azure. Essa etapa só pode ser realizada antes da implantação.

Uma das etapas necessárias para habilitar a Área de Trabalho Remota é escolher um nome de usuário, senha e data de expiração da conta. Esses três itens podem ser alterados no Portal de Gerenciamento do Azure. Isso é útil para quando se esquece a senha definida meses atrás, quando o serviço foi implantado pela primeira vez.

Ao clicar no botão Configurar no portal, para alterar algum destes três parâmetros, esta sequência aparecerá, normalmente: Atualizando..., Aguardando o host..., Função atualizada com sucesso. Aguardando o host…, Pronto. Isto significa que a função recebe e, em seguida, trata o evento de alteração. Os clientes podem se inscrever nos eventos de RoleEnvironment. Em seguida, quando o RoleEnvironment.Changing Event for recebido, aceitam as alterações e continuam executando (padrão) ou deixam a instância offline, aplicam as alterações e, em seguida, ficam online novamente (e.Cancel = true)

Se o código reciclar a função nos eventos de alteração, todas as instâncias em todas as funções deste serviço hospedado serão recicladas. Os serviços com múltiplas instâncias não apresentarão tempo de inatividade, graças à arquitetura do domínio de atualização, mas o seu desempenho pode ser prejudicado à medida que cada domínio é reciclado. Mais importante: se o problema em questão só se reproduz uma vez por mês, poderá perder a chance de capturar o estado da instância. Portanto, recomenda-se que a conexão com a Área de Trabalho Remota esteja habilitada, com credenciais conhecidas e seguras que não tenham expirado.

Em seguida, é necessário testar para verificar se a conexão está funcionando. A maneira mais fácil de fazer isso é clicando no botão Conectar no portal. Na maioria dos casos, será necessário manter uma cópia do arquivo RDP, para poder alterar a seção Recursos Locais, a fim de incluir os discos locais. Isso permitirá que os arquivos sejam facilmente copiados para dentro e para fora da instância. É possível fazer esta operação clicando na guia Recursos Locais e, em seguida, no botão Mais. As configurações de conexão na guia Geral permitem que as configurações do usuário sejam salvas em um arquivo .RDP.

Windows Azure - Caixas de diálogo de Conexão de Área de Trabalho Remota

Como solucionar problemas na VM

Após ter-se conectado a uma instância, o que deve procurar? Se estiver solucionando problemas de uma função que falha ao iniciar, leia este Artigo da MSDN. Kevin Williamson possui uma excelente postagem no blog, que fornece uma visão geral sobre onde encontrar os arquivos de log e qual processo depurar.

É possível também instalar o VM Assistant para visualizar os arquivos de log e receber informações úteis sobre a instância. Também é possível instalar as ferramentas, como o Monitor de Rede ou o Fiddler, para ver o que está acontecendo na rede. Um dos testes mais simples é executar o Internet Explorer na instância e conectar-se ao site, porque ele mostrará os detalhes da exceção.

Depurar um Núcleo da Web Hospedado

Se uma função do Núcleo da Web Hospedado estiver em execução, haverá somente uma janela de comando disponível na máquina virtual. Assim, será necessário abrir uma nova janela de comando através do comando start no prompt de comando, caso contrário o usuário terá a experiência completa do Windows Server. A seguir está uma lista com alguns comandos básicos:

  • Start – Abre uma nova janela de comando

  • explorer – Abre o Windows Explorer

  • eventvwr – Abre o visualizador de logs do evento

  • taskmgr – Abre o Gerenciador de Tarefas

  • start iexplore – Executa o Internet Explorer

  • services.msc – Abre o Service Manager

  • control – Abre o Painel de Controle

  • certmgr.msc – Abre o snap-in do gerenciador de certificados

  • regedit – Abre o Editor do Registro

  • shutdown /r /t 0 – Reinicia a instância de máquina virtual

  • Start Task Manager – Útil se o usuário fechar o prompt de Comando e precisar inicializar um novo (no Gerenciador de Tarefas, vá para Arquivo -> Executar -> Cmd)

A Área de Trabalho Remota é a base para um Serviço com suporte do Azure, mas possui suas limitações conforme o número de funções e instâncias aumenta. Por exemplo, como é possível saber a qual instância é preciso se conectar quando há 100 ou mais delas? Usar este método de solução de problemas pode, na verdade, aumentar o tempo necessário para restaurar o site, se o usuário não souber o que procurar ou onde procurar.

Os pontos principais são os seguintes:

  • Ativar a área de trabalho remota em todas as funções durante a implantação.

  • Definir uma senha forte e conhecida, e certificar-se de que as credenciais não expirem.

  • Testar o acesso para garantir que ele funciona, antes que ocorra um problema.

  • Salve um arquivo RDP da conexão.

Há quatro tarefas principais para usar o Diagnóstico do Azure:

  1. Instalar o WAD

  2. Configurar a coleta de dados

  3. Instrumentar o código

  4. Exibir dados

Instalar o WAD

A arquitetura de Diagnóstico do Azure está programada para primeiramente coletar os dados na instância e, em seguida, persistir os dados para o Armazenamento do Azure. Portanto, primeiramente é necessário acessar o Portal de Gerenciamento do Azure e criar uma conta de armazenamento; por exemplo, meuslogs. Uma prática recomendada é localizar a conta de armazenamento na mesma localização geográfica que o aplicativo do Azure, para evitar pagar custos externos de largura de banda e reduzir a latência.

Um dos grandes recursos de desenvolvimento das Ferramentas do Azure para o Visual Studio versão 1.4 (agosto de 2011) e posterior é a possibilidade de ter diferentes arquivos de configuração (ServiceConfiguration.cscfg) para o local e a nuvem. As várias configurações de serviço são úteis para o diagnóstico, porque facilitam o uso do Emulador de Armazenamento nos testes locais, livre de custos, enquanto mantêm um arquivo de configuração à parte para a produção. Uma das principais causas da falha ao inicializar por parte dos aplicativos publicados no Azure é esquecer de alterar uma cadeia de conexão contendo UseDevelopmentStorage=true para false.

O Visual Studio facilita a habilitação do diagnóstico durante o teste clicando no botão Usar o emulador de armazenamento do Azure:

Windows Azure - Caixas de diálogo de Conexão de Conta de Armazenamento

Após ter testado seu aplicativo e assim que estiver pronto para publicar, você precisará ter uma conta de armazenamento para configurar para a nuvem (ServiceConfiguration.Cloug.cscfg). David Makogon comenta em seu blog três razões para ter uma conta de armazenamento especificamente para o diagnóstico, que seja separada do seu armazenamento de dados de aplicativos:

  1. Ter uma chave de acesso separada para diagnóstico possibilita o acesso aos logs sem riscos para os dados do aplicativo.

  2. Não há nenhum custo incidente em ter várias contas de armazenamento, pois o custo é calculado com base no tamanho de dados.

  3. O desempenho pode ser melhorado por ter uma conta separada.

Em seguida configure a cadeia de conexão:

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

Os valores AccountName e AccountKey estão disponíveis no Portal de Gerenciamento na seção da conta de armazenamento. AccountName é a primeira parte do URL para a tabela e pontos de extremidade de armazenamento do blob (a parte antes de “.table.core.windows.net”). AccountKey é a Chave de Acesso Primária codificada em base 64 para a sua conta de armazenamento.

Por padrão, apenas os Logs do Azure estão habilitados, mas isso pode ser alterado assim que você decidir a quantidade de dados que deseja coletar e quando os logs devem ser transferidos. Estas não são decisões triviais, porque influenciam o desempenho do seu aplicativo e determinam o quanto você será tarifado para o armazenamento de dados a cada mês.

Primeiro, você precisa determinar a quantidade de armazenamento total que será necessária para os dados coletados pelo Diagnóstico do Azure. Esse valor é restringido pelo tamanho do disco para seu Tamanho de instância/Máquina Virtual e pela propriedade OverallQuotaInMB da classe DiagnosticMonitorConfiguration. Por exemplo, se tiver configurado o seu modelo de serviço para usar um tamanho de máquina virtual ExtraSmall, a quantidade máxima de armazenamento local disponível será de 20 GB. Por padrão, OverallQuotaInMB é definido como 4 GB, o que significa que você só terá 16 GB de armazenamento total local, que pode não ser suficiente para o seu aplicativo e arquivos temporários. OverallQuotaInMB define o tamanho de um buffer delimitador regravável. Por outro lado, se o site tiver muito tráfego e você tiver configurado vários contadores de desempenho, os seus dados de diagnóstico poderão ser substituídos, especialmente se não os transferir para o armazenamento persistente de forma regular.

Após definir o tamanho da máquina virtual, você pode querer ir além dos 4 GB. Isto pode ser conseguido pela adição de um elemento <LocalStorage> para DiagnosticStore com o atributo sizeInMB definido como o novo tamanho para o seu arquivo ServiceDefinition.csdef e mudando o valor OverallQuotaInMB em conformidade:

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

Ao definir o valor do atributo cleanOnRoleRecycle como falso, você garante que o armazenamento local “DiagnosticStore” não seja limpo quando a função for reciclada. Consulte Apêndice D: ServiceDefinition.csdef para obter o código completo do ServiceDefinition.csdef. Essa definição não garante que os dados permanecerão se a instância for movida (problema de hardware e assim por diante). Lembre-se de que as configurações de diagnóstico são específicas para uma função, por isso, será necessário adicionar um DiagnosticStore para cada uma de suas funções individualmente.

Calcular o tamanho agregado dos dados de diagnóstico que você configurou é extremamente importante, porque o Diagnóstico do Azure falhará se a soma exceder OverallQuotaInMB. A única maneira de ver esse erro é anexar um depurador ou adicionar um try catch ao método OnStart. Isto é o que aparece no log de eventos do aplicativo se o código catch gravar um evento:

Windows Azure - Log de Eventos

Como calcular a “soma de subcotas solicitadas”? Cada tipo de coleção de itens (logs de eventos, contadores de desempenho e assim por diante) tem um buffer de dados associado que, por padrão, é zero. A propriedade BufferQuotaInMB pode ser deixado como padrão em zero, o que significa um tamanho menor do que OverallQuotainMB ou pode ser explicitamente definida. A OverallQuotaInMB deve ser menor do que a soma de todas as propriedades BufferQuotaInMB.

Quando a cota é atingida, os dados mais antigos são excluídos à medida que novos dados são adicionados. Esta política de exclusão também se aplica se tiver configurado um intervalo de transferência para o buffer. Após a transferência, os dados permanecem no armazenamento local e serão excluídos conforme a política acima.


// 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;

As subcotas dos Diretórios são definidas como zero, de modo que usarão o resto da cota de armazenamento disponível. Se colocar um valor específico, ele deve ser maior ou igual às outras cotas, porque deve ser suficientemente grande para conter os logs do IIS (função web) e os despejos de memória. Por padrão, Directory.QuotaInMB é definida como 1024 MB, o que significa que, se um despejo de memória for maior do que um gigabyte, o despejo deixará de gravar. Os minidespejos são uma maneira de reduzir o tamanho dos despejos.

Os arquivos de despejo completos contêm uma memória para processo (Bytes Virtuais) para quando existem falhas. Porque estamos executando em uma versão do Windows de 64 bits, o limite superior da memória será a memória física da máquina. É possível encontrar esse valor consultando a coluna da memória nesta tabela de Tamanho de instância/Máquina Virtual. Por exemplo, um despejo de memória completo de uma instância ExtraLarge poderia ser de até 14 GB. Obviamente, este é o pior cenário, onde o processo está usando toda a memória disponível, mas não acontece isso quando você realmente deseja capturar o arquivo de despejo?

Agora que você sabe a quantidade de dados de diagnóstico que irá coletar, você precisa determinar uma estratégia para conservar estes dados.

Uma opção seria a de não começar a coletar dados até determinar que ocorreu um problema. Esta opção tem duas falhas:

  1. Como terá conhecimento de que ocorreu um problema? Embora seja possível contar com os clientes para relatarem um problema grave, o que acontece com as questões mais insidiosas, como uma perda de memória?

  2. Qual é a linha de base, antes do problema ter começado? O seu aplicativo está sendo executado a 80% da CPU o tempo todo ou é um sintoma do problema?

Surpreendentemente, essa opção é a mais popular, pois não requer qualquer custo, planejamento ou ação. É também, sem dúvida, a pior alternativa.

A opção dois destina-se a configurar todos os contadores necessários, mas não para conservar os dados no Armazenamento do Windows Azure. Quando ocorre um problema, os dados podem ser examinados ou uma transferência pode ser iniciada manualmente. Esta parece ser a solução ideal, porque não há nenhum custo envolvido até que um problema surja. Infelizmente, os mesmos problemas relativamente à opção um se aplicam à opção dois e aumentam o tempo de recuperação.

A opção três destina-se a definir as diferentes propriedades ScheduledTransferPeriod de modo suficiente pequeno para assegurar que os dados de diagnóstico não sejam substituídos na instância, mas grande o bastante para não afetar o desempenho de seu aplicativo. O período de transferência menor que você pode especificar é de 1 minuto. Felizmente, qualquer valor inferior será arredondado para 1, de modo que a persistência não seja desligada. Assim, certifique-se de verificar se os seus dados de diagnóstico estão sendo transferidos antes que você realmente precise deles.

Um problema comum em muitos dos exemplos de amostras de código é que o ScheduledTransferPeriod está definido como 1 minuto, o que impactará negativamente o desempenho do aplicativo na produção. A razão pela qual os exemplos usam o valor mínimo é para que você possa ver rapidamente se eles funcionam. A maioria dos desenvolvedores não querem esperar 30 minutos para verificar se os logs foram transferidos. Há duas maneiras de contornar esse dilema: modificar sistematicamente a configuração do WAD após a implantação usando uma das Outras Ferramentas Úteis ou adicionar código mais uma configuração ao arquivo ServiceConfiguration.cscfg aproveitando o recurso dos vários arquivos de configuração de serviço mencionado anteriormente nesta seção. A configuração é criada desta forma como no ServiceConfiguration.Local.cscfg:

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

Enquanto no ServiceConfiguration.Cloud.cscfg temos algo parecido com:

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

O código no método OnStart e no evento RoleEnvironmentChanging ficaria assim:

// 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;

A outra variável que terá impacto sobre a quantidade de dados coletada é o nível de log. Uma das fontes de dados mais importantes para coleta são os Logs de Eventos do Aplicativo. Os Logs de Eventos do Aplicativo e, por vezes, os logs de Eventos do Sistema podem ser úteis. Os logs de Eventos de Segurança não estão disponíveis através do WAD. O tamanho desses arquivos pode ser reduzido usando os seguintes valores de filtro para especificar o nível de entradas de log:

  • Crítico

  • Error

  • Aviso

  • Informações

  • Detalhado

O nível de log é cumulativo, de modo que se o filtro estiver definido como Aviso, os valores Erro e Crítico também serão transferidos. É possível usar o método acima para configurar níveis específicos LogLevelFilter específicos para as configurações locais e da nuvem. ServiceConfiguration.Local.cscfg ficaria assim:

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

ServiceConfiguration.Cloud.cscfg ficaria assim:

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

O código no método OnStart e no evento RoleEnvironmentChanging ficaria assim:

// 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;

O código sugerido pode ou não atender às suas necessidades. Para aqueles que não desejarem adicionar nenhum código e preferirem ter a última configuração conhecida em vez do que está definido no código, existe outra solução.

Usar um Arquivo de Configuração

O SDK 1.3 do Azure adicionou a capacidade de colocar a configuração em um arquivo XML, em vez de escrever o código. David Hardin afirma que esta é a maneira mais eficiente de configuração de diagnóstico para todos os tipos de funções do Azure. Este método tem muitas vantagens em relação à escrita de código:

  1. O WAD inicia antes de OnStart ser executado, para que os erros em tarefas de inicialização sejam capturados.

  2. Todas as alterações feitas na configuração em tempo de execução permanecerão após uma reinicialização.

  3. Inicia automaticamente o agente de diagnóstico com a definição de configuração, sem a necessidade de código adicional que pode causar uma exceção e, que por sua vez, pode levar a que a função não seja iniciada.

  4. Este é o único método para a obtenção de um diagnóstico da função da máquina virtual beta.

  5. As alterações na configuração não exigem que o código seja recriado.

Pode encontrar um diagnostics.wadcfg de exemplo no Apêndice F: diagnostics.wadcfg. O arquivo de configuração chamado diagnostics.wadcfg deve ser colocado no seguinte local e certifique-se de definir a configuração Copiar para Diretório de Saída como Copiar sempre:

  • Para funções de trabalho, o arquivo de configuração está localizado no diretório raiz da função.

  • Para funções da Web, o arquivo de configuração está localizado no diretório bin no diretório raiz da função.

  • Para as funções de máquinas virtuais beta, o arquivo de configuração deve estar localizado na pasta %ProgramFiles%\Azure Integration Components\<VersionNumber>\Diagnostics na imagem do servidor que estiver fazendo o upload para o Portal de Gerenciamento do Azure. <VersionNumber> é a versão do SDK do Azure que você está usando. Um arquivo padrão está localizado nesta pasta que você pode modificar ou você pode substituir este arquivo por um de sua preferência.

O formato deste arquivo está descrito no seguinte Documento MSDN. O arquivo .wadcfg será ignorado se já existir uma configuração XML no recipiente de armazenamento do blob wad-control-container. Você também precisa certificar-se de que tudo no arquivo esteja correto; caso contrário, nenhum diagnóstico será coletado.

Agora você está pronto para decidir quais informações deseja coletar.

Configurar a Coleta de Dados

Se não desejar usar um arquivo de configuração, o melhor lugar para começar o diagnóstico será no método OnStart dentro de um bloco try/catch. O bloco garantirá que, se ocorrer um problema, você lidará com isso tranquilamente, o que impedirá a sua função de ficar presa reciclando. O perigo de colocar o código no método OnStart é que, se você não lidar com todas as exceções, a função entrará em um ciclo de reciclagem que será difícil de depurar. Enquanto está nesse método, a instância da função estará definida como Ocupada e não estará disponível através do balanceador de carga do Azure. Se o método OnStart retornar falso ou se ocorrer uma exceção, a instância da função será imediatamente interrompida. Se o método retornar verdadeiro, o Azure iniciará a função chamando o método Execução.

Ao encapsular o código OnStart em um bloco try/catch, você pode evitar a reciclagem da sua função (o status no Portal de Gerenciamento nunca passa para Pronto), quando ocorrer uma exceção. O código catch pode conter uma chamada de método Trace.WriteLine (Exemplo MSDN) ou um erro do log de eventos pode ser registrado (Blog de depuração do ASP.NET). Ao registrar um evento no log de eventos é mais fácil ver por que motivo uma função não inicia. Uma ligeira alteração neste código, como proposto por Tom Christian, é registrar a exceção no log de Eventos do Aplicativo da seguinte forma:

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

O código completo está no Apêndice B: Exemplo de Código da Função Web. O método mais eficiente para configurar diagnósticos é usar um arquivo de configuração e código, o que permite alterações dinâmicas das configurações a partir do Portal de Gerenciamento.

Após a configuração do diagnóstico do Azure, é possível começar a coleta de dados. É possível coletar cinco tipos de dados:

  • Despejos de memória

  • Log de Eventos do Windows

  • Contadores de desempenho

  • Logs IIS

  • Logs FREB

A tabela a seguir fornece uma visão geral de quais dados são coletados localmente por padrão e quais dados devem ser configurados explicitamente:

 

Fonte de Dados Configuração Padrão Descrição

DiagnosticInfrastructureLogs

Habilitados, armazenados localmente, sem transferência definida para o armazenamento persistente. Transfere para a tabela de armazenamento WADDiagnosticInfrastructureLogsTable

Os logs são específicos à infraestrutura do diagnóstico em si. Normalmente, estes logs não são muito úteis.

Logs

Habilitados, armazenados localmente, sem transferência definida para o armazenamento persistente. Transfere para a tabela de armazenamento WADLogsTable

Logs do System.Diagnostics.Trace, que está localizado no código do aplicativo.

Diretórios

Os blobs wad-iis-failedreqlogfiles, wad-iis-logfiles e wad-crash-dumps são automaticamente criados por padrão, cada um com sua propriedade DirectoryQuotaInMB definida como 1024 MB. Também é possível configurar diretórios adicionais

Os dados do log serão transferidos durante o intervalo de transferência ScheduledTransferPeriod

PerformanceCounters

Desabilitado. Quando adicionados, o nome da tabela de armazenamento será WADPerformanceCountersTable

Os contadores de desempenho devem ser especificados explicitamente

WindowsEventLog

Desabilitado. Quando adicionados, o nome da tabela de armazenamento será WADWindowsEventLogsTable

Nenhum elemento DataSources está especificado para os logs de Eventos do Windows.

CrashDumps

Míni despejos de memória são coletados localmente. É possível habilitar os despejos de memória. O nome criado no armazenamento de blob é wad-crash-dumps.

Chame o método EnableCollection(true) para obter despejos de memória completos.

Falha do IIS 7.0 ao solicitar dados de rastreamento

Desabilitado. Quando adicionados, o nome da tabela de armazenamento será wad-iis-failedreqlogfiles

Isto deve ser habilitado em Web.config

  • Despejos de memória

    O Diagnóstico do Azure não coleta despejos de memória automaticamente. A sintaxe está confusa porque, para coletar minidespejos, é necessário adicionar este código:

    // Enable crash mini dump collection.
                    CrashDumps.EnableCollection(false);
    
    O código para coletar os despejos completos tem esta aparência:

                    // Enable full crash dump collection.
                    CrashDumps.EnableCollection(true);
    
    Lembre-se do que foi falado sobre a configuração de Directory.QuotaInMB: se o usuário trabalhar com despejos completos, será necessário alocar armazenamento local e geral suficiente para salvá-los.

  • Logs de evento

    Os logs de evento são a maneira mais útil para encontrar erros no aplicativo. Os Eventos do Aplicativo e do Sistema podem ser adicionados desta maneira:

    // Add in configuration settings for Windows Event logs           config.WindowsEventLog.DataSources.Add("Application!*");
    config.WindowsEventLog.DataSources.Add("System!*");
    
    Apenas os eventos que ocorrem após o início do Diagnóstico do Azure são coletados, o que torna os logs de Eventos sem utilidade para diagnosticar problemas de inicialização, a não ser que a maneira recomendada de inicialização e o diagnóstico de configuração sejam usados.

    Também é possível filtrar somente alguns eventos. O Blog de Steve Marx explica como criar uma consulta XPath para obter somente informações úteis. Por exemplo, ao usar a seguinte consulta XPath com o método Adicionar, seriam coletadas somente mensagens WaAppAgent:

    ("Application!*[System[Provider[@Name='WaAppAgent']]]")
    
  • Contadores de desempenho

    Os contadores de desempenho devem ser adicionados explicitamente. A dificuldade em configurar estes contadores é que, se um deles estiver errado, todos os outros contadores da função falharão. Na janela de saída do Emulador de Computação, verá o seguinte erro:

    [MonAgentHost] Error:  PdhExpandWildCardPath(\Process(_Total)) failed
    
    As funções web e de trabalho podem usar diversas linguagens. Para todos os tipos de função, há os contadores de desempenho básicos que são recomendados. O nome do processo no exemplo abaixo (WaWorkerHost) deverá ser alterado para WallSHost, no caso de uma função web. O código específico para uma função de trabalho que não está executando código .NET pode ser encontrado no Apêndice C: Exemplo da Função de Trabalho:

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

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

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

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

    • @"\Memory\Available Bytes"

    Em uma função web ou de trabalho que está executando código em linguagem .NET, há contadores adicionais que devem ser monitorados. Novamente, o nome do processo no exemplo abaixo (w3wp) deverá ser alterado para WaWorkerHost se a função for de trabalho e para WallSHost se uma função web estiver sendo usado no modo IIS completo. Os contadores recomendados para uma função web que está executando código em linguagem .NET podem ser encontrados no Apêndice B: Exemplo de Código da Função 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"

    A cadeia WallSHost deverá ser alterada para w3wp se o modo IIS completo não estiver em uso. Como discutido anteriormente, o ScheduledTransferPeriod vai determinar quando ou se os contadores serão conservados no armazenamento.

  • Logs de IIS

    As funções Web do Azure são executadas no IIS com o log habilitado por padrão e gravadas no formato W3C, codificado em UTF-8, na pasta de recursos do aplicativo (por exemplo, C:\Resources\directory\c5c31518818e46569fa68f0809b5a6aa.fm_WebRole.DiagnosticStore\LogFiles\Web) com a Sobreposição de Arquivo de Log definida como Por Hora. Há um arquivo de log por site. Ao fazer a conexão remota com uma das instâncias e abrir o Gerenciador de Serviços de Informações da Internet, é possível ver as configurações:

    Windows Azure - Caixa de diálogo Registrar em Log

    As opções de log padrão podem ser modificadas, para satisfazer os requisitos do usuário. O truque é que qualquer alteração precisará ser incorporada em uma tarefa de inicialização, de modo que as configurações não sejam perdidas a cada reinicialização da instância. Por exemplo, para registrar somente erros, utilize o arquivo Appcmd.exe, que é parte do IIS7 em uma tarefa de inicialização, contendo o seguinte comando:

    appcmd set config /section:httpLogging /dontLog:False /selectiveLogging:LogError
    
  • Falha no Rastreamento de Solicitação

    Se possuir uma função web, certamente desejará coletar os logs Falha no Rastreamento de Solicitação (anteriormente conhecida como Falha de Solicitação de Buffer ou FREB). Isso é feito no arquivo Web.config adicionando as seguintes linhas à seção <System.webServer> como segue:

    <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>
    
    Isso resulta em falha de registro para todas as solicitações que demoram mais de 15 segundos ou com códigos de status entre 400 e 599 (o elemento failureDefinitions). Após criar o log FREB, ele será automaticamente conservado no armazenamento.

  • Outros Diretórios

    Você também pode querer coletar outros arquivos que são gravados para a instância, em particular os arquivos do agente convidado. Esses arquivos podem fornecer informações sobre o que está acontecendo entre o agente convidado e o controlador de malha do Azure. Para fazer isso, você precisa configurar um diretório que será copiado pelo Diagnóstico do 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);
    
    A mesma advertência se aplica aqui sobre o que pode acontecer se a configuração falhar. Para testar no emulador de computação, você precisará criar esta pasta e certificar-se de que múltiplas funções não estão executando este código. Caso contrário, ocorrerá uma violação de compartilhamento. Esse erro não ocorrerá na configuração da nuvem, porque cada instância é separada.

Solução de problemas do WAD

Agora que você tem tudo configurado, é hora de testá-lo, tanto no emulador de computação como no implantado no Azure. O que acontece quando os diagnósticos não aparecem? Aqui está uma lista de itens a verificar:

  1. Confira os blobs no recipiente de blob wad-control-container na conta de armazenamento de diagnóstico. Você está procurando o blob nomeado com <deploymentID>/<RoleName>/<RoleInstance> (ou seja, 3981bcff0eb743ddb9b7574a8821e955/WebRole1/WebRole1_IN_0).

    1. Abra o arquivo XML e verifique se ele está configurado da forma que você espera. Se vir <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes> para uma determinada fonte de dados, significa que os diagnósticos não estão configurados para transferir os dados.

    2. Se tiver várias instâncias, e algumas delas estiverem transferindo diagnósticos, mas outras não, compare os arquivos XML para se certificar de que eles estejam todos configurados corretamente.

    3. Se configurar o diagnóstico após a implantação, e o diagnóstico aleatoriamente parar de funcionar, provavelmente é porque a função de reciclagem ou a instância foi reiniciada. Quando uma instância é reiniciada, as configurações personalizadas pós-implantação são perdidas e são usados os diagnósticos configurados no código. Um dos principais benefícios de usar o arquivo wadcfg. é que esta configuração não é substituída na reciclagem da função.

  2. Verifique os registros na tabela WADDiagnosticInfrastructureLogsTable na conta de armazenamento de diagnóstico. Você vai querer filtrar baseado em DeploymentId (ou seja, DeploymentId eq 'bd9e149f76e8413aba8865c77326e449'). Procure quaisquer exceções ou mensagens de erro que possam indicar por que os diagnósticos não estão sendo transferidos.

  3. Se a informação Diagnostics.Trace não estiver sendo coletada, verifique se o DiagnosticMonitorTraceListener está configurado no web.config ou app.config. Isso é configurado por padrão em projetos de nuvem, mas em algum momento ele pode ficar alterado, o que fará com que as instruções de rastreamento não sejam coletadas pelos diagnósticos.

  4. Um problema comum é não consultar o armazenamento de diagnóstico corretamente, retornando, assim, que não foram encontrados resultados e assumindo que os diagnósticos não estão sendo capturados. Consulte as tabelas de diagnóstico, filtrando por DeploymentID, e valide se os diagnósticos estão sendo transferidos corretamente ou não. Alguns erros de consulta comuns são: não filtragem por DeploymentID e não seguir os tokens de continuação.

  5. Após a implantação, se a sua instância não for iniciada, verifique se a conta de armazenamento configurada no arquivo ServiceConfiguration.cscfg não está definida como “UseDevelopmentStorage = true”. Se estiver usando uma versão pós-agosto 2011 das Ferramentas do Azure para Visual Studio 2011, você receberá um aviso. Caso contrário você vai precisar executar o RDP em sua instância e verificar o arquivo de configuração da função localizado na pasta C:\Config.

  6. Outra coisa a verificar quando conectado à instância é se DiagnosticsAgent.exe e MonAgentHost.exe estão sendo executados. Assumindo que estejam, será possível instalar e anexar o WinDBG para ver se todas as exceções estão sendo lançadas.

  7. Também é possível verificar se os diagnósticos estão sendo gravados localmente.

    • Para o ambiente de desenvolvimento, os arquivos .tsf serão gravados em:

      C:\Users\<username>\AppData\Local\dftmp\Resources\<deploymentID>\directory\DiagnosticStore\Monitor\Tables

    • Em uma instância em execução, os arquivos serão gravados em:

      C:\Resources\<deploymentID>.<role>\directory\DiagnosticStore\Monitor\Tables

    Atualmente para ler esses arquivos, você terá que criar um caso de suporte e enviá-los para a Microsoft.

  8. Se tiver várias instâncias e só algumas delas não estiverem transferindo diagnósticos corretamente, tente recriar a função no Portal de Gerenciamento. Isso deve ser usado como último recurso, porque perderemos a capacidade de determinar a causa raiz de por que o problema estava acontecendo.

Instrumentar o código

Talvez os dados de diagnóstico mais importantes sejam as mensagens de rastreamento que você, como desenvolvedor, adiciona a seu próprio código. Os dados do sistema podem mostrar exceções ou registrar em log mensagens de erro. Você pode rastrear até chamadas específicas para sistemas dependentes. A prática recomendada seria adicionar uma mensagem de rastreamento ao chamar um sistema dependente que pode falhar; por exemplo, um serviço de autenticação de terceiros.

O quadro ETW associa um TraceEventType a cada evento:

 

TraceEventType Nível Valor Significado

Crítico

1

0x0001

Erro fatal ou falha do aplicativo

Error

2

0x0002

Erro recuperável

Aviso

3

0x0004

Problema não-crítico – pode ser uma indicação de problemas mais sérios eminentes.

Informações

4

0x0008

Mensagem informativa

Detalhado

5

0x0010

Rastreamento de depuração (como a informação do fluxo da execução detalhada, parâmetros e assim por diante)

Início

0x0100

Início de uma operação lógica

Parar

0x0200

Parada de uma operação lógica

Depois de ter um plano de como instrumentar seu código, você pode simplesmente adicionar o namespace System.Diagnostics e, em seguida, adicionar mensagens de rastreamento, que em C# ficaria assim:

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

Como o Azure começou a ser executado no IIS Completo (SDK 1.3), o código do aplicativo Web é executado em um domínio de aplicativo diferente e é processado a partir do RoleEntryPoint. Isto significa que as mensagens de rastreamento não aparecerão no emulador de computação, a menos que você adicione um ouvinte de rastreamento adicional a Web.Config em 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>

Para aplicativos mais complexos, uma metodologia EventId lhe permitirá filtrar logs de forma mais eficiente, o que levará à resolução de problemas de forma mais rápida. Se usar WriteLine em C#, EventId será sempre 0. Para especificar um EventId, será necessário usar o método TraceEvent, em que o traceType pode ser encontrado na tabela acima:

Trace.TraceEvent(traceType, eventId, message);

As mensagens de rastreamento são conservadas na tabela WADLogsTable. O Azure automaticamente associa as seguintes informações a cada evento registrado: um carimbo de data/hora, uma contagem em escala (que fornece um controle de tempo mais detalhado com uma granularidade de 100 nanossegundos) e informações sobre a implantação, a função e a instância de função. Isso permite que você restrinja os logs para instâncias específicas. A mensagem é armazenada em formato XML como esta:


<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>

O nível corresponde a TraceEventType. Na tabela acima, é possível ver que o nível 3 corresponde a um Aviso. Se nenhum TraceEventType for especificado ou se usar Trace.WriteLine, o nível será definido como 5 (detalhado).

Na maioria das vezes, o log padrão deverá ser suficiente. Para obter tipos de log mais detalhados, você pode criar um ouvinte de rastreamento personalizado:

A Consulta da Tabela do Azure é um projeto CodePlex de funções web que permite que você consulte a WADLogsTable com uma consulta LINQ.

Exibir os dados

A razão para coletar diagnósticos é tê-los prontamente disponíveis quando ocorre um problema. Isso significa que você precisa verificar se tudo está funcionando antes que haja um problema, da mesma forma que você precisa verificar se um backup de dados está funcionando corretamente. Isso significa ver seus dados de diagnóstico durante o teste de sua aplicação e, em seguida, periodicamente, para garantir que eles ainda estão funcionando. Significa, também, a criação de uma linha de base para poder saber quando ocorre um desempenho anormal.

Todos os dados do Diagnóstico do Azure são armazenados na conta de armazenamento especificada quando o WAD é iniciado. É possível usar o Visual Studio Server Explorer ou um dos muitos storage explorers para exibir os dados.

O blob wad-control-container contém o registro da própria infraestrutura de diagnóstico. Este é o lugar onde você pode ver se os dados estão sendo transferidos de uma determinada instância. A identidade do blob será da seguinte forma:

0aef2b51ad1d49ef915dd41d3ca01f24/WorkerRole1/WorkerRole1_IN_0

Essa identidade é separada em três partes:

  1. O número longo é a ID de implantação – 0aef2b51ad1d49ef915dd41d3ca01f24

  2. Nome da função – WorkerRole1

  3. Nome da instância – WorkerRole1_IN_0

Quando existem várias instâncias diferentes, o sufixo baseado em zero será incrementado, por exemplo, WorkerRole1_IN_1 será a segunda instância.

A tabela abaixo mostra onde cada log está gravado:

 

Tipo de Log Formato de armazenamento do Azure Observações

Os logs do Azure são criados a partir do seu código

Tabela

O ouvinte de rastreamento deve ser adicionado ao arquivo web.config ou app.config. Os arquivos são armazenados em WADLogsTable.

Logs do IIS 7.0

Blob

Somente funções web. Armazenados em um Contêiner de Blob no caminho wad-iis-logfiles\<deployment ID>\<web role name>\<role instance>\W3SVC1.

Logs de Infraestrutura do Diagnóstico do Windows

Tabela

Informações sobre o próprio serviço de diagnóstico. Armazenado em WADDiagnosticInfrastructureLogsTable.

Falha no logs de solicitação

Blob

Somente funções web. Habilitados através da definição de opções de rastreamento nas configurações system.WebServer em web.config. Armazenados em um contêiner de blob no caminho wad-iis-failedreqlogfiles\<deployment ID>\<web role name>\<role instance>\W3SVC1.

Logs de eventos do Windows

Tabela

Habilitados alterando DiagnosticMonitor Configuration.WindowsEventLog na definição da configuração inicial. Armazenados em WADWindowsEventLogsTable.

Contadores de desempenho

Tabela

Habilitados alterando DiagnosticMonitor Configuration.PerformanceCounters. Armazenados em WADPerformanceCountersTable. A função de trabalho do código de exemplo configura um contador de desempenho.

Despejos de memória

Blob

Habilitados chamando CrashDumps.EnableCollection. Armazenados em um contêiner de blob no caminho wad-crash-dumps. Como o ASP.NET manipula a maioria das exceções, isso geralmente é útil apenas para uma função de trabalho.

Logs de erro personalizados

Blob

Para obter um exemplo útil de como funciona, consulte o Blog de Neil Mackenzie.

Quando os dados de despejo de memória são transferidos para um armazenamento persistente, eles ficam armazenados no contêiner de blob wad-crash-dumps. Os logs do IIS são transferidos para o contêiner de blob wad-iis-logfiles. As falhas nas solicitações são armazenadas no contêiner de blob wad-iis-failedreqlogfiles.

Os logs de eventos são transferidos para a tabela WADWindowsEventLogs no armazenamento persistente. Os contadores de desempenho são transferidos para a tabela WADPerformanceCounters no intervalo especificado. O WADDiagnosticInfrastructureLogs contém logs sobre a infraestrutura de diagnóstico. Os ouvintes de rastreamento podem ser encontrados na tabela WADLogsTable.

Outra ferramenta para exibir os dados de diagnósticos é através da utilização de LINQPad usando o exemplo AzureLogsWithLINQPad de Jason Haley.

Gerenciar Diagnósticos

Conservar todos esses arquivos de log no armazenamento do Azure custará dinheiro e tempo. A solução ideal será habilitar o rastreamento “somente no momento”, quando precisa solucionar um problema particular. Quando alterar dinamicamente as configurações de diagnóstico, será necessário não esquecer de as repor manualmente para suas configurações originais ou alterar as configurações originais se precisar de algum item sempre presente. Este passo consciente é especialmente importante se não estiver usando o arquivo .wadcfg, porque se a instância for reiniciada, suas novas configurações serão substituídas pelas configurações de diagnóstico configuradas em seu código.

Os Cmdlets do PowerShell do Azure podem gerenciar vários aspectos dos seus serviços do Azure em execução, incluindo o diagnóstico. Você executa esses serviços em sua máquina local e eles usam as APIs de Diagnóstico e Gerenciamento do Azure para se conectarem pela Internet ao seu serviço, fornecendo as informações e ajustando os parâmetros.

O Windows PowerShell é instalado com o Windows 7 e é a evolução dos cmdLets do Gerenciamento de Serviços instalados com a Ferramenta de Gerenciamento do Azure (MMC). Abaixo está uma lista com os cmdlets mais úteis:

  • Get-DiagnosticConfiguration – Obtém a configuração de buffer do nome de buffer especificado (Logs, Diretórios, PerformanceCounters, WindowsEventLogs ou DiagnosticInfrastructureLogs).

  • Para alterar a configuração para uma função, use o cmdlet DiagnosticConfiguration.

  • Start-OnDemandTransfer – Inicia uma transferência sob demanda do buffer de dados especificado. Isso move os dados para o Armazenamento do Azure (tabela ou armazenamento de blob).

O Blog de David Aiken tem um script para a limpeza de alguns arquivos de log (arquivos de log do IIS e arquivos XML wad-control-container). O cmdlet Clear-Container deve ser chamado para cada contêiner. Também será necessário para assegurar que as suas transferências programadas não ficam sobrepostas com a exclusão. Também será necessário definir uma estratégia para os logs armazenados em tabelas (contadores de desempenho, logs de eventos e etc). Alguns usuários baixam tudo do armazenamento do Azure e colocam em um banco de dados SQL Server, para que não sejam cobrados pelo armazenamento e sejam capazes de fazer consultas mais complexas sobre os dados.

Ao entender os recursos de diagnóstico do Azure, os desenvolvedores podem criar aplicativos com suporte usando as práticas recomendadas de design descritas abaixo.

A integridade de um aplicativo precisa ser avaliada em relação a uma linha de base. O fato de sua página inicial ser exibida, não significa necessariamente que seu aplicativo esteja em bom estado. Compreender a integridade e o desempenho da lógica de negócios também é necessário para criar uma linha de base de integridade completa.

A etapa seguinte é entender como essa integridade se acumula. O primeiro pilar de um bom estado de integridade é mantendo os pagamentos do Azure em ordem. Ter uma assinatura por pagar trará progressivamente más consequências, o que, em última instância, pode levar à exclusão de seu aplicativo.

Para cada assinatura, existe um serviço hospedado do Azure composto por quatro níveis que poderão afetar a integridade de seu aplicativo.

Windows Azure - Níveis de integridade

Por exemplo, uma instância poderá falhar devido a uma falha de hardware ou ser reiniciada devido a uma atualização de software. Isso não levará à falha da função, a menos que tenha apenas uma instância configurada. Da mesma forma, cada serviço hospedado está localizado em uma região particular (por exemplo, Centro- Sul dos EUA). Essa informação crítica determinará se o seu aplicativo é afetado por um evento de interrupção de serviço (também conhecido como interrupção). As falhas nos níveis mais baixos podem causar falhas no nível de serviço hospedado se a redundância não estiver incorporada no design do aplicativo.

A maioria dos aplicativos do Azure requer arquiteturas mais complexas que as do diagrama anterior. O seu aplicativo possivelmente será como o seguinte:

Windows Azure - Exemplo de arquitetura

A natureza distribuída introduz vários pontos possíveis de falha. Documentar esses caminhos críticos torna a solução dos problemas mais eficiente. Por exemplo, no diagrama acima, como poderia testar se a falha ocorreu no Controle de Acesso?

De forma a entender o que está errado em seu aplicativo, será necessário monitorar e registrar o estado do aplicativo. Em geral, você deseja registrar quatro categorias de informação sobre o seu aplicativo:

  • Programática: exceções, valores de chave variáveis e qualquer outra informação necessária para depurar o aplicativo.

  • Processo corporativo: auditoria necessária para a segurança, o controle de alterações, a conformidade.

  • Estabilidade do sistema: desempenho, escalabilidade, rendimento, latências.

  • Validação das pressuposições corporativas: O aplicativo está sendo usado como pretendia?

O elemento mais básico do caráter humano é bloquear quando há uma crise. O treinamento e a prática lhe permitirão superar esse instinto. Essa é a razão porque treinamos exercícios de combate a incêndio e algumas companhias aéreas estão promovendo cursos de segurança em caso de acidente. A maioria das grandes empresas gastam uma quantidade significativa de seu orçamento no planejamento de recuperação de desastres. Para obter as práticas recomendadas, pode ler a Implementação da Equipe de TI da Microsoft para Recuperação de Desastres no Datacenter.

Apenas gostaríamos de destacar as técnicas que irão acelerar a solução de problemas em caso de problema. Saber que seu aplicativo foi criado de uma forma que facilitará a solução de problemas pode reduzir o estresse quando ocorre um problema, reduzindo o tempo para colocar o site em funcionamento. A análise do custo-benefício determinará a quantidade de tolerância a falhas será criada em seu sistema. Por exemplo, valerá a pena o custo adicional de ter um backup dinâmico fornecido pelo Gerenciamento de Tráfego para reduzir o tempo de inatividade?

O Gerenciamento de Tráfego do Azure permite-lhe gerenciar e distribuir o tráfego de entrada para os seus serviços hospedados do Azure, quer estejam implantados no mesmo data center ou em data centers diferentes no mundo todo. Proporciona a capacidade de configurar um serviço de failover. Assim, se o seu serviço primário deixar de funcionar, o tráfego é enviado para o próximo serviço disponível na lista. O software de terceiros como Akamai ou Limelight também oferece soluções de balanceamento de carga.

Abaixo está um plano de cinco etapas para acelerar a resolução.

A primeira etapa em seu plano é ter conhecimento dos problemas assim que eles ocorrem. Quanto mais rápido você tiver conhecimento de um problema, mais rápido poderá começar a implementar o seu plano de recuperação de desastres. É por essa razão que o monitoramento é fundamental.

A segunda etapa é determinar qual a origem do problema: na plataforma Azure ou em seu aplicativo. O primeiro local a procurar é no Painel de Serviços do Azure. Este local requer que você conheça todos os serviços usados por seu aplicativo e em que data center o serviço está implantado. Apenas uma degradação no serviço é necessária para ter impacto em seu aplicativo.

Uma forma de monitorar os eventos de serviço da plataforma Azure é através da assinatura de todos os feeds RSS para o seu aplicativo. Por exemplo, se o seu aplicativo foi hospedado no data center do Centro-Norte dos EUA, você deverá assinar este feed RSS.

O Armazenamento do Azure usa domínios com falha (rack, comutador de rede, potência) para limitar o impacto das falhas de hardware. Um equívoco comum sobre o armazenamento do Azure é que as réplicas dos seus dados fora de um único local (por exemplo, Centro-Sul dos EUA) irão falhar automaticamente para uma réplica. Se o armazenamento tiver um problema em uma determinada localizaç��o, o acesso aos seus dados será afetado. Este blog da equipe de armazenamento dá-lhe todos os detalhes sobre o novo recurso de replicação geográfica.

A terceira etapa consiste em localizar o problema. Essa é talvez a etapa mais difícil em um aplicativo complexo que usa vários Serviços do Azure. Criar um serviço sem monitoração de estado ajudará a isolar as diferentes partes de seu aplicativo. Se todos os serviços dependentes estiverem funcionando normalmente, será necessário determinar a integridade dos seus serviços de computação. Isso poderá ser feito no Portal de Gerenciamento acessando a seção Serviços Hospedados, Contas de Armazenamento e CDN e escolhendo qual a sua implantação. Na janela de propriedades, você verá algo assim:

Windows Azure - Propriedades de implantação

Nesse caso, pode-se constatar que durante os últimos oito dias, a minha implantação foi executada normalmente, conforme calculada pela diferença do período de tempo entre a Hora da última operação concluída e a última atualização. Se, por outro lado, observar que a sua implantação foi anulada ou reiniciada recentemente, isso pode ajudar a identificar por onde começar a procurar. Se lhe parecer ser um evento de serviço afetando todas as suas implantações em um determinado data center, entre em contato com a Microsoft imediatamente: (866) 676-6546.

A quarta etapa é a realização de etapas de solução de problemas padrão, como a verificação de arquivos de log, logs de eventos, anexar um depurador ou usar ferramentas, como o Procmon ou o Monitor de Rede, para ver se consegue encontrar alguma indicação sobre o problema. O primeiro lugar a procurar na implantação dos Serviços Hospedados do Azure é no Log de Eventos do Aplicativo. Certifique-se de que não existem exceções lançadas pelo aplicativo. Isso pode parecer desnecessário, uma vez que todo o suporte é gratuito. A verdade é que, muitas vezes, é possível encontrar e corrigir os problemas mais rapidamente que engenheiro do suporte da Microsoft altamente treinado, que não tem o seu conhecimento de todo o escopo do aplicativo. Se é a prioridade for “site em funcionamento”, procurar primeiro é a melhor alternativa.

A quinta etapa é entrar em contato com o Suporte da Microsoft. Para acelerar a resolução do seu problema, precisará fornecer a ID federada (Windows Live ID) associada ao Proprietáro da Conta da assinatura. Também deverá fornecer o resultado da sua análise da origem do problema e os erros encontrados nos diferentes arquivos de log. Os engenheiros do suporte da Microsoft poderão solicitar-lhe que os adicione como coadministradores à sua subscrição, para que possam ver o Portal de Gerenciamento da mesma forma que você.

O desempenho é como a beleza: está nos olhos de quem vê. Qual é o limite quando o desempenho se torna inaceitável? Quando uma página expira? Mesmo que quantifique o tempo de carregamento máximo, isso não garante que as páginas sejam carregadas para todos os seus clientes. O roteamento DNS e a confiabilidade da rede são dois fatores-chave para determinar os tempos de carregamento da página. Por exemplo, tínhamos um cliente em Memphis, Tennessee cujo ISP enviava o tráfego de Santo António, Texas primeiro para Chicago.

Uma discussão detalhada do desempenho está fora do escopo deste documento. Para obter as práticas recomendadas para o desenvolvimento no Azure, consulte o artigo do TechNet Guia de Desempenho e Elasticidade do SQL Azure. A solução de problemas de desempenho começam por ter uma linha de base. Por essa razão, é vital a coleta de dados de desempenho durante um longo período de tempo. Uma vez definida a linha de base, poderá identificar as tendências e as anomalias.

A plataforma Azure fornece Contratos de Nível de Serviço (SLA), que definem os níveis de disponibilidade/conectividade dos vários serviços. O que são os seus SLAs? O meu ISP disse-me uma vez que eu não deveria usar a minha conexão para os negócios, porque o meu pacote não tinha um SLA. A confiabilidade é um pouco como o desempenho, que está fortemente dependente da conexão de rede subjacente do cliente e também é subjetiva. Os links acima podem ajudar no entendimento do desempenho da sua conexão de rede.

Um erro comum é assumir que os SLAs da plataforma Azure irão garantir os mesmos SLAs do seu aplicativo. Primeiro, alguns não leem a segunda frase, que diz:

Para computação, garantimos que quando implanta duas ou mais instâncias de função em diferentes domínios com falha e domínios de atualização, as suas funções de Internet terão conectividade externa, pelo menos, 99,95% do tempo.

Essa frase carece de dois qualificativos adicionais: “duas ou mais instância de função por função”. Por outras palavras, ter uma função web e uma função de trabalho, cada uma com uma instância, implica que o seu aplicativo não estará disponível toda a vez que há atualizações do sistema operacional de host ou algum tipo de recuperação de sistema. A computação do Azure usa domínios com falha para assegurar que o SLA é atendido.

Outra concepção errônea é a de que se escolher uma versão do SO particular, não terá quaisquer interrupções derivadas das atualizações do sistema operacional. Embora isso seja verdadeiro no caso do SO convidado sendo executado em sua instância, o mesmo não se verifica no SO de host sendo executado no computador físico no data center.

A fim de maximizar a confiabilidade, será necessário monitorar o seu site internamente com os dados de Diagnóstico do Windows Azure e externamente usando o Gomez da Compuware ou Pingdom. Também será necessário verificar se possui os patches de segurança mais recentes e um plano de verificação das alterações de código.

Ao criar um novo aplicativo com o Visual Studio, o comportamento padrão é definir a versão do sistema operacional convidado no arquivo ServiceConfiguration.cscfg como segue:

osFamily="1" osVersion="*"

Isso é bom, porque obterá atualizações automáticas, que é um dos benefícios-chave da PaaS. Não seria o ideal porque não está usando o SO mais recente. Para usar a versão do sistema operacional mais recente (Windows Server 2008 R2), a configuração deverá assemelhar-se ao seguinte:

osFamily="2" osVersion="*"

Infelizmente, muitos clientes decidem bloquear uma versão particular do SO com o intuito de aumentar o tempo de atividade evitando as atualização do SO convidado. Isso é apenas uma estratégia razoável para clientes corporativos, que sistematicamente testam cada atualização na preparação e, em seguida, agendam uma Permuta de VIP para seu aplicativo essencial sendo executado na produção. Para todos os outros que não testam cada atualização do SO de host, ao não configurarem as atualizações automáticas estão colocando o aplicativo do Azure em risco.

Qual é o plano quando precisa de atualizar o seu serviço especialmente em caso de emergência? Esta etapa frequentemente ignorada poderá ser a diferença entre ter um site inoperante e lidar com problemas de preparação menores. Embora se gaste muito tempo e esforço no planejamento inicial e liberação do aplicativo do Azure, muitas vezes assume-se que esses testes extensivos não são necessários para as atualizações porque a ação para corrigir uma alteração é menor do que em um produto pronto. As regressões podem ser rapidamente corrigidas. Infelizmente também podem causar facilmente falhas catastróficas.

Cada alteração em um aplicativo de produção precisa ser testada antes da implantação final para produção. O tempo extra é bem empregue tendo em conta as possíveis consequências de uma falha. Para obter mais informações, leia a Visão geral da atualização de um Serviço do Azure.

Obrigado por dispensar algum tempo considerando os tópicos aqui apresentados. Gostaríamos muito de saber qual o seu feedback daquilo que melhor funciona com você. O custo de ter seu serviço inoperante deverá ser considerado relativamente ao custo da coleta dos dados de diagnóstico. Esse cálculo deverá ser realizado antes de passar para a produção. O trabalho necessário para desenvolver aplicativos confiáveis no Azure não é novo, revolucionário nem tecnicamente desafiador; apenas requer que os projetistas e desenvolvedores considerem os potenciais problemas que poderão surgir nos seus aplicativos e utilizem as práticas aqui descritas.

  • Christian, Tom, “Ajuda com a função do Azure paralisada no estado Inicializando/Ocupado/Parado”, Blog, 28 de fevereiro de 2011.

  • Cross, Andy, “Rastreamento para o SDK V1.3 do Emulador de Computação do Azure”, Blog, 22 de janeiro de 2011.

  • Haley, Jason, “Como: Consultar Tabelas de Log do Azure com LINQPad”, Blog, 28 de janeiro de 2010 15:09.

  • Hardin, David, “Configurar o WAD por meio do Arquivo de Configuração diagnostics.wadcfg”, Blog, 29 de março de 2011.

  • Kelly, Mike, “Controlar os Logs e Rastreamento no Azure”, MSDN Magazine, junho de 2010.

  • Mackenzie, Neil, “Diagnóstico Personalizado no Azure”, Blog, 8 de dezembro de 2009.

  • Makogon, David, “Dica do Dia do Azure: Conta de Armazenamento de Diagnóstico Separada”, Blog, 15 de agosto de 2010.

  • Marx, Steve, “Capturar Eventos Filtrados do Windows com o Diagnóstico do Azure”, Blog, 21 de abril de 2010.

  • Mladenov, Toddy, “Coletar Logs de Eventos no Azure”, Blog, 2 de maio de 2010.

  • Myers, Walter, “Configurar Contadores de Desempenho nas Funções Web e de Trabalho do Azure”, Blog, 31 de janeiro de 2011.

  • Nakashima, Jim, “Usar o IntelliTrace para depurar os Serviços de Nuvem do Azure”, Blog, 7 de junho de 2010.

  • O’Neil, Jim, “Erro 500 e Outros Erros no Blog de Implantações do Azure”, Blog, 11 de abril de 2011 4:47.

  • Stiefel, Michael, “Porque Falhou o Meu Aplicativo? Usar a API de Diagnóstico do Azure para Encontrar Problemas de Códigos”, Blog, 8 de setembro de 2011.

  • Washam, Michael, “Gerenciar Arquivos de Log com os Cmdlets do PowerShell 2.0 do Azure”, Blog, 20 de setembro de 2011.

  • Williamson, Kevin, “Arquitetura de Funções do Azure”, Blog, 5 de maio de 2011.

  • Portal de Gerenciamento do Azurehttp://manage.windowsazure.com.

  • Portal do Azure http://www.microsoft.com/windowsazure/

 

Malha

Os clusters lógicos de computadores, que fornecem um ambiente de execução de funções em uma máquina virtual.

FREB

Falha no Rastreamento de Solicitação (anteriormente conhecida como Falha de Solicitação de Buffer (Failed Request Buffering))

Portal de gerenciamento

O Portal de Gerenciamento do Azure é um portal administrativo para gerenciamento, implantação e monitoramento dos serviços do Azure. O Portal de Gerenciamento pode ser acessado em http://manage.windowsazure.com.

REST

REpresentational State Transfer (Transferência de Estado Representacional); é um projeto de software que utiliza uma arquitetura cliente-servidor sem monitoração de estado onde os serviços Web são exibidos como recursos e podem ser identificados por seus URLs.

Contrato de Nível de Serviço

Contrato de Nível de Serviço (SLA – Service Level Agreement)

Máquina Virtual

A emulação do software no computador que é executada em uma partição isolada de um computador real.

WAD

Diagnóstico do Azure

Função Web

Uma função web é uma função personalizada para programação de aplicativo Web com suporte pelo IIS 7 e pelo ASP.NET.

Função de trabalho

Uma função de trabalho é uma função útil para desenvolvimento generalizado e pode executar processamento em segundo plano para uma função web.

Este apêndice foca no código solicitado para configuração do Diagnóstico do Azure. O método RoleEntryPoint.OnStart é chamado para lhe dar a oportunidade de personalizar a inicialização em vez da instância de função. Poderá fornecer sua própria implementação do OnStart para executar o código necessário para a configuração do WAD para a sua função.

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

Este apêndice foca no código solicitado para configuração do Diagnóstico do Azure em uma função de trabalho.

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>

noteObservação
Esse arquivo de configuração é para uso local, com o emulador de computação.

<?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>

Este é um exemplo de um arquivo diagnostics.wadcfg para uma função 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>

Esta é a configuração padrão gravada no 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>

Mostrar:
© 2015 Microsoft