Partilhar via

Resolver problemas com o agente do Log Analytics para Linux

  • Artigo

Este artigo fornece ajuda na solução de erros que você pode enfrentar com o agente do Log Analytics para Linux no Azure Monitor.

Atenção

Este artigo faz referência ao CentOS, uma distribuição Linux com status de Fim de Vida (EOL). Por favor, considere o seu uso e planejamento de acordo. Para obter mais informações, consulte as diretrizes de Fim da Vida Útil do CentOS.

Ferramenta de solução de problemas do Log Analytics

O agente do Log Analytics para Linux Troubleshooting Tool é um script projetado para ajudar a localizar e diagnosticar problemas com o agente do Log Analytics. Ele é incluído automaticamente com o agente após a instalação. Executar a ferramenta deve ser o primeiro passo para diagnosticar 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 de terminal em uma máquina 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 quando o agente do Log Analytics é instalado. Se a instalação falhar de alguma forma, você também pode instalar a ferramenta manualmente:

  1. Certifique-se de que o GNU Project Debugger (GDB) esteja instalado na máquina porque a solução de problemas depende dele.
  2. Copie o pacote da resolução de problemas para a sua máquina: wget https://raw.github.com/microsoft/OMS-Agent-for-Linux/master/source/code/troubleshooter/omsagent_tst.tar.gz
  3. Desembale o pacote: tar -xzvf omsagent_tst.tar.gz
  4. Execute a instalação manual: sudo ./install_tst

Cenários abrangidos

A Ferramenta de Solução de Problemas verifica os seguintes cenários:

  • O agente não é saudável; o batimento cardíaco não funciona corretamente.
  • O agente não inicia ou não consegue se conectar ao Log Analytics.
  • O agente Syslog não está funcionando.
  • O agente tem 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, consulte a documentação da ferramenta de solução de problemas no GitHub.

Nota

Execute a ferramenta Coletor de Log quando tiver um problema. Ter os logs inicialmente ajudará nossa equipe de suporte a solucionar seu problema mais rapidamente.

Limpar e reinstalar o agente Linux

Uma reinstalação limpa do agente corrige a maioria dos problemas. Esta tarefa pode ser a primeira sugestão de nossa equipe de suporte para colocar o agente em um estado não corrompido. Executar a ferramenta Troubleshooting Tool e o Log Collector e tentar uma reinstalação limpa ajuda a resolver problemas mais rapidamente.

  1. Faça o download do script de limpeza:

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

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

    $ sudo sh purge_omsagent.sh

Locais de log importantes e a ferramenta Coletor de Log

Ficheiro Caminho
Agente do Log Analytics para arquivo de log do Linux /var/opt/microsoft/omsagent/<workspace id>/log/omsagent.log
Arquivo de log de configuração do agente do Log Analytics /var/opt/microsoft/omsconfig/omsconfig.log

Recomendamos que você use a ferramenta Coletor de Log 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, consulte OMS Linux Agent Log Collector.

Ficheiros de configuração importantes

