Solucionar problemas com o agente do Log Analytics para Linux

Este artigo fornece ajuda para solucionar erros que podem ocorrer com o agente do Log Analytics para Linux no Azure Monitor.

Ferramenta de solução de problemas Log Analytics

A ferramenta de solução de problemas do agente do Log Analytics para Linux é um script criado para ajudar a localizar e diagnosticar problemas com o agente do Log Analytics. Ela é incluída automaticamente com o agente na instalação. A execução da ferramenta deve ser a primeira etapa no diagnóstico de um problema.

Usar a ferramenta de solução de problemas

Para executar a ferramenta de solução de problemas, cole o seguinte comando em uma janela do terminal em um computador com o agente do Log Analytics:

sudo /opt/microsoft/omsagent/bin/troubleshooter

Instalação manual

A ferramenta de solução de problemas é incluída automaticamente na instalação do agente do Log Analytics. Se a instalação falhar de alguma forma, você também poderá instalar a ferramenta manualmente:

1. Verifique se o GDB (depurador de projeto GNU) está instalado no computador, pois a solução de problemas depende dele.
2. Copie o pacote de solução de problemas em seu computador: wget https://raw.github.com/microsoft/OMS-Agent-for-Linux/master/source/code/troubleshooter/omsagent_tst.tar.gz
3. Descompacte o pacote: tar -xzvf omsagent_tst.tar.gz
4. Execute a instalação manual: sudo ./install_tst

Cenários cobertos

A ferramenta de solução de problemas verifica os seguintes cenários:

• O agente não está íntegro, a pulsação não funciona corretamente.
• O agente não é iniciado ou não consegue se conectar ao Log Analytics.
• O syslog do agente não está funcionando.
• O agente tem um alto uso de CPU ou memória.
• O agente tem problemas de instalação.
• Os logs personalizados do agente não estão funcionando.
• Os logs do agente não podem ser coletados.

Para obter mais informações, confira a documentação da ferramenta de solução de problemas no GitHub.

Limpar e reinstalar o agente do Linux

Uma reinstalação limpa do agente corrige a maioria dos problemas. Essa tarefa pode ser a primeira sugestão da nossa equipe de suporte para colocar o agente em um estado não corrompido. A execução da ferramenta Coletor de logs e da ferramenta Solução de problemas e a tentativa de uma reinstalação limpa ajuda a resolver problemas com mais rapidez.

1. Baixar o script de limpeza:

   $ wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/tools/purge_omsagent.sh

2. Execute o script de limpeza (com permissões sudo):

   $ sudo sh purge_omsagent.sh

Locais de logs importantes e a ferramenta Coletor de logs

Recomendamos que você use a ferramenta Coletor de logs para recuperar logs importantes para solução de problemas ou antes de enviar um problema do GitHub. Para obter mais informações sobre a ferramenta e como executá-la, confira Coletor de logs do agente Linux do OMS.

Arquivos de configuração importantes

Códigos de erro de instalação

Códigos de erro de integração

Habilitar o log de depuração

Depuração do plug-in de saída do OMS

O FluentD permite níveis de registro específicos do plugin, permitindo que você especifique diferentes níveis de log para entradas e saídas. Para especificar um nível de log diferente para a saída do OMS, edite a configuração geral do agente em /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf.

No plug-in de saída do OMS, antes do final do arquivo de configuração, altere a propriedade log_level de info para debug:

<match oms.** docker.**>
  type out_oms
  log_level debug
  num_threads 5
  buffer_chunk_limit 5m
  buffer_type file
  buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms*.buffer
  buffer_queue_limit 10
  flush_interval 20s
  retry_limit 10
  retry_wait 30s
</match>

O log de depuração permite que você veja os uploads em lotes para o Azure Monitor separados por tipo, número de itens de dados e tempo necessário para o envio.

Veja um exemplo de log habilitado para depuração:

Success sending oms.nagios x 1 in 0.14s
Success sending oms.omi x 4 in 0.52s
Success sending oms.syslog.authpriv.info x 1 in 0.91s

Saída detalhada

Em vez de usar o plug-in de saída do OMS, também é possível emitir itens de dados diretamente para stdout, o que fica visível no arquivo de log do agente Log Analytics para Linux.

No arquivo de configuração do agente geral do Log Analytics em /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf, comente o plug-in de saída do OMS adicionando um # na frente de cada linha:

#<match oms.** docker.**>
#  type out_oms
#  log_level info
#  num_threads 5
#  buffer_chunk_limit 5m
#  buffer_type file
#  buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms*.buffer
#  buffer_queue_limit 10
#  flush_interval 20s
#  retry_limit 10
#  retry_wait 30s
#</match>

