Compartilhar via

Solucionar problemas de syslog com Azure Monitor Agent no Linux

Use este artigo para diagnosticar e resolver problemas em que os eventos de syslog em uma VM do Linux não são coletados ou encaminhados para um workspace Log Analytics por Azure Monitor Agent.

Durante a instalação, o Azure Monitor Agent instala uma configuração de saída para o daemon syslog do sistema. Essa configuração define como encaminhar eventos do daemon para Azure Monitor Agent. Você pode encontrá-lo em:

  • /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf para rsyslog (a maioria das distribuições do Linux)
  • /etc/syslog-ng/conf.d/azuremonitoragent-tcp.conf para syslog-ng

O Agente do Azure Monitor escuta em uma porta TCP (registrada em /etc/opt/microsoft/azuremonitoragent/config-cache/syslog.port) para receber eventos de rsyslog ou syslog-ng. Ele filtra esses eventos com base em valores de facilidade ou severidade definidos na regra de coleta de dados (DCR) localizada em /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/. O agente descarta eventos que não correspondem à configuração do DCR.

Observação

Antes da versão 1.28, Azure Monitor Agent usava um soquete de domínio Unix em vez de uma porta TCP para receber eventos do rsyslog. O omfwd módulo de saída no rsyslog oferece mecanismos de spool e repetição para melhorar a confiabilidade.

Azure Monitor Agent analisa mensagens de syslog de entrada de acordo com RFC3164 e RFC5424 e também dá suporte a formatos other. Ele determina o endpoint de destino para cada evento do DCR e tenta carregar os eventos corretamente.

Observação

  • Se o Azure Monitor Agent estiver inacessível ou enfrentando atrasos, o daemon syslog armazena temporariamente os eventos usando suas filas internas.
  • Se Azure Monitor Agent não carregar eventos recebidos de rsyslog ou syslog-ng, ele os enfileira em /var/opt/microsoft/azuremonitoragent/events usando seu mecanismo de persistência local.

Diagnosticar falhas de upload do syslog

Se Azure Monitor Agent receber com êxito eventos de syslog de rsyslog ou syslog-ng, mas os dados não aparecerem no workspace Log Analytics, as causas mais comuns estarão relacionadas à conectividade, configuração ou autenticação – não ao uso de disco local.

As causas mais comuns incluem:

  • A REGRA de Coleta de Dados (DCR) não está associada ao computador
    Se você não associar um DCR (ou se associar o DCR errado), Azure Monitor Agent não saberá para onde enviar os dados.

  • O DCR não inclui uma fonte de dados do syslog ou a instalação/gravidade não corresponde
    Nesse caso, Azure Monitor Agent descarta os eventos depois de recebê-los.

  • A máquina não pode alcançar os pontos de extremidade de ingestão do Azure Monitor
    Essa condição geralmente é causada por:

    • Restrições de firewall de saída
    • Má configuração de Proxy
    • Ausência de tags de serviço ou de pontos de extremidade necessários em redes restritas

  • A configuração de TLS ou proxy impede conexões de saída
    Se um proxy for necessário e não estiver configurado para Azure Monitor Agent, as tentativas de upload falharão.

  • A identidade gerenciada ou credenciais de Azure usadas pelo agente não podem ser autenticadas
    Essa condição pode ocorrer se a extensão do agente não for provisionada corretamente.

Para solucionar problemas de upload e conectividade, confira as seguintes diretrizes:

Se Azure Monitor Agent estiver recebendo eventos de syslog, mas não puder carregá-los, ele normalmente registrará erros relacionados à conectividade ou à autenticação em:

/var/opt/microsoft/azuremonitoragent/log/mdsd.err

Os dados do Rsyslog não são carregados devido ao espaço em disco completo

Sintoma

Os dados do Syslog não estão sendo carregados: Quando você inspeciona os logs de erros em /var/opt/microsoft/azuremonitoragent/log/mdsd.err, você vê entradas sobre erro ao inserir item no repositório persistente local... Sem espaço no dispositivo... semelhante ao seguinte trecho:

2021-11-23T18:15:10.9712760Z: Error while inserting item to Local persistent store syslog.error: IO error: No space left on device: While appending to file: /var/opt/microsoft/azuremonitoragent/events/syslog.error/000555.log: No space left on device