Categoria Localização do ficheiro
Syslog /etc/syslog-ng/syslog-ng.conf ou /etc/rsyslog.conf ou /etc/rsyslog.d/95-omsagent.conf
Performance, saída Nagios, Zabbix, Log Analytics e agente geral /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf
Configurações extras /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/*.conf

Nota

A edição de arquivos de configuração para contadores de desempenho e Syslog será substituída se a coleção for configurada a partir da configuração do agente no portal do Azure para seu espaço de trabalho. Para desabilitar a configuração de todos os agentes, desative a coleta do gerenciamento de agentes herdados. Para um único agente, execute o seguinte script:

sudo /opt/microsoft/omsconfig/Scripts/OMS_MetaConfigHelper.py --disable && sudo rm /etc/opt/omi/conf/omsconfig/configuration/Current.mof* /etc/opt/omi/conf/omsconfig/configuration/Pending.mof*

Códigos de erro de instalação

Código de erro Significado
NOT_DEFINED Como as dependências necessárias não estão instaladas, o plug-in auditado auoms não será instalado. Falha na instalação de auoms. Instale o pacote auditado.
2 Opção inválida fornecida ao pacote shell. Executar sudo sh ./omsagent-*.universal*.sh --help para uso.
3 Nenhuma opção fornecida para o pacote shell. Executar sudo sh ./omsagent-*.universal*.sh --help para uso.
4 Tipo de pacote inválido ou configurações de proxy inválidas. Os pacotes omsagent-rpm.sh só podem ser instalados em sistemas baseados em RPM. Os pacotes omsagent-deb.sh só podem ser instalados em sistemas baseados em Debian. Recomendamos que você use o instalador universal da versão mais recente. Analise também para verificar suas configurações de proxy.
5 O shell bundle deve ser executado como root ou houve um erro 403 retornado durante a integração. Execute o comando usando sudo.
6 Arquitetura de pacote inválida ou houve um erro 200 retornado durante a integração. Os pacotes omsagent-*x64.sh só podem ser instalados em sistemas de 64 bits. Os pacotes omsagent-*x86.sh só podem ser instalados em sistemas de 32 bits. Transfira o pacote correto para a sua arquitetura a partir da versão mais recente.
17 Falha na instalação do pacote OMS. Examine a saída do comando para a falha raiz.
18 Falha na instalação do pacote OMSConfig. Examine a saída do comando para a falha raiz.
19 Falha na instalação do pacote OMI. Examine a saída do comando para a falha raiz.
20 Falha na instalação do pacote SCX. Examine a saída do comando para a falha raiz.
21 Falha na instalação dos kits do provedor. Examine a saída do comando para a falha raiz.
22 Falha na instalação do pacote incluído. Examine a saída do comando para a falha de raiz
23 Pacote SCX ou OMI já instalado. Use --upgrade em vez de --install instalar o pacote shell.
30 Erro de pacote interno. Arquive um problema do GitHub com detalhes da saída.
55 Versão openssl sem suporte ou não pode se conectar ao Azure Monitor ou dpkg está bloqueado ou faltando programa curl.
61 Biblioteca de tipos Python ausente. Instale a biblioteca ou pacote Python ctypes (python-ctypes).
62 Falta programa de alcatrão. Instale o alcatrão.
63 Falta programa sed. Instale o sed.
64 Faltando programa de ondulação. Instale a ondulação.
65 Falta programa gpg. Instale o gpg.

Códigos de erro de integração

Código de erro Significado
2 Opção inválida fornecida ao script omsadmin. Executar sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h para uso.
3 Configuração inválida fornecida para o script omsadmin. Executar sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h para uso.
4 Proxy inválido fornecido ao script omsadmin. Verifique o proxy e consulte nossa documentação para usar um proxy HTTP.
5 Erro HTTP 403 recebido do Azure Monitor. Veja a saída completa do script omsadmin para obter detalhes.
6 Erro HTTP diferente de 200 recebido do Azure Monitor. Veja a saída completa do script omsadmin para obter detalhes.
7 Não é possível conectar-se ao Azure Monitor. Veja a saída completa do script omsadmin para obter detalhes.
8 Erro ao integrar o espaço de trabalho do Log Analytics. Veja a saída completa do script omsadmin para obter detalhes.
30 Erro de script interno. Arquive um problema do GitHub com detalhes da saída.
31 Erro ao gerar ID do agente. Arquive um problema do GitHub com detalhes da saída.
32 Erro ao gerar certificados. Veja a saída completa do script omsadmin para obter detalhes.
33 Erro ao gerar metaconfiguração para omsconfig. Arquive um problema do GitHub com detalhes da saída.
34 Script de geração de metaconfiguração não presente. Tente integrar novamente com sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key>o .

Ativar o registo de depuração

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

O FluentD permite níveis de log específicos de plug-in que permitem especificar 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 log_level propriedade de debuginfo para :

<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 carregamentos em lote no Azure Monitor separados por tipo, número de itens de dados e tempo necessário para enviar.

Aqui está 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, você pode enviar itens de dados diretamente para stdouto , que é visível no agente do Log Analytics para o arquivo de log do Linux.

No arquivo de configuração geral do agente 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, descomente a seguinte seção removendo o # na frente de cada linha:

<match **>
  type stdout
</match>

Problema: Não é possível conectar-se por proxy ao Azure Monitor

Causas prováveis

  • O proxy especificado durante a integração estava incorreto.
  • Os pontos de extremidade do serviço Azure Monitor e Azure Automation não estão incluídos na lista aprovada em seu datacenter.

Resolução

  1. Reintegre ao Azure Monitor com o agente do Log Analytics para Linux usando o comando a seguir com a opção -v habilitada. Ele permite a saída detalhada do agente 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. Revise a seção Atualizar configurações de proxy para verificar se você configurou corretamente o agente para se comunicar por meio de um servidor proxy.

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

Problema: você recebe um erro 403 ao tentar integrar

Causas prováveis

  • A data e a hora estão incorretas no servidor Linux.
  • O ID e a chave do espaço de trabalho não estão corretos.

Resolução

  1. Verifique a hora no seu servidor Linux com a data do comando. Se o tempo for +/- 15 minutos a partir da hora atual, a integração falhará. Para corrigir essa situação, atualize a data e/ou fuso horário do seu servidor Linux.
  2. Verifique se você instalou a versão mais recente do agente do Log Analytics para Linux. A versão mais recente agora notifica se a distorção do tempo estiver causando a falha de integração.
  3. Reintegre usando a ID e a chave de espaço de trabalho corretas nas instruções de instalação anteriormente neste artigo.

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

Este é um problema conhecido que ocorre no primeiro carregamento de dados do Linux em um espaço de trabalho do Log Analytics. Esse problema não afeta os dados que estão sendo enviados ou a experiência do serviço.

Problema: vê o omiagent a utilizar 100% da CPU

Causas prováveis

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

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

  1. Faça o download do 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 limite de CPU de 30%:
    bash omiHighCPUDiagnostics.sh --runtime-in-min 1440 --cpu-threshold 30

  3. Callstack será despejado no arquivo omiagent_trace. Se você notar 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 o nss-pem não estiver disponível para atualização, o que acontece principalmente no CentOS, faça o downgrade para 7.29.0-46. Se você executar "yum update" por engano, curl será atualizado para 7.29.0-51 e o problema acontecerá novamente:
    sudo yum downgrade curl libcurl

  3. Reinicie o OMI:
    sudo scxadmin -restart

Problema: não vê as mensagens do Syslog reencaminhadas

Causas prováveis

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

Resolução

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

Problema: está a receber o erro Endereço já utilizado no ficheiro de registo omsagent

Você vê [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

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

Resolução

  1. Como root, execute os seguintes comandos. Observe que 25224 é um exemplo, e é possível que em seu ambiente você veja um número de 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 correto rsyslogd ou syslog_ng de configuração e alterar a configuração relacionada ao LAD para gravar na porta 25229.

  2. Se a VM estiver em execução rsyslogd, o arquivo a ser modificado será /etc/rsyslog.d/95-omsagent.conf (se existir, caso contrário /etc/rsyslog). Se a VM estiver em execução 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: não é possível desinstalar o omsagent usando a opção purge

Causas prováveis

  • A extensão de diagnóstico do Linux está instalada.
  • A extensão de diagnóstico do Linux foi instalada e desinstalada, mas você ainda vê um erro sobre o omsagent sendo usado 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 da máquina 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 nenhum dado do Nagios

Causas prováveis

  • O usuário do omsagent não tem permissões para ler o arquivo de log do Nagios.
  • A fonte e o filtro Nagios não foram descomentados 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, verifique se a origem e o filtro do Nagios não são 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 o que foi instalado pelo agente do Log Analytics para o pacote Linux.
  • O OMI está congelado, bloqueando o agente OMS.
  • Classe de logs de recursos DSC não encontrada erro no omsconfig.log arquivo de log.
  • É feito backup do agente do Log Analytics para dados.
  • 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 omsconfig.log arquivo de log, mas não existe nenhuma mensagem de log sobre PerformRequiredConfigurationChecks operações.

Resolução

  1. Instale todas as dependências, como o pacote auditado.

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

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

  4. Em alguns sistemas de distribuição do Azure, o daemon do servidor OMI omid não é iniciado depois que a máquina virtual é reinicializada. Se esse for o caso, você não verá os dados relacionados à solução Audit, ChangeTracking ou UpdateManagement. A solução é iniciar manualmente o servidor OMI executando sudo /opt/omi/bin/service_control restarto .

  5. Depois que o pacote OMI é atualizado manualmente para uma versão mais recente, ele deve ser reiniciado manualmente para que o agente do Log Analytics continue funcionando. Esta etapa é necessária para algumas distros em que o servidor OMI não inicia 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 entrar em um estado bloqueado aguardando o OMI, que bloqueia toda a coleta de dados. O processo do agente do OMS estará em execução, mas não haverá atividade, o que é evidenciado por nenhuma nova linha de log (como pulsações enviadas) presente no omsagent.log. Reinicie o OMI com sudo /opt/omi/bin/service_control restart para recuperar o agente.

  6. Se vir um erro de classe de recurso DSC não encontrada 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 consegue falar com o Azure Monitor, o backup dos dados no agente é feito 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.

    Nota

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

    • Se o arquivo de log não indicar que PerformRequiredConfigurationChecks as omsconfig.log operações estão sendo executadas periodicamente no sistema, pode haver um problema com o trabalho/serviço cron. Certifique-se de que o trabalho cron existe em /etc/cron.d/OMSConsistencyInvoker. Se necessário, execute os seguintes comandos para criar o 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, certifique-se de que o serviço 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 deste serviço. Se o serviço não existir, você poderá instalar os binários e iniciá-lo 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: quando você configura a coleta do portal para contadores de desempenho Syslog ou Linux, as configurações não são aplicadas

Causas prováveis

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

Resolução

Background: omsconfig é o agente de configuração do Log Analytics para Linux que procura uma 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 localizado em /etc/opt/microsoft/omsagent/conf/omsagent.conf.

Em alguns casos, o agente de configuração do Log Analytics para Linux pode não conseguir se comunicar com o serviço de configuração do portal. Esse cenário resulta na não aplicação da configuração mais recente.

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

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

Problema: você não está vendo nenhum dado de log personalizado

Causas prováveis

  • Falha na integração ao Azure Monitor.
  • A configuração Aplicar a seguinte configuração aos meus servidores Linux não foi selecionada.
  • omsconfig não pegou a configuração de log personalizada mais recente do serviço.
  • O agente do Log Analytics para Linux omsagent não consegue acessar o log personalizado devido a permissões ou não ser encontrado. Poderá 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 corrigido no agente do Log Analytics para Linux versão 1.1.0-217.

Resolução

  1. Verifique se a integração no Azure Monitor foi bem-sucedida verificando se o seguinte arquivo existe: /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf. Em caso negativo:

    1. Reintegre usando as instruções de linha de comando 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 pode se comunicar com o omsconfig Azure Monitor executando o seguinte comando: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'. Este comando retorna a configuração que o agente recebe do serviço, incluindo configurações de Syslog, contadores de desempenho do Linux e 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 a falar com o omsconfig Azure Monitor e recuperar a configuração mais recente.

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

  1. Adicione o omsagent usuário ao grupo específico: sudo usermod -a -G <GROUPNAME> <USERNAME>.
  2. Conceda 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 com o agente do Log Analytics para a versão Linux anterior à 1.1.0-217. Depois de atualizar para o agente mais recente, execute o seguinte comando para obter a versão mais recente 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 a um novo espaço de trabalho

Quando você tenta reintegrar um agente a um novo espaço de trabalho, a configuração do agente do Log Analytics precisa ser limpa antes da reintegração. Para limpar a configuração antiga do agente, execute o pacote shell com --purge:

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

Ou

sudo sh ./onboard_agent.sh --purge

Pode continuar a voltar a integrar depois de utilizar a --purge opção.

Problema: a extensão do agente do Log Analytics no portal do Azure está 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á inativo, desativado ou não configurado.

Resolução

  1. Remova 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 as alterações de estado de provisionamento para Provisionamento sejam bem-sucedidas.

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

Causas prováveis

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

Resolução

  1. Verifique a versão mais recente nesta página do GitHub.

  2. Faça o download do 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. Atualize pacotes executando sudo sh ./omsagent-*.universal.x64.sh --upgrade.

Problema: A instalação está falhando e diz que o Python2 não pode suportar ctypes, mesmo que o Python3 esteja sendo usado

Causas prováveis

Para esse problema conhecido, se o idioma da VM não for inglês, uma verificação falhará ao verificar qual versão do Python está sendo usada. Esse problema leva o agente sempre assumindo que o Python2 está sendo usado e falhando se não houver Python2.

Resolução

Altere o idioma ambiental da VM para inglês:

export LANG=en_US.UTF-8