Resolver problemas com o agente do Log Analytics para Linux

  • Artigo

Este artigo fornece ajuda na resolução de erros que poderá deparar com o agente do Log Analytics para Linux no Azure Monitor.

Ferramenta de Resolução de Problemas do Log Analytics

O agente do Log Analytics para a Ferramenta de Resolução de Problemas do Linux é um script concebido para ajudar a encontrar e diagnosticar problemas com o agente do Log Analytics. É automaticamente incluído com o agente após a instalação. Executar a ferramenta deve ser o primeiro passo para diagnosticar um problema.

Utilizar a Ferramenta de Resolução de Problemas

Para executar a Ferramenta de Resolução de Problemas, cole o seguinte comando numa janela de terminal num computador com o agente do Log Analytics:

sudo /opt/microsoft/omsagent/bin/troubleshooter

Instalação manual

A Ferramenta de Resolução de Problemas é incluída automaticamente quando o agente do Log Analytics é instalado. Se a instalação falhar de alguma forma, também pode instalar a ferramenta manualmente:

  1. Certifique-se de que o Depurador do Projeto GNU (GDB) está instalado no computador porque a resolução de problemas depende do mesmo.
  2. Copie o pacote de resolução de problemas para o 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 abrangidos

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

  • O agente está em mau estado de funcionamento; o heartbeat não funciona corretamente.
  • O agente não inicia ou não consegue ligar-se ao Log Analytics.
  • O agente Syslog não está a funcionar.
  • O agente tem uma utilização elevada da CPU ou da memória.
  • O agente tem problemas de instalação.
  • Os registos personalizados do agente não estão a funcionar.
  • Os registos do agente não podem ser recolhidos.

Para obter mais informações, veja a documentação da Ferramenta de Resolução de Problemas no GitHub.

Nota

Execute a ferramenta Recoletor de Registos quando tiver um problema. Ter os registos inicialmente ajudará a nossa equipa de suporte a resolver o problema mais rapidamente.

Remover e reinstalar o agente Linux

Uma reinstalação limpa do agente corrige a maioria dos problemas. Esta tarefa pode ser a primeira sugestão da nossa equipa de suporte para colocar o agente num estado não correlacionado. Executar a Ferramenta de Resolução de Problemas e a ferramenta Recoletor de Registos e tentar reinstalar de forma limpa ajuda a resolver os problemas mais rapidamente.

  1. Transfira o script de remoção:

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

  2. Execute o script de remoção (com permissões sudo):

    $ sudo sh purge_omsagent.sh

Localizações de registo importantes e a ferramenta Recoletor de Registos

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

Recomendamos que utilize a ferramenta Recoletor de Registos para obter registos importantes para resolução de problemas ou antes de submeter um problema do GitHub. Para obter mais informações sobre a ferramenta e como executá-la, veja Recoletor de Registos do Agente Linux do OMS.

Ficheiros de configuração importantes

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

Nota

