Resolução de problemas do Diagnóstico do Azure
Este artigo descreve informações de solução de problemas relevantes para usar o Diagnóstico do Azure. Para obter mais informações sobre Diagnóstico, consulte Visão geral do Diagnóstico do Azure.
Componentes lógicos
Os componentes são:
- Diagnostics Plug-in Launcher (DiagnosticsPluginLauncher.exe): Inicia a extensão Diagnostics. Ele serve como o processo de ponto de entrada.
- Plug-in de diagnóstico (DiagnosticsPlugin.exe): Configura, inicia e gerencia o tempo de vida do agente de monitoramento. É o processo principal que é lançado pelo lançador.
- Agente de monitoramento (processos MonAgent*.exe): monitora, coleta e transfere os dados de diagnóstico.
Caminhos de log/artefato
Os caminhos a seguir levam a alguns logs e artefatos importantes. Referimo-nos a esta informação ao longo deste artigo.
Serviços Cloud do Azure
Artefacto | Caminho |
---|---|
Arquivo de configuração do Diagnóstico do Azure | %SystemDrive%\Packages\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics<version>\Config.txt |
Ficheiros de registo | C:\Logs\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics<versão>\ |
Armazenamento local para dados de diagnóstico | C:\Resources\Directory<CloudServiceDeploymentID>.<RoleName>. DiagnosticStore\WAD0107\Tabelas |
Arquivo de configuração do agente de monitoramento | C:\Resources\Directory<CloudServiceDeploymentID>.<RoleName>. DiagnosticStore\WAD0107\Configuração\MaConfig.xml |
Pacote de extensão do Azure Diagnostics | %SystemDrive%\Packages\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics<versão> |
Caminho do utilitário de coleta de log | %SystemDrive%\Pacotes\GuestAgent\ |
Arquivo de log MonAgentHost | C:\Resources\Directory<CloudServiceDeploymentID>.<RoleName>. DiagnosticStore\WAD0107\Configuration\MonAgentHost.<seq_num>.log |
Máquinas virtuais
Artefacto | Caminho |
---|---|
Arquivo de configuração do Diagnóstico do Azure | C:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<version>\RuntimeSettings |
Ficheiros de registo | C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>\ |
Armazenamento local para dados de diagnóstico | C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>\WAD0107\Tables |
Arquivo de configuração do agente de monitoramento | C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>\WAD0107\Configuration\MaConfig.xml |
Arquivo de status | C:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<version>\Status |
Pacote de extensão do Azure Diagnostics | C:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion> |
Caminho do utilitário de coleta de log | C:\WindowsAzure\Logs\WaAppAgent.log |
Arquivo de log MonAgentHost | C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>\WAD0107\Configuration\MonAgentHost.<seq_num>.log |
Os dados métricos 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 ver os dados no portal, verifique a WADMetrics\*
tabela na conta de armazenamento de diagnóstico para ver se os registros de métrica correspondentes estão lá e verifique se o provedor de recursos Microsoft.Insights está registrado.
Aqui, o PartitionKey
da tabela é a ID do recurso, a máquina virtual ou o conjunto de escala da máquina virtual. RowKey
é o nome da métrica. Também é conhecido como o nome do contador de desempenho.
Se o ID do recurso estiver incorreto, verifique Diagnostics Configuration>Metrics>ResourceId para ver se o ID do recurso está definido corretamente.
Se não houver dados para a métrica específica, verifique Diagnostics Configuration>PerformanceCounter para ver se a métrica (contador de desempenho) está incluída. Ativamos os seguintes contadores por padrão:
- \Processador(_Total)% Tempo do processador
- \Memory\Available Bytes
- \ASP.NET Aplicativos(total)\Solicitações/s
- \ASP.NET Aplicativos(Total)\Total de erros/s
- \ASP.NET\Solicitações enfileiradas
- \ASP.NET\Solicitações rejeitadas
- \Processor(w3wp)% Tempo do processador
- \Processo(w3wp)\Bytes privados
- \Process(WaIISHost)% Tempo do processador
- \Process(WaIISHost)\Bytes Privados
- \Process(WaWorkerHost)% Tempo do Processador
- \Process(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 definida corretamente, mas você ainda não conseguir ver os dados da métrica, use as diretrizes a seguir para ajudá-lo a solucionar problemas.
O Diagnóstico do Azure não inicia
Para obter informações sobre por que o Diagnóstico falhou ao iniciar, consulte os arquivos DiagnosticsPluginLauncher.log e DiagnosticsPlugin.log no local dos arquivos de log fornecidos anteriormente.
Se esses logs indicarem Monitoring Agent not reporting success after launch
, isso significa que houve uma falha ao iniciar MonAgentHost.exe. Observe os logs no local indicado para o MonAgentHost
arquivo de log na seção anterior "Máquinas virtuais".
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 encontrar um código de saída negativo, consulte a tabela de códigos de saída na secção Referências.
Os dados de diagnóstico não são registados no Armazenamento do Azure
Determine se nenhum dos dados aparece ou se alguns deles aparecem.
Logs de infraestrutura de diagnóstico
O Diagnóstico registra todos os erros nos logs de infraestrutura de Diagnóstico. Certifique-se de ter ativado a captura de logs de infraestrutura de Diagnóstico em sua configuração. Em seguida, você pode procurar rapidamente quaisquer erros relevantes que apareçam na DiagnosticInfrastructureLogsTable
tabela em sua conta de armazenamento configurada.
Não são apresentados dados
O motivo mais comum pelo qual os dados de eventos não aparecem é que as informações da conta de armazenamento são definidas incorretamente.
Solução: corrija a configuração do Diagnóstico e reinstale o Diagnóstico.
Se a conta de armazenamento estiver configurada corretamente, acesso remoto à máquina 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 O Diagnóstico do Azure não é iniciado.
Se os processos estiverem em execução, vá para Os dados estão sendo capturados localmente e siga as instruções lá.
Se ainda houver um problema, tente:
- Desinstale o agente.
- Remova o diretório C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics.
- Instale o agente novamente.
Falta parte dos dados
Se você estiver recebendo alguns dados, mas não todos, isso significa que o pipeline de coleta/transferência de dados está definido corretamente. Siga as subseções aqui para reduzir o problema.
A coleção está configurada?
A configuração de Diagnóstico contém instruções para um tipo específico de dados a serem coletados. Revise sua configuração para verificar se você está procurando apenas os dados que configurou para a coleção.
O host está gerando dados?
- Contadores de desempenho: Abra
perfmon
e verifique o contador. - Logs de rastreamento: acesso remoto à VM e adicione um
TextWriterTraceListener
ao arquivo de configuração do aplicativo. Para configurar o ouvinte de texto, consulte Criar e inicializar ouvintes de rastreamento. Certifique-se de que o<trace>
elemento tem<trace autoflush="true">
. Se você não vir logs de rastreamento sendo gerados, consulte a seção "Mais sobre logs de rastreamento ausentes". - Rastreamento de eventos para rastreamentos do Windows (ETW): acesso remoto à VM e instale a ferramenta PerfView. No PerfView, execute File>User Command>Listen etwprovder1>etwprovider2 e assim por diante. O comando Listen diferencia maiúsculas de minúsculas e não pode haver espaços entre a lista separada por vírgulas de provedores ETW. Se o comando falhar na execução, selecione Log no canto inferior direito da ferramenta PerfView para ver o que tentou ser executado e qual foi o resultado. Supondo que a entrada esteja correta, uma nova janela será aberta. Em poucos segundos, você verá os vestígios do ETW.
- Logs de eventos: acesso remoto à VM. Abra o Visualizador de Eventos e certifique-se de que 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 são coletados em diferentes arquivos .tsf. Os nomes são semelhantes aos nomes de tabela no Armazenamento do Azure.
Por exemplo, os contadores de desempenho são coletados em PerformanceCountersTable.tsf. Os logs de eventos são coletados em WindowsEventLogsTable.tsf. Use as instruções na seção Extração de log local para abrir os arquivos de coleção local e verificar se eles são coletados no disco.
Se você não vir logs sendo coletados localmente e já tiver verificado que o host está gerando dados, provavelmente terá um problema de configuração. Reveja cuidadosamente a sua configuração.
Além disso, revise a configuração que foi gerada para o MonitoringAgent MaConfig.xml. Verifique se há uma seção que descreve a fonte de log relevante. Em seguida, verifique se ele não está perdido na conversão entre a configuração do Diagnóstico e a configuração do agente de monitoramento.
Os dados estão a ser transferidos?
Se você verificou que os dados estão sendo capturados localmente, mas ainda não os vê em sua conta de armazenamento, siga estas etapas:
- Verifique se você forneceu uma conta de armazenamento correta e se não rolou 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
o . - Verifique se a conta de armazenamento fornecida está correta. Certifique-se de que não tem restrições de rede que impeçam os componentes de alcançar pontos de extremidade de armazenamento público. Uma maneira de fazer isso é acessar remotamente a máquina e tentar escrever algo na mesma conta de armazenamento.
- Finalmente, você pode ver quais falhas estão sendo relatadas pelo agente de monitoramento. O agente de monitoramento grava seus logs em maeventtable.tsf, que está localizado no armazenamento local para dados de diagnóstico. Siga as instruções na seção Extração de log local para abrir este arquivo. Em seguida, tente determinar se há
errors
falhas na leitura de arquivos locais gravando no armazenamento.
Capturar e arquivar logs
Se você está pensando em entrar em contato com o suporte, a primeira coisa que eles podem pedir é coletar logs da sua máquina. Você pode economizar tempo fazendo isso sozinho. Execute o CollectGuestLogs.exe
utilitário no caminho do utilitário de coleta de log. Ele gera um arquivo .zip com todos os logs relevantes do Azure na mesma pasta.
Tabelas de dados de diagnóstico não encontradas
As tabelas no Armazenamento do Azure que contêm eventos ETW são nomeadas usando o seguinte código:
if (String.IsNullOrEmpty(eventDestination)) {
if (e == "DefaultEvents")
tableName = "WADDefault" + MD5(provider);
else
tableName = "WADEvent" + MD5(provider) + eventId;
}
else
tableName = "WAD" + eventDestination;
Eis 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"
}
}
]
Este código gera quatro tabelas:
Evento | Nome da tabela |
---|---|
provider="prov1" <ID do evento = "1" /> | WADEvent+MD5("prov1")+"1" |
provider="prov1" <ID do evento="2" eventDestination="dest1" /> | WADdest1 |
provider="prov1" <DefaultEvents /> | WADDefault+MD5("prov1") |
provider="prov2" <DefaultEvents eventDestination="dest2" /> | WADdest2 |
Referências
Confira as referências a seguir
Verifique a configuração da extensão de diagnóstico
A maneira mais fácil de verificar sua configuração de extensão é ir para o Azure Resource Explorer. Em seguida, vá para a máquina virtual ou serviço de nuvem onde a extensão Diagnostics (IaaSDiagnostics / PaaDiagnostics) está.
Como alternativa, a área de trabalho remota na máquina e examine o arquivo de configuração de Diagnóstico descrito na seção Caminho dos artefatos de log.
Em ambos os casos, procure Microsoft.Azure.Diagnostics e o campo xmlCfg ou WadCfg .
Se você 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 está codificada em base64. Você precisa decodificá-lo para ver o XML que foi carregado pelo Diagnóstico.
Para a função de serviço de nuvem, se você escolher a configuração do disco, os dados serão codificados em base64. Você precisará decodificá-lo para ver o XML que foi carregado pelo Diagnóstico.
Códigos de saída do plug-in do Azure Diagnostics
O plug-in retorna os seguintes códigos de saída:
Código de saída | Description |
---|---|
0 | Êxito. |
-1 | Erro genérico. |
-2 | Não é possível carregar o arquivo rcf. Esse erro interno só deve acontecer se o iniciador de plug-in do agente convidado for invocado manualmente incorretamente na VM. |
-3 | Não é possível carregar o arquivo de configuração de diagnóstico. Solução: causada por um arquivo de configuração que não passa na validação do esquema. A solução é fornecer um arquivo de configuração que esteja em conformidade com o esquema. |
-4 | Outra instância do Diagnóstico do agente de monitoramento já está usando o diretório de recursos local. Solução: especifique um valor diferente para LocalResourceDirectory. |
-6 | O iniciador de plug-in do agente convidado tentou iniciar o Diagnóstico com uma linha de comando inválida. Esse erro interno só deve acontecer se o iniciador de plug-in do agente convidado for invocado manualmente incorretamente na VM. |
-10 | O plug-in Diagnóstico foi encerrado com uma exceção não tratada. |
-11 | O agente convidado não pôde criar o processo responsável por iniciar e monitorar o agente de monitoramento. Solução: verifique se há recursos suficientes do sistema disponíveis para iniciar novos processos. |
-101 | Argumentos inválidos ao chamar o plug-in Diagnóstico. Esse erro interno só deve acontecer se o iniciador de plug-in do agente convidado for invocado manualmente incorretamente na VM. |
-102 | O processo do plug-in não consegue inicializar-se. Solução: verifique se há recursos suficientes do sistema disponíveis para iniciar novos processos. |
-103 | O processo do plug-in não consegue inicializar-se. Especificamente, não é possível criar o objeto do registrador. Solução: verifique se há recursos suficientes do sistema disponíveis para iniciar novos processos. |
-104 | Não é possível carregar o arquivo rcf fornecido pelo agente convidado. Esse erro interno só deve acontecer se o iniciador de plug-in do agente convidado for invocado manualmente incorretamente na VM. |
-105 | O plug-in Diagnóstico não pode abrir o arquivo de configuração do Diagnóstico. Esse erro interno só deve acontecer se o plug-in Diagnóstico for invocado manualmente incorretamente na VM. |
-106 | Não é possível ler o arquivo de configuração de diagnóstico. Causado por um arquivo de configuração não passar na validação do esquema. |
-107 | A passagem do diretório de recursos para o agente de monitoramento é inválida. Esse erro interno só deve acontecer se o agente de monitoramento for invocado manualmente incorretamente na VM. |
-108 | Não é possível converter o arquivo de configuração de diagnóstico no arquivo de configuração do agente de monitoramento. Esse erro interno só deve acontecer se o plug-in Diagnóstico for invocado manualmente com um arquivo de configuração inválido. |
-110 | Erro de configuração do Diagnóstico Geral. Esse erro interno só deve acontecer se o plug-in Diagnóstico for invocado manualmente com um arquivo de configuração inválido. |
-111 | Não é possível iniciar o agente de monitoramento. Solução: verifique se há recursos suficientes do sistema disponíveis. |
-112 | Erro geral. |
Extração de log local
O agente de monitoramento coleta logs e artefatos como .tsf
arquivos. O .tsf
arquivo não é legível, mas você pode convertê-lo da .csv
seguinte maneira:
<Azure diagnostics extension package>\Monitor\x64\table2csv.exe <relevantLogFile>.tsf
Um novo arquivo chamado <relevantLogFile>.csv
é criado no mesmo caminho que o arquivo correspondente .tsf
.
Nota
Você só precisa executar este utilitário no arquivo principal .tsf
(por exemplo, PerformanceCountersTable.tsf
). Os ficheiros que os acompanham (por exemplo, PerformanceCountersTables_\*\*001.tsf
, PerformanceCountersTables_\*\*002.tsf
) são processados automaticamente.
Mais sobre logs de rastreamento ausentes
Nota
As informações a seguir se aplicam principalmente aos Serviços de Nuvem do Azure, a menos que você tenha configurado o DiagnosticsMonitorTraceListener
em um aplicativo que está sendo executado em sua VM de infraestrutura como serviço (IaaS).
- Verifique se o DiagnosticMonitorTraceListener está configurado no web.config ou app.config. Ele é configurado por padrão em projetos de serviço de nuvem. No entanto, alguns clientes comentam isso, o que faz com que as instruções de rastreamento não sejam coletadas pelo Diagnostics.
- Se os logs não estiverem sendo gravados a partir do método OnStart ou Run , verifique se o DiagnosticMonitorTraceListener está no app.config. Por padrão, ele está no web.config, mas isso só se aplica ao código em execução no w3wp.exe. Portanto, você precisa dele em app.config para capturar rastreamentos que estão sendo executados no WaIISHost.exe.
- Certifique-se de que está a utilizar Diagnostics.Trace.TraceXXX em vez de Diagnostics.Debug.WriteXXX. As instruções Debug são removidas de uma compilação de versão.
- Verifique se o código compilado realmente tem as linhas Diagnostics.Trace. Use Refletor, ildasm ou ILSpy para verificar. Os comandos Diagnostics.Trace são removidos do binário compilado, a menos que você use o símbolo de compilação condicional TRACE. Esse problema comum ocorre quando você está usando o MSBuild para criar um projeto.
Problemas conhecidos e atenuações
Os seguintes problemas conhecidos têm atenuações.
Dependência do .NET 4.5
A extensão de Diagnóstico do Azure para Windows tem uma dependência de tempo de execução no .NET Framework 4.5 ou posterior. No momento da redação deste artigo, todas as máquinas provisionadas para os Serviços de Nuvem do Azure e todas as imagens oficiais baseadas em VMs 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 de Diagnóstico do Azure para Windows em uma máquina que não tem o .NET 4.5 ou posterior. Essa situação acontece quando você cria sua máquina 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 quando você executa DiagnosticsPluginLauncher.exe. A falha acontece devido à seguinte exceção não tratada:
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
Atenuação: Instale o .NET 4.5 ou posterior em sua máquina.
Os dados dos contadores de desempenho estão disponíveis no armazenamento, mas não são exibidos no portal
A experiência do portal nas VMs mostra determinados contadores de desempenho por padrão. Se você não vir os contadores de desempenho e souber que os dados estão sendo gerados porque estão disponíveis no armazenamento, verifique se:
Se os dados armazenados têm nomes de contadores em inglês. Se os nomes dos contadores não estiverem em inglês, o gráfico métrico do portal não o reconhecerá.
- Atenuação: altere o idioma da máquina para inglês para contas do sistema. Para fazer isso, selecione Configurações de cópia administrativa>da região>do painel>de controle. Em seguida, limpe a tela de boas-vindas e as contas do sistema para que o idioma personalizado não seja aplicado à conta do sistema.
Se você estiver usando curingas (*) em seus nomes de contadores de desempenho, o portal não poderá correlacionar o contador configurado e coletado quando os contadores de desempenho forem enviados para o coletor de Armazenamento do Azure.
- Atenuação: para garantir que você possa usar curingas e fazer com que o portal expanda o (*), roteie seus contadores de desempenho para o coletor do Azure Monitor.