Solução de problemas do Diagnóstico do Azure

Este artigo descreve informações de solução de problemas relevantes para o uso do Diagnóstico do Azure. Para saber mais sobre o Diagnóstico do Azure, confira Visão geral do Diagnóstico do Azure.

Componentes lógicos

Os componentes são:

• Inicializador do Plug-in do Diagnóstico (DiagnosticsPluginLauncher.exe): inicia a extensão do Diagnóstico. Serve como o processo do ponto de entrada.
• Plug-in do Diagnóstico (DiagnosticsPlugin.exe): configura, inicializa e gerencia o tempo de vida do agente de monitoramento. É o principal processo inicializado pelo inicializador.
• Agente de Monitoramento (MonAgent*.exe processes): monitora, coleta e transfere os dados de diagnóstico.

Caminhos do log/artefato

Os caminhos a seguir levam a alguns logs e artefatos importantes. Nos referimos a essas informações ao longo deste artigo.

Serviços de nuvem do Azure

Máquinas virtuais

Os dados de métrica não aparecem no Portal do Azure

O Diagnóstico fornece dados de métrica que podem ser exibidos no portal do Azure. Se você tiver problemas para visualizar os dados no portal, verifique a tabela WADMetrics\* na conta de armazenamento do Diagnóstico para ver se os registros de métricas correspondentes estão presentes e assegurar que o provedor de recursos Microsoft.Insights está registrado.

Aqui, o PartitionKey da tabela é a ID de recurso, máquina virtual ou conjunto de dimensionamento de máquinas virtuais. RowKey é o nome da métrica. Ele também é conhecido como o nome do contador de desempenho.

Se a ID do recurso estiver incorreta, verifique Configuração do Diagnóstico>Métricas>ResourceId para ver se a ID do recurso está definida corretamente.

Se não houver dados para a métrica específica, verifique Configuração de Diagnóstico>PerformanceCounter para ver se a métrica (contador de desempenho) está incluída. Os seguintes contadores são habilitados por padrão:

• \Processador(_Total)% Tempo do processador
• \Memória\Bytes Disponíveis
• \Aplicativos ASP.NET (Total)\Solicitações/s
• \Aplicativos ASP.NET (Total)\Total de Erros/s
• \ASP.NET\Solicitações Enfileiradas
• \ASP.NET\Solicitações Rejeitadas
• \Processador(w3wp)% Tempo do Processador
• \Processo(w3wp)\Bytes Privados
• \Processo(WaIISHost)% Tempo do Processador
• \Processo(WaIISHost)\Bytes Privados
• \Processo(WaWorkerHost)% Tempo do Processador
• \Processo(WaWorkerHost)\Bytes Privados
• \Memória\Falhas de Página/s
• .Memória CLR NET(Global)% Tempo em GC
• \LogicalDisk(C:)\Bytes de Gravação de Disco/s
• \LogicalDisk(C:)\Bytes de Leitura de Disco/s
• \LogicalDisk(D:)\Bytes de Gravação de Disco/s
• \LogicalDisk(D:)\Bytes de Leitura de Disco/s

Se a configuração estiver configurada corretamente, mas você ainda não pode ver os dados de métrica, utilize as seguintes diretrizes para ajudá-lo a solucionar problemas.

O Diagnóstico do Azure não inicia

Para obter informações sobre o motivo do Diagnóstico falhar ao iniciar, confira os arquivos DiagnosticsPluginLauncher.log e DiagnosticsPlugin.log no local dos arquivos de log que foi fornecido anteriormente.

Se esses logs indicarem Monitoring Agent not reporting success after launch, isso significa que houve uma falha ao iniciar MonAgentHost.exe. Examine os logs no local indicado para o arquivo de log MonAgentHost na seção "Máquinas virtuais" anterior.

A última linha dos arquivos de log contém o código de saída.

DiagnosticsPluginLauncher.exe Information: 0 : [4/16/2016 6:24:15 AM] DiagnosticPlugin exited with code 0

Se você encontrar um código de saída negativo, consulte a tabela de códigos de saída na seção Referências.