A edição de ficheiros de configuração para contadores de desempenho e Syslog é substituída se a coleção estiver configurada a partir da configuração do agente no portal do Azure da área de trabalho. Para desativar a configuração de todos os agentes, desative a recolha da gestão de agentes legados. 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 Uma vez que 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. Pacote de instalação auditado.
2 Opção inválida fornecida ao pacote de shell. Execute sudo sh ./omsagent-*.universal*.sh --help para utilização.
3 Não foi fornecida nenhuma opção para o pacote de shell. Execute sudo sh ./omsagent-*.universal*.sh --help para utilização.
4 Tipo de pacote inválido ou definiçõ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 utilize o instalador universal a partir da versão mais recente. Reveja também para verificar as definições de proxy.
5 O pacote de shell tem de ser executado como raiz ou foi devolvido um erro 403 durante a integração. Execute o comando com sudo.
6 Arquitetura de pacote inválida ou foi devolvido um erro 200 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. Veja a saída do comando para a falha de raiz.
18 Falha na instalação do pacote OMSConfig. Veja a saída do comando para a falha de raiz.
19 Falha na instalação do pacote OMI. Veja a saída do comando para a falha de raiz.
20 Falha na instalação do pacote SCX. Veja a saída do comando para a falha de raiz.
21 Falha na instalação dos Kits de fornecedor. Veja a saída do comando para a falha de raiz.
22 Falha na instalação do pacote agrupado. Veja a saída do comando para a falha de raiz
23 O pacote SCX ou OMI já está instalado. Utilize --upgrade em vez de instalar o pacote de --install shell.
30 Erro interno do pacote. Submeta um problema do GitHub com os detalhes da saída.
55 A versão openssl não suportada ou não consegue ligar ao Azure Monitor ou o dpkg está bloqueado ou está em falta no programa curl.
61 Biblioteca de tipos de ctypes Python em falta. Instale a biblioteca ou pacote de ctypes do Python (python-ctypes).
62 Falta o programa tar. Instale o tar.
63 Programa de sed em falta. Instalar sed.
64 Programa curl em falta. Instale o curl.
65 Programa gpg em falta. 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 utilização.
3 Configuração inválida fornecida ao script omsadmin. Executar sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h para utilização.
4 Proxy inválido fornecido para o script omsadmin. Verifique o proxy e veja a nossa documentação para utilizar 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 não 200 recebido do Azure Monitor. Veja a saída completa do script omsadmin para obter detalhes.
7 Não é possível ligar ao Azure Monitor. Veja a saída completa do script omsadmin para obter detalhes.
8 Erro ao integrar na área de trabalho do Log Analytics. Veja a saída completa do script omsadmin para obter detalhes.
30 Erro de script interno. Submeta um problema do GitHub com os detalhes da saída.
31 Erro ao gerar o ID do agente. Submeta um problema do GitHub com os 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. Submeta um problema do GitHub com os detalhes da saída.
34 O script de geração de metaconfiguração não está presente. Repita a integração com sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key>.

Ativar o registo de depuração

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

O FluentD permite níveis de registo específicos do plug-in que lhe permitem especificar diferentes níveis de registo para entradas e saídas. Para especificar um nível de registo 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 fim do ficheiro de configuração, altere a log_level propriedade 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 registo de depuração permite-lhe ver carregamentos em lotes para o Azure Monitor separados por tipo, número de itens de dados e tempo de envio.

Eis um exemplo de registo ativado 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 verbosa

Em vez de utilizar o plug-in de saída do OMS, pode produzir itens de dados diretamente para stdouto , que está visível no ficheiro de registo do Agente do Log Analytics para Linux.

No ficheiro 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 ao adicionar um # à 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>

Por baixo do plug-in de saída, anule o comentário da secção seguinte ao remover a # frente de cada linha:

<match **>
  type stdout
</match>

Problema: Não é possível ligar através do proxy ao Azure Monitor

Causas prováveis

  • O proxy especificado durante a inclusão estava incorreto.
  • Os pontos finais de serviço do Azure Monitor e do Automatização do Azure não estão incluídos na lista aprovada no datacenter.

Resolução

  1. Reonboard to Azure Monitor with the Log Analytics agent for Linux by using the following command with the option -v enabled. Permite a saída verbosa do agente que se liga através do proxy ao Azure Monitor: /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key> -p <Proxy Conf> -v

  2. Reveja a secção Atualizar definições de proxy para verificar se configurou corretamente o agente para comunicar através de um servidor proxy.

  3. Verifique novamente se os pontos finais descritos na lista de requisitos de firewall de rede do Azure Monitor são adicionados corretamente a uma lista de permissões. Se utilizar Automatização do Azure, os passos de configuração de rede necessários também estão ligados acima.

Problema: Recebe um erro 403 ao tentar integrar

Causas prováveis

  • A data e a hora estão incorretas no servidor Linux.
  • O ID da área de trabalho e a chave da área de trabalho não estão corretos.

