Compartir a través de


Guía de solución de problemas de Syslog para el Agente de Azure Monitor para Linux

Precaución

En este artículo se hace referencia a CentOS, una distribución de Linux con un estado de finalización del servicio (EOL). Tenga en cuenta su uso y planeación en consecuencia. Para más información, consulte la Guía de fin de ciclo de vida de CentOS.

Información general sobre la recopilación de Syslog del Agente de Azure Monitor para Linux y los estándares RFC admitidos:

  • El Agente de Azure Monitor instala una configuración de salida para el demonio syslog del sistema durante el proceso de instalación. El archivo de configuración especifica la forma en que fluyen los eventos entre el demonio de syslog y el Agente de Azure Monitor.
  • Para rsyslog (la mayoría de las distribuciones de Linux), el archivo de configuración es /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf. Para syslog-ng, el archivo de configuración es /etc/syslog-ng/conf.d/azuremonitoragent-tcp.conf.
  • El agente de Azure Monitor realiza la escucha en un puerto TCP para recibir eventos de rsyslog / syslog-ng. El puerto de esta comunicación se registra en /etc/opt/microsoft/azuremonitoragent/config-cache/syslog.port.

    Nota:

    Antes de la versión 1.28 del agente de Azure Monitor, usaba un socket de dominio Unix en lugar del puerto TCP para recibir eventos de rsyslog. El módulo de salida omfwd en rsyslog ofrece mecanismos de cola y reintento para mejorar la confiabilidad.

  • El demonio de Syslog usa colas cuando se retrasa la ingesta del Agente de Azure Monitor o cuando no se puede acceder al Agente de Azure Monitor.
  • El Agente de Azure Monitor ingiere eventos de Syslog a través del socket mencionado anteriormente y los filtra en función de la combinación de instalación o gravedad de la configuración de la regla de recopilación de datos (DCR) en /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/. Si facility o severity no están presentes en la DCR, se quitarán.
  • Agente de Azure Monitor intenta analizar los eventos de acuerdo con RFC3164 y RFC5424. También tiene la capacidad de analizar los formatos de mensaje enumerados en este sitio web.
  • El Agente de Azure Monitor identifica el punto de conexión de destino para los eventos de Syslog desde la configuración de la DCR e intenta cargar los eventos.

    Nota

    El Agente de Azure Monitor usa la persistencia local de forma predeterminada. Todos los eventos recibidos de rsyslog o syslog-ng se ponen en cola en /var/opt/microsoft/azuremonitoragent/events si hay un error durante la carga.

Issues

Puede que encuentre los siguientes errores.

Los datos de Rsyslog no se cargan debido a un problema de espacio en disco completo en el Agente de Azure Monitor para Linux

En las secciones siguientes se describe el problema.

Síntoma

Los datos de Syslog no se cargan: al inspeccionar los registros de errores en /var/opt/microsoft/azuremonitoragent/log/mdsd.err, verá entradas sobre Error al insertar el elemento en el almacén persistente local... No queda espacio en el dispositivo de forma similar al siguiente fragmento de código:

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

El Agente de Azure Monitor para Linux almacena en búfer eventos a /var/opt/microsoft/azuremonitoragent/events antes la ingesta. En una instalación predeterminada del Agente de Azure Monitor para Linux, este directorio ocupa aproximadamente 650 MB de espacio en disco inactivo. El tamaño en disco aumenta cuando se carga un registro de forma sostenida. Se limpia cada 60 segundos y se reduce a aproximadamente 650 MB cuando la carga vuelva a estar inactiva.

Confirmación del problema de disco lleno

El comando df muestra casi ningún espacio disponible en /dev/sda1, como se muestra en la salida siguiente. Tenga en cuenta que debe examinar el elemento de línea que se correlaciona con el directorio de registro (por ejemplo, /var/log, /var o /).

   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

Puede usar el comando du para inspeccionar el disco y determinar qué archivos hacen que esté lleno. Por ejemplo:

   cd /var/log
   du -h syslog*
6.7G    syslog
18G     syslog.1

En algunos casos, es posible que du no informe de archivos o directorios grandes. Puede que un archivo marcado como (eliminado) ocupe el espacio. Este problema puede ocurrir cuando algún otro proceso ha intentado eliminar un archivo, pero sigue habiendo un proceso con el archivo abierto. Puede utilizar el comando lsof para buscar este tipo de archivos. En el ejemplo siguiente, vemos que /var/log/syslog se ha marcado como eliminado, pero ocupa 3,6 GB de espacio en disco. No se ha eliminado porque un proceso con PID 1484 todavía tiene abierto el archivo.

   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)

La configuración predeterminada de Rsyslog registra todas las instalaciones en /var/log/

En algunas distribuciones populares (por ejemplo, Ubuntu 18.04 LTS), rsyslog se suministra con un archivo de configuración predeterminado (/etc/rsyslog.d/50-default.conf) que registra eventos de casi todas las instalaciones en el disco en /var/log/syslog. Los eventos Syslog de la familia RedHat/CentOS se almacenarán en /var/log/, pero en un archivo diferente: /var/log/messages.

Agente de Azure Monitor no depende de los eventos de Syslog que se registran en /var/log/. Alternativamente, configura el servicio rsyslog para reenviar los eventos a través de un puerto TCP directamente al proceso del servicio azuremonitoragent (mdsd).

Corrección: quitar las instalaciones de gran volumen de /etc/rsyslog.d/50-default.conf

Si va a enviar un volumen de registro alto a través de rsyslog y el sistema está configurado para registrar eventos para estas instalaciones, modifique la configuración predeterminada de rsyslog para evitar el registro y almacenarlos en /var/log/. Los eventos de esta instalación se seguirán reenviando a Agente de Azure Monitor porque rsyslog usa una configuración diferente para el reenvío que reside en /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf.

  1. Por ejemplo, para evitar que eventos local4 se registren en /var/log/syslog o /var/log/messages, reemplace la línea en /etc/rsyslog.d/50-default.conf que ve en este fragmento...:

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

    ...por este otro fragmento (agregue local4.none;):

    *.*;local4.none;auth,authpriv.none          -/var/log/syslog
    
  2. sudo systemctl restart rsyslog