Causa

O Agente do Azure Monitor para Linux faz buffer de eventos para /var/opt/microsoft/azuremonitoragent/events antes da ingestão. Em uma instalação padrão Azure Monitor Agent para Linux, esse diretório leva cerca de 650 MB de espaço em disco em ocioso. O tamanho no disco aumenta quando ele está sob carga de registro sustentada. Ele é limpo a cada 60 segundos e reduz-se para aproximadamente 650 MB quando a carga retorna ao estado ocioso.

Confirmar o problema de disco cheio

O comando df mostra quase nenhum espaço disponível em /dev/sda1, conforme mostrado na saída a seguir. Você deve examinar o item de linha que se correlaciona ao diretório de log (por exemplo, /var/log, /varou /).

df -h

Filesystem Size  Used Avail Use% Mounted on
udev        63G     0   63G   0% /dev
tmpfs       13G  720K   13G   1% /run
/dev/sda1   29G   29G  481M  99% /
tmpfs       63G     0   63G   0% /dev/shm
tmpfs      5.0M     0  5.0M   0% /run/lock
tmpfs       63G     0   63G   0% /sys/fs/cgroup
/dev/sda15 105M  4.4M  100M   5% /boot/efi
/dev/sdb1  251G   61M  239G   1% /mnt
tmpfs       13G     0   13G   0% /run/user/1000

Você pode usar o comando du para inspecionar o disco para determinar quais arquivos estão fazendo com que o disco esteja cheio. Por exemplo:

cd /var/log
du -h syslog*

6.7G    syslog
18G     syslog.1

Em alguns casos, du pode não relatar arquivos ou diretórios grandes. É possível que um arquivo marcado como (excluído) esteja ocupando o espaço. Essa situação pode acontecer quando um processo tenta excluir um arquivo, mas um processo diferente ainda tem o arquivo aberto.

Você pode usar o comando lsof para verificar tais arquivos. No exemplo a seguir, você verá que /var/log/syslog está marcado como excluído, mas ocupa 3,6 GB de espaço em disco. Ele não é excluído porque um processo com o PID 1484 ainda tem o arquivo aberto.

sudo lsof +L1

COMMAND   PID   USER   FD   TYPE DEVICE   SIZE/OFF NLINK  NODE NAME
none      849   root  txt    REG    0,1       8632     0 16764 / (deleted)
rsyslogd 1484 syslog   14w   REG    8,1 3601566564     0 35280 /var/log/syslog (deleted)

A configuração padrão do rsyslog registra todas as instalações em /var/log/

Em algumas distribuições populares, como o Ubuntu 18.04 LTS, o rsyslog é fornecido com um arquivo de configuração padrão (/etc/rsyslog.d/50-default.conf). Essa configuração registra eventos de quase todas as instalações em disco em /var/log/syslog. Os eventos do Syslog da família RedHat são armazenados em /var/log/, mas em um arquivo diferente: /var/log/messages.

Azure Monitor Agent não depende dos eventos do Syslog que estão sendo registrados no /var/log/. Em vez disso, ele configura o serviço rsyslog para encaminhar eventos em uma porta TCP diretamente no processo de serviço de azuremonitoragent (mdsd).

Remover recursos de alto volume da configuração padrão do rsyslog

Se você estiver enviando um volume do log alto por meio do rsyslog e seu sistema estiver configurado para registrar eventos para essas instalações, considere modificar a configuração padrão do rsyslog para evitar o registro em log e armazená-lo em /var/log/. Os eventos para esta instalação ainda são encaminhados para o Agente do Azure Monitor porque o rsyslog usa uma configuração distinta para o encaminhamento colocado em /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf.

  1. Para evitar que os eventos local4 sejam registrados em /var/log/syslog ou /var/log/messages, altere a linha no /etc/rsyslog.d/50-default.conf a partir deste trecho:

    *.*;auth,authpriv.none          -/var/log/syslog

    Para este trecho (adicione local4.none;):

    *.*;local4.none;auth,authpriv.none          -/var/log/syslog

  2. sudo systemctl restart rsyslog

Próximas Etapas 

Se as etapas neste artigo não resolverem o problema, confira:

  • Last updated on