Resolução

  1. Verifique a hora no servidor Linux com a data de comando. Se a hora for +/- 15 minutos a partir da hora atual, a inclusão falhará. Para corrigir esta situação, atualize a data e/ou fuso horário do servidor Linux.
  2. Verifique se instalou a versão mais recente do agente do Log Analytics para Linux. A versão mais recente notifica-o agora se a distorção de tempo estiver a causar a falha de integração.
  3. Volte a integrar utilizando o ID da área de trabalho e a chave de área de trabalho corretos nas instruções de instalação anteriores neste artigo.

Problema: verá um erro 500 e 404 no ficheiro de registo logo após a integração

Este é um problema conhecido que ocorre no primeiro carregamento de dados do Linux para uma área de trabalho do Log Analytics. Este problema não afeta os dados que estão a ser enviados ou a experiência de 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 este problema surgir muito nas distribuições Redhat/CentOS 7.x. Para saber mais sobre este problema, veja 1667121 Regressão de desempenho em libcurl.

Os erros relacionados com o desempenho não acontecem a toda a hora e são difíceis de reproduzir. Se tiver este problema com o omiagent, utilize o script omiHighCPUDiagnostics.sh, que recolherá o rastreio de pilha do omiagent quando exceder um determinado limiar.

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

  2. Execute diagnósticos durante 24 horas com o limiar de 30% da CPU:
    bash omiHighCPUDiagnostics.sh --runtime-in-min 1440 --cpu-threshold 30

  3. A pilha de chamadas será despejada no ficheiro de omiagent_trace. Se notar muitas chamadas de funções curl e NSS, siga estes passos 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 principalmente no CentOS, mude o curl para 7.29.0-46. Se executar a "atualização yum" por engano, o curl será atualizado para a versão 7.29.0-51 e o problema voltará a acontecer:
    sudo yum downgrade curl libcurl

  3. Reiniciar 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 recolha das instalações enviadas ou dos níveis de registo.
  • O Syslog não está a ser reencaminhado corretamente para o servidor Linux.
  • O número de mensagens a serem reencaminhadas por segundo é demasiado grande para a configuração base do agente do Log Analytics para Linux processar.

Resolução

  • Verifique se a configuração na área de trabalho do Log Analytics do Syslog tem todas as instalações e os níveis de registo corretos. Reveja a configuração da coleção Syslog no portal do Azure.
  • Verifique se os daemons de mensagens Syslog nativos (rsyslog, syslog-ng) podem receber as mensagens reencaminhadas.
  • Verifique as definições da firewall no servidor Syslog para garantir que as mensagens não estão a ser bloqueadas.
  • Simule uma mensagem do Syslog para o Log Analytics com 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

[error]: unexpected error error_class=Errno::EADDRINUSE error=#<Errno::EADDRINUSE: Address already in use - bind(2) for "127.0.0.1" port 25224> Verá 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. Está a utilizar a mesma porta para a recolha de dados do Syslog que o omsagent.

Resolução

  1. Como raiz, execute os seguintes comandos. Tenha em atenção que 25224 é um exemplo e é possível que, no seu ambiente, veja um número de porta diferente utilizado 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, tem de editar o ficheiro correto rsyslogd ou syslog_ng de configuração e alterar a configuração relacionada com LAD para escrever na porta 25229.

  2. Se a VM estiver a executar rsyslogd, o ficheiro a modificar será /etc/rsyslog.d/95-omsagent.conf (se existir, senão /etc/rsyslog). Se a VM estiver em execução syslog_ng, o ficheiro a modificar 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 com a opção de remoção

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 continua a ver um erro sobre o omsagent que está a ser utilizado pelo mdsd e não pode ser removido.

Resolução

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

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

Causas prováveis

  • O utilizador omsagent não tem permissões para ler a partir do ficheiro de registo nagios.
  • A origem e o filtro Nagios não foram descommentes do ficheiro omsagent.conf.