Os dados do Diagnóstico não são registrados no Armazenamento do Microsoft Azure

Determine se nenhum dado aparece ou se alguns dos dados aparecem.

Logs de infraestrutura de diagnóstico

O diagnóstico registra todos os erros nos logs de infraestrutura de Diagnóstico. Verifique se você habilitou a captura dos logs de infraestrutura do Diagnóstico na configuração. Então, você poderá examinar rapidamente os erros relevantes que aparecem na tabela DiagnosticInfrastructureLogsTable na conta de armazenamento configurada.

Nenhum dado é exibido

O motivo mais comum para os dados de evento não serem sempre exibidos é porque as informações da conta de armazenamento estão definidas incorretamente.

Solução: corrija sua configuração do Diagnóstico e o reinstale.

Se a conta de armazenamento estiver configurada corretamente, faça acesso remoto ao computador e verifique se DiagnosticsPlugin.exe e MonAgentCore.exe estão em execução. Se eles não estiverem em execução, siga as etapas em Diagnóstico do Azure não inicia.

Se os processos estiverem executando, acesse Os dados estão sendo capturados localmente? e siga as instruções.

Se ainda houver um problema, tente:

1. Desinstalar o agente.
2. Remover o diretório C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics.
3. Reinstalar o agente.

Parte dos dados está ausente

Se você estiver obtendo alguns dados, mas não todos, isso significa que a coleta de dados/pipeline de transferência está configurado corretamente. Siga as subseções aqui para restringir o problema.

A coleção está configurada?

A configuração de Diagnóstico contém instruções para um determinado tipo de dados a ser coletado. Examine a configuração para verificar se você está enxergando apenas os dados configurados para a coleção.

O host está gerando dados?

• Contadores de desempenho: abra perfmon e verifique o contador.
• Logs de rastreamento: acesse remotamente a VM e adicione um TextWriterTraceListener ao arquivo de configuração do aplicativo. Para configurar o ouvinte de textos, confira Criar e inicializar ouvintes de rastreamento. Verifique se o elemento <trace> tem <trace autoflush="true">. Se você não visualizar os logs de rastreamento sendo gerados, confira a seção "Mais informações sobre logs de rastreamento ausentes".
• Rastreamentos do ETW (Rastreamento de Eventos para Windows): acesso remoto à VM e instalação da ferramenta PerfView. Em PerfView, execute Arquivo>Comando do Usuário>Escutar etwprovder1>etwprovider2, e assim por diante. O comando Escutar diferencia letras maiúsculas de minúsculas e não pode haver espaços entre a lista separada por vírgulas dos provedores do ETW. Se o comando falhar na execução, selecione o botão Log na parte inferior direita da ferramenta PerfView para ver o que tentou executar e qual foi o resultado. Supondo que a entrada está correta, uma nova janela aparecerá. Em alguns segundos, você verá rastreamentos do ETW.
• Logs de vento: Acesso remoto na VM. Abra o Visualizador de Eventos e verifique se os eventos existem.

Os dados estão sendo capturados localmente?

Em seguida, certifique-se de que os dados estão sendo capturados localmente. Os dados são armazenados localmente em arquivos *.tsf no armazenamento local para dados de diagnóstico. Diferentes tipos de logs coletados em diferentes arquivos .tsf. Os nomes são semelhantes aos nomes de tabela no Armazenamento do Microsoft Azure.

Por exemplo, os contadores de desempenho são coletados em PerformanceCountersTable.tsf. Os logs de eventos são coletados em WindowsEventLogsTable.tsf. Utilize as instruções na seção Extração de log local para abrir os arquivos de coleção local e verifique se estão coletados no disco.

Se não for possível visualizar logs sendo coletados localmente e você já verificou que o host está gerando dados, provavelmente há um problema de configuração. Revise a configuração cuidadosamente.

Examine também a configuração que foi gerada para MonitoringAgent MaConfig.xml. Verifique se há uma seção que descreve a origem do log relevante. Em seguida, verifique se isso não está perdido na tradução entre a configuração do Diagnóstico e a configuração do agente de monitoramento.