Abaixo do plug-in de saída, remova a marca de comentário da seguinte seção removendo o # na frente de cada linha:

<match **>
  type stdout
</match>

Problema: não é possível fazer a conexão por meio do proxy ao Azure Monitor

Causas prováveis

• O proxy especificado durante a integração estava incorreto.
• Os pontos de extremidade de serviço do Azure Monitor e da Automação do Azure não estão incluídos na lista de aprovados no datacenter.

Resolução

1. Reintegrar-se ao Azure Monitor com o agente de Log Analytics para Linux usando o seguinte comando com a opção -v habilitada. Isso permite a saída detalhada do agente que está se conectando por meio do proxy ao Azure Monitor: /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key> -p <Proxy Conf> -v

2. Examine a seção Atualizar as configurações de proxy para verificar se você configurou corretamente o agente para se comunicar por meio de um servidor proxy.

3. Verifique duas vezes se os pontos de extremidade descritos na lista de requisitos de firewall de rede do Azure Monitor foram adicionados corretamente a uma lista de permissões. Se você usa a Automação do Azure, as etapas de configuração de rede necessárias também estão vinculadas acima.

Problema: você recebe um erro 403 quando tentar integrar

Causas prováveis

• A data e a hora estão incorretas no servidor Linux.
• A ID do workspace e a chave do workspace não estão corretas.

Resolução

1. Verifique a hora no servidor Linux com o comando date. Se a hora for +/-15 minutos em relação à hora atual, a integração falhará. Para corrigir essa situação, atualize a data e/ou o fuso horário do servidor Linux.
2. Verifique se que você instalou a última versão do agente do Log Analytics para Linux. A versão mais recente agora notifica se a distorção de horário está causando a falha de integração.
3. Faça a reintegração usando a ID do workspace e a chave do workspace corretas nas instruções de instalação no início deste artigo.

Problema: Você vê um erro 404 e 500 no arquivo de log logo após a integração

Esse é um problema conhecido que ocorre durante o primeiro upload de dados do Linux em um workspace do Log Analytics. Esse problema não afeta os dados que são enviados nem a experiência do serviço.

Problema: o omiagent está usando 100% da CPU

Causas prováveis

A regressão no pacote nss-pem v1.0.3-5.el7 causou um problema de desempenho grave. Temos visto esse problema surgir muito nas distribuições do Redhat/CentOS 7.x. Para saber mais sobre esse problema, confira 1667121 Regressão de desempenho em libcurl.

Os bugs relacionados ao desempenho não acontecem o tempo todo e são muito difíceis de reproduzir. Se você tiver esse problema com o omiagent, use o script omiHighCPUDiagnostics.sh, que coletará o rastreamento de pilha do omiagent quando ele exceder um certo limite.

1. Baixar o script:
   wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/tools/LogCollector/source/omiHighCPUDiagnostics.sh

2. Execute o diagnóstico por 24 horas com um limite de CPU de 30%:
   bash omiHighCPUDiagnostics.sh --runtime-in-min 1440 --cpu-threshold 30

3. A pilha de chamadas será despejada no arquivo omiagent_trace. Se você observar muitas chamadas de função curl e NSS, siga estas etapas de resolução.

Resolução

1. Atualize o pacote nss-pem para v1.0.3-5.el7_6.1:
   sudo yum upgrade nss-pem

2. Se nss-pem não estiver disponível para atualização, o que acontece muito no CentOS, faça o downgrade do curl para 7.29.0-46. Se, por engano, você executar "yum update", o curl será atualizado para 7.29.0-51 e o problema ocorrerá novamente:
   sudo yum downgrade curl libcurl

3. Reiniciar o OMI:
   sudo scxadmin -restart

Problema: você não está vendo as mensagens do Syslog encaminhadas

Causas prováveis

• A configuração aplicada ao servidor Linux não permite a coleta dos recursos e/ou dos níveis de log enviados.
• O Syslog não está sendo encaminhado corretamente para o servidor Linux.
• O número de mensagens que estão sendo encaminhadas por segundo é muito grande para a configuração básica do agente do Log Analytics para o Linux manipular.

Resolução

• Verifique se a configuração no espaço de trabalho do Log Analytics para o Syslog tem todos os recursos e os níveis de log corretos. Examine configurar a coleção do Syslog no portal do Azure.
• Verifique se os daemons do sistema de mensagens Syslog nativos (rsyslog, syslog-ng) podem receber as mensagens encaminhadas.
• Verifique as configurações de firewall no servidor Syslog para garantir que as mensagens não estejam sendo bloqueadas.
• Simule uma mensagem do Syslog para o Log Analytics usando o comando logger:
  logger -p local0.err "This is my test message"