Resolução

  1. Adicione o utilizador omsagent para ler a partir do ficheiro Nagios ao seguir estas instruções.

  2. No ficheiro de configuração geral do agente do Log Analytics para Linux em /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf, certifique-se de que a origem e o filtro nagios não estão consolidados.

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

<filter oms.nagios>
  type filter_nagios_log
</filter>

Problema: Não está a ver dados do Linux

Causas prováveis

  • Falha na integração no Azure Monitor.
  • A ligação ao Azure Monitor está bloqueada.
  • A máquina virtual foi reiniciada.
  • 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.
  • A OMI está bloqueada, a bloquear o agente do OMS.
  • Erro de classe de registos de recursos do DSC não encontrado no omsconfig.log ficheiro de registo.
  • É criada uma cópia de segurança do agente do Log Analytics para dados.
  • Registos DSC A configuração atual não existe. Execute Start-DscConfiguration comando com o parâmetro -Path para especificar um ficheiro de configuração e criar primeiro uma configuração atual. no omsconfig.log ficheiro de registo, mas não existe nenhuma mensagem de registo sobre PerformRequiredConfigurationChecks operações.

Resolução

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

  2. Verifique se a inclusão no Azure Monitor foi bem-sucedida ao verificar se existe o seguinte ficheiro: /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf. Se não tiver sido, volte a integrar com as instruções da linha de comandos omsadmin.sh.

  3. Se estiver a utilizar um proxy, verifique os passos de resolução de problemas do proxy anteriores.

  4. Em alguns sistemas de distribuição do Azure, o daemon do servidor OMI omid não é iniciado depois de a máquina virtual ser reiniciada. Se for este o caso, não verá dados relacionados com a solução Auditoria, ChangeTracking ou UpdateManagement. A solução é iniciar manualmente o servidor OMI ao executar sudo /opt/omi/bin/service_control restart.

  5. Depois de o pacote OMI ser atualizado manualmente para uma versão mais recente, tem de ser reiniciado manualmente para que o agente do Log Analytics continue a funcionar. Este passo é necessário para algumas distribuições em que o servidor OMI não é iniciado automaticamente depois de ser atualizado. Execute sudo /opt/omi/bin/service_control restart para reiniciar o OMI.

    Em algumas situações, a OMI pode ficar congelada. O agente do OMS pode entrar num estado bloqueado à espera do OMI, que bloqueia toda a recolha de dados. O processo do agente do OMS será executado, mas não haverá atividade, o que é evidenciado por nenhuma nova linha de registo (como heartbeats enviados) 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 recursos DSC não encontrado em 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, é efetuada uma cópia de segurança dos dados no agente para o tamanho da memória intermédia total de 50 MB. O agente deve ser reiniciado ao executar o seguinte comando: /opt/microsoft/omsagent/bin/service_control restart.

    Nota

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

    • Se o omsconfig.log ficheiro de registo não indicar que PerformRequiredConfigurationChecks as operações estão a ser executadas periodicamente no sistema, poderá existir um problema com a tarefa/serviço cron. Certifique-se de que a tarefa cron existe em /etc/cron.d/OMSConsistencyInvoker. Se necessário, execute os seguintes comandos para criar a tarefa 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. Pode utilizar service cron status com Debian, Ubuntu e SUSE ou service crond status com RHEL, CentOS e Oracle Linux para verificar o estado deste serviço. Se o serviço não existir, pode instalar os binários e iniciar o serviço com 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 configura a coleção a partir do portal para contadores de desempenho do Syslog ou do Linux, as definições não são aplicadas

Causas prováveis

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

Resolução