Os dados estão sendo transferidos?

Se você verificou que os dados estão sendo capturados localmente, mas ainda não é possível visualizá-los na conta de armazenamento, siga as estas etapas:

• Verifique se você forneceu uma conta de armazenamento correta e que não substituiu as chaves para a conta de armazenamento fornecida. Para os Serviços de Nuvem do Azure, às vezes os usuários não atualizam useDevelopmentStorage=true.
• Verifique se a conta de armazenamento fornecida está correta. Verifique se você não possui restrições de rede impedindo que os componentes alcancem os pontos de extremidade do armazenamento público. Uma maneira de fazer isso é entrar por acesso remoto no computador e tentar gravar algo na mesma conta de armazenamento.
• Finalmente, é possível observar quais falhas estão sendo relatadas pelo agente de monitoramento. O agente de monitoramento grava os logs em maeventtable.tsf que está localizado no armazenamento local para dados de diagnóstico. Siga as instruções da seção Extração de log local para abrir esse arquivo. m seguida, tente determinar se há errors, que indicam falhas de leitura para arquivos locais gravando no armazenamento.

Capturar e arquivar logs

Caso esteja pensando em contatar o suporte, a primeira ação que poderão solicitar a você é coletar os logs do seu computador. Você pode poupar tempo fazendo isso você mesmo. Execute o utilitário CollectGuestLogs.exe no caminho do utilitário de coleta de logs. Ele gera um arquivo .zip com todos os logs do Azure relevantes na mesma pasta.

Tabelas dos dados de diagnósticos não encontradas

As tabelas no armazenamento do Azure que contêm eventos do ETW são nomeadas usando o código a seguir:

        if (String.IsNullOrEmpty(eventDestination)) {
            if (e == "DefaultEvents")
                tableName = "WADDefault" + MD5(provider);
            else
                tableName = "WADEvent" + MD5(provider) + eventId;
        }
        else
            tableName = "WAD" + eventDestination;

Veja um exemplo:

        <EtwEventSourceProviderConfiguration provider="prov1">
          <Event id="1" />
          <Event id="2" eventDestination="dest1" />
          <DefaultEvents />
        </EtwEventSourceProviderConfiguration>
        <EtwEventSourceProviderConfiguration provider="prov2">
          <DefaultEvents eventDestination="dest2" />
        </EtwEventSourceProviderConfiguration>

"EtwEventSourceProviderConfiguration": [
    {
        "provider": "prov1",
        "Event": [
            {
                "id": 1
            },
            {
                "id": 2,
                "eventDestination": "dest1"
            }
        ],
        "DefaultEvents": {
            "eventDestination": "DefaultEventDestination",
            "sinks": ""
        }
    },
    {
        "provider": "prov2",
        "DefaultEvents": {
            "eventDestination": "dest2"
        }
    }
]

Esse código gera quatro tabelas:

Referências

Confira as referências a seguir

Verificar a configuração da extensão do Diagnóstico

A maneira mais fácil de verificar sua configuração de extensão é acessar o Azure Resource Explorer. Em seguida, vá até a máquina virtual ou serviço de nuvem onde está a extensão do Diagnóstico (IaaSDiagnostics/PaaDiagnostics).

Como alternativa, acesse a área de trabalho remota na máquina e examine o arquivo de configuração do Diagnóstico descrito na seção do caminho de artefatos de log.

Em ambos os casos, pesquise por Microsoft.Azure.Diagnostics e por xmlCfg ou WadCfg.

Se estiver pesquisando em uma máquina virtual e o campo WadCfg estiver presente, isso significa que a configuração está no formato JSON. Se o campo xmlCfg estiver presente, significa que a configuração está em XML e codificada em base64. Você precisa decodificá-la para ver o XML que foi carregado pelo Diagnóstico.

Para a função do serviço de nuvem, se você usar a configuração do disco, os dados estão codificados em base64. Será necessário decodificá-la para ver o XML que foi carregado pelo Diagnóstico.

Códigos de saída do plug-in do Diagnóstico do Azure