Problema: você está recebendo o endereço Errno já em uso no arquivo de log do omsagent

Se aparecer [error]: unexpected error error_class=Errno::EADDRINUSE error=#<Errno::EADDRINUSE: Address already in use - bind(2) for "127.0.0.1" port 25224> em omsagent.log.

Causas prováveis

Esse erro indica que a extensão de diagnóstico do Linux (LAD) está instalada lado a lado com a extensão de VM do Linux do Log Analytics. Ela está usando a mesma porta para coleta de dados do Syslog que o omsagent.

Resolução

1. Como raiz, execute os comandos a seguir. Observe que 25224 é um exemplo e é possível que no seu ambiente você veja um número da porta diferente usado pelo LAD.

   /opt/microsoft/omsagent/bin/configure_syslog.sh configure LAD 25229
   
   sed -i -e 's/25224/25229/' /etc/opt/microsoft/omsagent/LAD/conf/omsagent.d/syslog.conf
   

   Em seguida, você precisa editar o arquivo de configuração rsyslogd ou syslog_ng correto e alterar a configuração relacionada ao LAD para gravar na porta 25229.

2. Se a VM estiver executando rsyslogd, o arquivo a ser modificado será /etc/rsyslog.d/95-omsagent.conf (se existir, caso contrário, será /etc/rsyslog). Se a VM estiver executando syslog_ng, o arquivo a ser modificado será /etc/syslog-ng/syslog-ng.conf.

3. Reinicie o omsagent sudo /opt/microsoft/omsagent/bin/service_control restart.

4. Reinicie o serviço Syslog.

Problema: você não consegue desinstalar o omsagent usando a opção de limpeza

Causas prováveis

• A extensão de diagnóstico do Linux está instalada.
• O extensão de diagnóstico do Linux foi instalada e desinstalada, mas você ainda vê um erro sobre o uso do omsagent pelo mdsd e ele não pode ser removido.

Resolução

1. Desinstale a extensão de diagnóstico do Linux.
2. Remova os arquivos de extensão de diagnóstico do Linux do computador, se eles estiverem presentes no seguinte local: /var/lib/waagent/Microsoft.Azure.Diagnostics.LinuxDiagnostic-<version>/ e /var/opt/microsoft/omsagent/LAD/.

Problema: não é possível ver os dados do Nagios

Causas prováveis

• O usuário do omsagent não tem permissões para ler o arquivo de log do Nagios.
• A origem e o filtro do Nagios não tiveram a marca de comentário removida do arquivo omsagent.conf.

Resolução

1. Adicione o usuário omsagent para ler o arquivo Nagios seguindo estas instruções.

2. No arquivo de configuração geral do agente do Log Analytics para Linux em /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf, assegure-se de que ambos fonte e filtro do Nagios não estejam comentados.

   <source>
     type tail
     path /var/log/nagios/nagios.log
     format none
     tag oms.nagios
   </source>
   
   <filter oms.nagios>
     type filter_nagios_log
   </filter>
   

Problema: você não está vendo nenhum dado do Linux

Causas prováveis

• Falha na integração ao Azure Monitor.
• A conexão com o Azure Monitor está bloqueada.
• A máquina virtual foi reinicializada.
• O pacote OMI foi atualizado manualmente para uma versão mais recente em comparação com a instalada pelo pacote do agente do Log Analytics para Linux.
• O OMI está congelado, bloqueando o agente do OMS.
• Erro classe não encontrada dos logs de recurso do DSC no arquivo de log omsconfig.log.
• O agente do Log Analytics para dados é submetido a backup.
• Logs DSC A configuração atual não existe. Execute o comando Start-DscConfiguration com o parâmetro -Path para especificar um arquivo de configuração e criar uma configuração atual primeiro. no arquivo de log omsconfig.log, mas não existe mensagem de log sobre operações PerformRequiredConfigurationChecks.

Resolução

1. Instale todas as dependências como o pacote auditd.

2. Verifique se a integração ao Azure Monitor foi bem-sucedida verificando se o seguinte arquivo existe: /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf. Se não foi, faça a reintegração usando as instruções da linha de comando omsadmin.sh.

3. Se estiver usando um proxy, verifique as etapas de solução de problemas de proxy acima.