Fundo:omsconfig é o agente do Log Analytics para o agente de configuração do Linux que procura uma nova configuração do lado do portal a cada cinco minutos. Em seguida, esta configuração é aplicada ao agente do Log Analytics para ficheiros 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 poderá não conseguir comunicar com o serviço de configuração do portal. Este cenário resulta na não aplicação da configuração mais recente.

  1. Verifique se o omsconfig agente está instalado ao executar 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 consegue comunicar com o omsconfig Azure Monitor ao executar o seguinte comando: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'. Este comando devolve a configuração que o agente recebe do serviço, incluindo definições do Syslog, contadores de desempenho do Linux e registos 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 a obter a configuração mais recente.

Problema: Não está a ver dados de registo personalizados

Causas prováveis

  • Falha ao integrar no Azure Monitor.
  • A definição Aplicar a seguinte configuração aos meus Servidores Linux não foi selecionada.
  • omsconfig não recolheu a configuração de registo personalizado mais recente do serviço.
  • O agente do Log Analytics para o utilizador omsagent do Linux não consegue aceder ao registo personalizado devido a permissões ou não foi 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 race corrigido no agente do Log Analytics para Linux versão 1.1.0-217.

Resolução

  1. Verifique se a inclusão no Azure Monitor foi efetuada com êxito ao verificar se existe o seguinte ficheiro: /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf. Caso contrário, também:

    1. Volte a integrar com as instruções da linha de comandos omsadmin.sh.
    2. Em Definições Avançadas no portal do Azure, certifique-se de que a definição Aplicar a seguinte configuração aos meus Servidores Linux está ativada.

  2. Verifique se o agente consegue comunicar com o omsconfig Azure Monitor ao executar o seguinte comando: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'. Este comando devolve a configuração que o agente recebe do serviço, incluindo definições do Syslog, contadores de desempenho do Linux e registos 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 a falar com o omsconfig Azure Monitor e a obter a configuração mais recente.

Fundo: Em vez do agente do Log Analytics para Linux em execução como um utilizador com privilégios , rooto agente é executado como o omsagent utilizador. Na maioria dos casos, tem de ser concedida permissão explícita a este utilizador para que determinados ficheiros sejam lidos. Para conceder permissão ao omsagent utilizador, execute os seguintes comandos:

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

Existe um problema conhecido com uma condição race com o agente do Log Analytics para Linux anterior à versão 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: está a tentar voltar a integrar uma nova área de trabalho

Quando tenta voltar a integrar um agente numa nova área de trabalho, a configuração do agente do Log Analytics tem de ser limpa antes de voltar a integrar. Para limpar a configuração antiga do agente, execute o pacote de shell com --purge:

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

Ou

sudo sh ./onboard_agent.sh --purge

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

Problema: a extensão do agente do Log Analytics no portal do Azure está marcada com um estado de falha: Falha no aprovisionamento

Causas prováveis

  • O agente do Log Analytics foi removido do sistema operativo.
  • O serviço do agente do Log Analytics está inativo, desativado ou não está configurado.

Resolução

  1. Remova a extensão do portal do Azure.
  2. Instale o agente ao seguir as instruções.
  3. Reinicie o agente ao executar o seguinte comando:
    sudo /opt/microsoft/omsagent/bin/service_control restart.
  4. Aguarde vários minutos até que o estado de aprovisionamento mude para o Aprovisionamento com êxito.

Problema: A atualização a pedido do agente do Log Analytics

Causas prováveis

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

Resolução

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

  2. Transfira 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. Atualize os pacotes ao executar sudo sh ./omsagent-*.universal.x64.sh --upgrade.

Problema: a instalação está a falhar e diz que o Python2 não consegue suportar tipos de dados, mesmo que o Python3 esteja a ser utilizado

Causas prováveis

Para este problema conhecido, se o idioma da VM não for inglês, uma verificação falhará ao verificar que versão do Python está a ser utilizada. Este problema leva o agente a assumir sempre que o Python2 está a ser utilizado e a falhar se não existir Python2.

Resolução

Altere a linguagem ambiental da VM para inglês:

export LANG=en_US.UTF-8