O plug-in retorna os seguintes códigos de saída:

Extração de log local

O agente de monitoramento coleta logs e artefatos como arquivos .tsf. O arquivo .tsf não está legível, mas você poderá convertê-lo em um .csv da seguinte maneira:

<Azure diagnostics extension package>\Monitor\x64\table2csv.exe <relevantLogFile>.tsf

Um novo arquivo chamado <relevantLogFile>.csv será criado no mesmo caminho correspondente do arquivo .tsf.

Mais informações sobre logs de rastreamento ausentes

• Verifique se DiagnosticMonitorTraceListener está configurado no web.config ou app.config. Isso é configurado por padrão em projetos de serviço de nuvem. No entanto, alguns clientes comentam isso, fazendo com que as instruções de rastreamento não sejam coletadas pelo Diagnóstico.
• Se os logs não estiverem sendo gravados pelo método OnStart ou Run, verifique se DiagnosticMonitorTraceListener está no app.config. Por padrão, ele está no web.config, mas isso se aplica somente à execução de código dentro de w3wp.exe. Portanto, é necessário que ele esteja no app.config para capturar rastreamentos executando no WaIISHost.exe.
• Verifique se você está utilizando Diagnostics.Trace.TraceXXX em vez de Diagnostics.Debug.WriteXXX. As instruções de depuração são removidas de uma compilação de versão.
• Certifique-se de que o código compilado realmente tenha as linhas Diagnostics.Trace. Use Reflector, ildasm ou ILSpy para verificar. Os comandos Diagnostics.Trace são removidos do binário compilado, a menos que você utilizes o símbolo de compilação condicional TRACE. Esse é um problema comum que ocorre ao utilizar o MSBuild para compilar um projeto.

Problemas e mitigações conhecidos

Os seguintes problemas conhecidos têm mitigações.

Dependência do .NET 4.5

A Extensão do Diagnóstico do Azure possui uma dependência de runtime no .NET Framework 4.5 ou posterior. No momento da gravação, todos os computadores provisionados para os Serviços de Nuvem do Azure, além de todas as imagens oficiais baseadas em máquinas virtuais do Azure, têm o .NET 4.5 ou posterior instalado.

Ainda é possível encontrar uma situação em que você tenta executar a Extensão do Diagnóstico do Azure para Windows em uma máquina que não tenha o .NET 4.5 ou posterior. Essa situação acontece quando você cria o computador a partir de uma imagem antiga ou instantâneo, ou quando você traz seu próprio disco personalizado.

Esse problema geralmente se manifesta como um código de saída 255 ao executar DiagnosticsPluginLauncher.exe. A falha ocorre devido à seguinte exceção sem tratamento:

System.IO.FileLoadException: Could not load file or assembly 'System.Threading.Tasks, Version=1.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies

Mitigação: Instala o .NET 4.5 ou posterior na máquina.

Os dados dos contadores de desempenho estão disponíveis no armazenamento, mas não aparecem no portal

A experiência do portal nas VMs mostra determinados contadores de desempenho por padrão. Se não for possível visualizar os contadores de desempenho, mas você souber que os dados estão sendo gerados porque estão disponíveis no armazenamento, verifique o seguinte:

• Se os dados armazenados possuem nomes dos contadores no idioma inglês. Se os nomes dos contadores não estiverem em inglês, o gráfico de métrica do portal não os reconhecerá.

  • Mitigação: altera o idioma do computador para inglês para as contas do sistema. Para fazes isso, selecione Painel de Controle>Região>Administrativo>Copiar Configurações. Em seguida, limpe Tela de boas-vindas e contas do sistema de modo que o idioma personalizado não seja aplicado à conta do sistema.

• Se estiver utilizando caracteres curinga (*) nos nomes do contador de desempenho, o portal não poderá correlacionar o contador coletado e configurado quando os contadores de desempenho forem enviados ao coletor do Armazenamento do Microsoft Azure.

  • Mitigação: para garantir que você possa usar curingas e fazer com que o portal expanda o (*), encaminhe seus contadores de desempenho para o coletor Azure Monitor.