4. Em alguns sistemas de distribuição do Azure, o daemon do servidor OMI OMID não é iniciado após a reinicialização da máquina virtual. Se esse for o caso, você não verá dados relacionados à solução Audit, ChangeTracking ou UpdateManagement. A solução alternativa é iniciar manualmente o server OMI executando sudo /opt/omi/bin/service_control restart.

5. Depois que o pacote OMI é atualizado manualmente para uma versão mais recente, ele precisa ser reiniciado manualmente para que o agente do Log Analytics continue funcionando. Esta etapa é necessária para algumas distribuições em que o servidor OMI não é iniciado automaticamente após a atualização. Execute sudo /opt/omi/bin/service_control restart para reiniciar o OMI.

   Em algumas situações, o OMI pode ficar congelado. O agente do OMS pode inserir um estado bloqueado aguardando o OMI, bloqueando todas as coletas de dados. O processo do agente do OMS será executado, mas não haverá nenhuma atividade, o que é evidenciados pela ausência de uma nova linha de log (como pulsações enviadas) presentes em omsagent.log. Reinicie o OMI com sudo /opt/omi/bin/service_control restart para recuperar o agente.

6. Se aparecer ao erro classe não localizada do recurso DSC no omsconfig.log, execute sudo /opt/omi/bin/service_control restart.

7. Em alguns casos, quando o agente do Log Analytics para Linux não pode se comunicar com o Azure Monitor, é feito backup dos dados no agente para o tamanho total do buffer, de 50 MB. O agente deve ser reiniciado executando o seguinte comando: /opt/microsoft/omsagent/bin/service_control restart.

   Observação

   Esse problema foi corrigido na versão do agente 1.1.0-28 ou posterior.

   • Se o arquivo de log omsconfig.log não indicar que as operações PerformRequiredConfigurationChecks estão sendo executadas periodicamente no sistema, poderá haver um problema com o trabalho/serviço cron. Verifique se o trabalho cron existe em /etc/cron.d/OMSConsistencyInvoker. Se necessário, execute os seguintes comandos para criar a trabalho cron:

     mkdir -p /etc/cron.d/
     echo "*/15 * * * * omsagent /opt/omi/bin/OMSConsistencyInvoker >/dev/null 2>&1" | sudo tee /etc/cron.d/OMSConsistencyInvoker
     

   • Além disso, verifique se que o serviço de cron está em execução. Você pode usar service cron status com Debian, Ubuntu e SUSE ou service crond status com RHEL, CentOS e Oracle Linux para verificar o status desse serviço. Se o serviço não existir, você poderá instalar os binários e iniciar o serviço usando as seguintes instruções:

     Ubuntu/Debian

     # To Install the service binaries
     sudo apt-get install -y cron
     # To start the service
     sudo service cron start
     

     SUSE

     # To Install the service binaries
     sudo zypper in cron -y
     # To start the service
     sudo systemctl enable cron
     sudo systemctl start cron
     

     RHEL/CentOS

     # To Install the service binaries
     sudo yum install -y crond
     # To start the service
     sudo service crond start
     

     Oracle Linux

     # To Install the service binaries
     sudo yum install -y cronie
     # To start the service
     sudo service crond start
     

Problema: ao configurar a coleta no portal para contadores de desempenho do Syslog ou do Linux, as configurações não são aplicadas

Causas prováveis

• O agente do Log Analytics para Linux não selecionou a configuração mais recente.
• As configurações alteradas no portal não foram aplicadas.

Resolução

Background: omsconfig é o agente do Log Analytics para o agente de configuração do Linux que procura nova configuração do lado do portal a cada cinco minutos. Essa configuração é então aplicada ao agente do Log Analytics para arquivos de configuração do Linux localizados em /etc/opt/microsoft/omsagent/conf/omsagent.conf.

Em alguns casos, o agente do Log Analytics para o agente de configuração do Linux pode não conseguir se comunicar com o serviço de configuração do portal. Esse cenário faz com que a configuração mais recente não seja aplicada.

1. Verifique se o agente omsconfig está instalado executando dpkg --list omsconfig ou rpm -qi omsconfig. Se ele não estiver instalado, reinstale a última versão do agente do Log Analytics para Linux.

2. Verifique se o agente omsconfig pode se comunicar com o Azure Monitor executando o seguinte comando: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'. Esse comando retorna a configuração que o agente recebe do serviço, incluindo as configurações de Syslog, os contadores de desempenho do Linux e os logs personalizados. Se este comando falhar, execute o seguinte comando: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'. Esse comando força o agente omsconfig a se comunicar com o Azure Monitor e recuperar a configuração mais recente.

Problema: você não está vendo os dados de log personalizados

