Guia de solução de problemas do Syslog para o Azure Monitor Agent for Linux

  • Artigo

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.

Visão geral da coleção Syslog do Azure Monitor Agent for Linux e dos padrões RFC suportados:

  • O Azure Monitor Agent instala uma configuração de saída para o daemon Syslog do sistema durante o processo de instalação. O arquivo de configuração especifica a maneira como os eventos fluem entre o daemon Syslog e o Azure Monitor Agent.
  • Para rsyslog (a maioria das distribuições Linux), o arquivo de configuração é /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf. Para syslog-ng, o arquivo de configuração é /etc/syslog-ng/conf.d/azuremonitoragent-tcp.conf.
  • O Azure Monitor Agent escuta uma porta TCP para receber eventos do rsyslog / syslog-ng. A porta para esta comunicação é registada em /etc/opt/microsoft/azuremonitoragent/config-cache/syslog.port.

    Nota

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

  • O daemon Syslog usa filas quando a ingestão do Azure Monitor Agent está atrasada ou quando o Azure Monitor Agent não está acessível.
  • O Azure Monitor Agent ingere eventos do Syslog por meio do soquete mencionado anteriormente e os filtra com base na combinação de recursos ou gravidade da configuração da regra de coleta de dados (DCR) no /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/. Qualquer facility um ou severity não presente no DCR é descartado.
  • O Azure Monitor Agent tenta analisar eventos de acordo com RFC3164 e RFC5424. Ele também sabe como analisar os formatos de mensagem listados neste site.
  • O Azure Monitor Agent identifica o ponto de extremidade de destino para eventos Syslog da configuração DCR e tenta carregar os eventos.

    Nota

    O Azure Monitor Agent usa persistência local por padrão. Todos os eventos recebidos ou rsyslog syslog-ng enfileirados se /var/opt/microsoft/azuremonitoragent/events não forem carregados.

Problemas

Você pode encontrar os seguintes problemas.

Os dados Rsyslog não são carregados devido a um problema de espaço total em disco no Azure Monitor Agent for Linux

As próximas seções descrevem o problema.

Sintoma

Os dados do Syslog não estão sendo carregados: quando você inspeciona os logs de erro no /var/opt/microsoft/azuremonitoragent/log/mdsd.err, você vê entradas sobre Erro ao inserir o item no armazenamento persistente local... Nenhum espaço deixado 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

Motivo

O Azure Monitor Agent for Linux armazena eventos em buffer antes /var/opt/microsoft/azuremonitoragent/events da ingestão. Em uma instalação padrão do Azure Monitor Agent for Linux, esse diretório ocupa ~650 MB de espaço em disco ocioso. O tamanho no disco aumenta quando ele está sob carga de registro sustentada. Ele é limpo a cada 60 segundos e reduz de volta para ~ 650 MB quando a carga retorna à ociosidade.

Confirme o problema de um disco cheio

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

   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 du comando para inspecionar o disco para determinar quais arquivos estão fazendo com que o disco fique 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. Pode ser possível que um arquivo marcado como (excluído) esteja ocupando espaço. Esse problema pode acontecer quando algum outro processo tentou excluir um arquivo, mas um processo com o arquivo ainda está aberto. Você pode usar o lsof comando para verificar esses arquivos. No exemplo a seguir, vemos que /var/log/syslog está marcado como excluído, mas ocupa 3,6 GB de espaço em disco. Ele não foi excluído porque um processo com 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 distros populares (por exemplo, Ubuntu 18.04 LTS), o rsyslog é fornecido com um arquivo de configuração padrão (/etc/rsyslog.d/50-default.conf), que registra eventos de quase todas as instalações no disco em /var/log/syslog. Os eventos Syslog da família RedHat/CentOS são armazenados em /var/log/ , mas em um arquivo diferente: /var/log/messages.

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

Correção: Remova recursos de alto volume de /etc/rsyslog.d/50-default.conf

Se você estiver enviando um alto volume de log por meio do rsyslog e seu sistema estiver configurado para registrar eventos para esses recursos, considere modificar a configuração padrão do rsyslog para evitar registrar e armazená-los em /var/log/. Os eventos desse recurso ainda seriam encaminhados para o Azure Monitor Agent porque o rsyslog usa uma configuração diferente para encaminhamento colocado no /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf.

  1. Por exemplo, para remover local4 eventos de serem registrados em /var/log/syslog ou , altere /var/log/messagesesta linha deste /etc/rsyslog.d/50-default.conf trecho:

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

    A este trecho (adicionar local4.none;):

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

  2. sudo systemctl restart rsyslog