Causas prováveis

• Falha na integração ao Azure Monitor.
• A configuração Aplicar a configuração a seguir aos meus servidores Linux não foi selecionada.
• O omsconfig não selecionou a configuração de log customizada mais recente do serviço.
• O usuário omsagent do agente do Log Analytics para Linux não pode acessar o log personalizado devido a permissões ou porque não foi encontrado. Você pode ver os seguintes erros:
  • [DATETIME] [warn]: file not found. Continuing without tailing it.
  • [DATETIME] [error]: file not accessible by omsagent.
• Problema conhecido com a condição de corrida corrigida no agente do Log Analytics para Linux versão 1.1.0-217.

Resolução

1. Verifique se a integração ao Azure Monitor foi bem-sucedida verificando se o seguinte arquivo existe: /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf. Caso não esteja, tente:

   1. Fazer a reintegração usando as instruções da linha de comando do omsadmin.sh.
   2. Em Configurações avançadas no portal do Azure, verifique se a configuração Aplicar a seguinte configuração aos meus servidores Linux está habilitada.

2. Verifique se o agente omsconfig pode se comunicar com o Azure Monitor executando o seguinte comando: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'. Esse comando retorna a configuração que o agente recebe do serviço, incluindo as configurações de Syslog, os contadores de desempenho do Linux e os logs personalizados. Se este comando falhar, execute o seguinte comando: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'. Esse comando força o agente omsconfig a se comunicar com o Azure Monitor e recuperar a configuração mais recente.

Background: Em vez do agente do Log Analytics para Linux sendo executado como um usuário privilegiado - root, o agente é executado como o usuário omsagent. Na maioria dos casos, a permissão explícita precisa ser concedida a esse usuário para que determinados arquivos sejam lidos. Para conceder permissão para o usuário omsagent, execute os seguintes comandos:

1. Adicione o usuário omsagent ao grupo específico: sudo usermod -a -G <GROUPNAME> <USERNAME>.
2. Permita o acesso de leitura universal ao arquivo necessário: sudo chmod -R ugo+rx <FILE DIRECTORY>.

Há um problema conhecido com uma condição de corrida do agente do Log Analytics na versão do Linux anterior à 1.1.0-217. Depois de atualizar para o agente mais recente, execute o seguinte comando para obter a última versão do plug-in de saída: sudo cp /etc/opt/microsoft/omsagent/sysconf/omsagent.conf /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf.

Problema: você está tentando reintegrar em um novo workspace

Quando você tenta inserir novamente um agente em um novo workspace, a configuração do agente do Log Analytics precisa ser limpa antes de reenquadrar. Para limpar a configuração antiga do agente, execute o pacote do shell com --purge:

sudo sh ./omsagent-*.universal.x64.sh --purge

Ou

sudo sh ./onboard_agent.sh --purge

Você poderá continuar a reintegração depois de usar a opção --purge.

Problema: a extensão do agente do Log Analytics no portal do Azure é marcada com um estado de falha: falha no provisionamento

Causas prováveis

• O agente do Log Analytics foi removido do sistema operacional.
• O serviço do agente do Log Analytics está inoperante, desabilitado ou não configurado.

Resolução

1. Remover a extensão do portal do Azure.
2. Instale o agente seguindo as instruções.
3. Reinicie o agente executando o seguinte comando:
   sudo /opt/microsoft/omsagent/bin/service_control restart.
4. Aguarde alguns minutos até que o estado de aprovisionamento mude para Provisionamento bem-sucedido.

Problema: a atualização do agente do Log Analytics sob demanda

Causas prováveis

Os pacotes do agente do Log Analytics no host estão desatualizados.

Resolução

1. Verifique a última versão nesta página do GitHub.

2. Baixe o script de instalação (1.4.2-124 é uma versão de exemplo):

   wget https://github.com/Microsoft/OMS-Agent-for-Linux/releases/download/OMSAgent_GA_v1.4.2-124/omsagent-1.4.2-124.universal.x64.sh
   

3. Atualizar pacotes executando sudo sh ./omsagent-*.universal.x64.sh --upgrade.

Problema: a instalação está falhando informando que o Python2 não dá suporte a ctypes, embora o Python3 esteja sendo usado

Causas prováveis

Para esse problema conhecido, se o idioma da VM não estiver em inglês, uma verificação falhará ao identificar qual versão do Python está sendo usada. Isso leva o agente a sempre supor que o Python2 esteja sendo usado e a falhar quando não existe nenhum Python2.

Resolução

Altere o idioma do ambiente da VM para inglês:

export LANG=en_US.UTF-8