Recopilación de eventos de Syslog con el agente de Azure Monitor
Los eventos de Syslog son uno de los orígenes de datos usados en una regla de recopilación de datos (DCR). Los detalles para la creación de la DCR se proporcionan en Recopilación de datos con el agente de Azure Monitor. En este artículo se proporcionan detalles adicionales para el tipo de origen de datos de eventos de Syslog.
Syslog es un protocolo de registro de eventos que es común a Linux. Puede usar el demonio de Syslog integrado en dispositivos y dispositivos Linux para recopilar eventos locales de los tipos que especifique. Las aplicaciones envían mensajes que se almacenan en la máquina local o se entregan a un recopilador de Syslog.
Sugerencia
Para recopilar datos de dispositivos que no permiten la instalación local del agente de Azure Monitor, configure un reenviador de registros basado en Linux dedicado.
Requisitos previos
- Área de trabajo de Log Analytics en la que tenga al menos derechos de colaborador. Los eventos de Syslog se envían a la tabla de Syslog.
- Una DCR nueva o existente descrita en Recopilación de datos con el agente de Azure Monitor.
Configuración de la recopilación de datos de Syslog
En el paso Recopilar y entregar de la DCR, seleccione Syslog de Linux en la lista desplegable Tipo de origen de datos.
Los recursos siguientes son compatibles con el recopilador de Syslog:
| Número de índice de prioridad | Nombre de la prioridad |
|---|---|
| {none} | No Pri |
| 0 | Kern |
| 1 | usuario |
| 2 | |
| 3 | daemon |
| 4 | auth |
| 5 | syslog |
| 6 | lpr |
| 7 | news |
| 8 | uucp |
| 9 | cron |
| 10 | authpriv |
| 11 | ftp |
| 12 | ntp |
| 13 | auditoría |
| 14 | alerta |
| 15 | clock |
| 16 | local0 |
| 17 | local1 |
| 18 | local2 |
| 19 | local3 |
| 20 | local4 |
| 21 | local5 |
| 22 | local6 |
| 23 | local7 |
De forma predeterminada, el agente recopilará todos los eventos que haya enviado la configuración de Syslog. Cambie el nivel de registro mínimo de cada instalación para limitar la recopilación de datos. Seleccione Ninguno para no recopilar ningún evento para una instalación determinada.
Destinos
Los datos de Syslog se pueden enviar a las siguientes ubicaciones.
| Destino | Tabla / Espacio de nombres |
|---|---|
| Área de trabajo de Log Analytics | Syslog |
Nota:
Las versiones 1.15.2 y posteriores del agente Linux de Azure Monitor admiten formatos RFC de Syslog, incluidos Cisco Meraki, Cisco ASA, Cisco FTD, Sophos XG, Juniper Networks, Corelight Zeek, CipherTrust, NXLog, McAfee y el formato de evento común (CEF).
Configuración de Syslog en agente de Linux
Cuando el agente de Azure Monitor está instalado en la máquina Linux, instala un archivo de configuración de Syslog predeterminado que define el recurso y la gravedad de los mensajes que se recopilan si Syslog está habilitado en DCR. El archivo de configuración es diferente según el demonio Syslog que ha instalado el cliente.
Rsyslog
En muchas distribuciones de Linux, el demonio rsyslogd es responsable de consumir, almacenar y enrutar mensajes de registro enviados mediante la API de Syslog de Linux. El agente de Azure Monitor usa el módulo de salida de reenvío TCP (omfwd) en rsyslog para reenviar mensajes de registro.
La instalación del agente de Azure Monitor incluye los archivos de configuración predeterminados ubicados en /etc/opt/microsoft/azuremonitoragent/syslog/rsyslogconf/. Cuando se agrega Syslog a una DCR, esta configuración se instala en el directorio del sistema etc/rsyslog.d y rsyslog se reiniciará automáticamente para que los cambios surtan efecto.
Nota:
En los sistemas basados en rsyslog, el agente Linux de Azure Monitor agrega reglas de reenvío al conjunto de reglas predeterminado definido en la configuración de rsyslog. Si se usan varios conjuntos de reglas, las entradas enlazadas a conjuntos de reglas no predeterminados no se reenvían al agente de Azure Monitor. Para más información sobre varios conjuntos de reglas en rsyslog, consulte la documentación oficial.
A continuación, se muestra la configuración predeterminada que recopila mensajes de Syslog enviados desde el agente local para todas las instalaciones con todos los niveles de registro.
$ cat /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf
# Azure Monitor Agent configuration: forward logs to azuremonitoragent
template(name="AMA_RSYSLOG_TraditionalForwardFormat" type="string" string="<%PRI%>%TIMESTAMP% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg%")
# queue.workerThreads sets the maximum worker threads, it will scale back to 0 if there is no activity
# Forwarding all events through TCP port
*.* action(type="omfwd"
template="AMA_RSYSLOG_TraditionalForwardFormat"
queue.type="LinkedList"
queue.filename="omfwd-azuremonitoragent"
queue.maxFileSize="32m"
queue.maxDiskSpace="1g"
action.resumeRetryCount="-1"
action.resumeInterval="5"
action.reportSuspension="on"
action.reportSuspensionContinuation="on"
queue.size="25000"
queue.workerThreads="100"
queue.dequeueBatchSize="2048"
queue.saveonshutdown="on"
target="127.0.0.1" Port="28330" Protocol="tcp")
La siguiente configuración se usa cuando se utiliza SELinux y se deciden usar sockets Unix.
$ cat /etc/rsyslog.d/10-azuremonitoragent.conf
# Azure Monitor Agent configuration: forward logs to azuremonitoragent
$OMUxSockSocket /run/azuremonitoragent/default_syslog.socket
template(name="AMA_RSYSLOG_TraditionalForwardFormat" type="string" string="<%PRI%>%TIMESTAMP% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg%")
$OMUxSockDefaultTemplate AMA_RSYSLOG_TraditionalForwardFormat
# Forwarding all events through Unix Domain Socket
*.* :omuxsock:
$ cat /etc/rsyslog.d/05-azuremonitoragent-loadomuxsock.conf
# Azure Monitor Agent configuration: load rsyslog forwarding module.
$ModLoad omuxsock
En algunos sistemas heredados, es posible que vea problemas de formato de registro de rsyslog cuando se usa un formato de reenvío tradicional para enviar eventos de Syslog al agente de Azure Monitor. Para estos sistemas, el agente de Azure Monitor coloca automáticamente una plantilla de reenviador heredada en su lugar:
template(name="AMA_RSYSLOG_TraditionalForwardFormat" type="string" string="%TIMESTAMP% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg%\n")
Syslog ng
La instalación del agente de Azure Monitor incluye los archivos de configuración predeterminados ubicados en /etc/opt/microsoft/azuremonitoragent/syslog/syslog-ngconf/azuremonitoragent-tcp.conf. Cuando se agrega una colección de Syslog a la DCR, este archivo de configuración se coloca en el directorio del sistema /etc/syslog-ng/conf.d/azuremonitoragent-tcp.conf y syslog-ng se reiniciará automáticamente para que los cambios surtan efecto.
El contenido predeterminado se muestra en el ejemplo siguiente. En este ejemplo se recopilan mensajes de Syslog enviados desde el agente local para todos los recursos y todos los niveles de gravedad.
$ cat /etc/syslog-ng/conf.d/azuremonitoragent-tcp.conf
# Azure MDSD configuration: syslog forwarding config for mdsd agent
options {};
# during install time, we detect if s_src exist, if it does then we
# replace it by appropriate source name like in redhat 's_sys'
# Forwrding using tcp
destination d_azure_mdsd {
network("127.0.0.1"
port(28330)
log-fifo-size(25000));
};
log {
source(s_src); # will be automatically parsed from /etc/syslog-ng/syslog-ng.conf
destination(d_azure_mdsd);
flags(flow-control);
};
La siguiente configuración se usa cuando se utiliza SELinux y se deciden usar sockets Unix.
$ cat /etc/syslog-ng/conf.d/azuremonitoragent.conf
# Azure MDSD configuration: syslog forwarding config for mdsd agent options {};
# during install time, we detect if s_src exist, if it does then we
# replace it by appropriate source name like in redhat 's_sys'
# Forwrding using unix domain socket
destination d_azure_mdsd {
unix-dgram("/run/azuremonitoragent/default_syslog.socket"
flags(no_multi_line) );
};
log {
source(s_src); # will be automatically parsed from /etc/syslog-ng/syslog-ng.conf
destination(d_azure_mdsd);
};
Nota:
Azure Monitor admite la recopilación de mensajes enviados por rsyslog o syslog-ng, donde rsyslog es el demonio predeterminado. El demonio de Syslog predeterminado en la versión 5 de Red Hat Enterprise Linux y Oracle Linux (sysklog) no es compatible con la recopilación de eventos de Syslog. Para recopilar datos de Syslog de esta versión de estas distribuciones, es necesario instalar el demonio rsyslog y configurarlo para reemplazar Sysklog.
Si modifica la configuración de Syslog, tiene que reiniciar el demonio Syslog para que los cambios surtan efecto.
Instalaciones admitidas
Los recursos siguientes son compatibles con el recopilador de Syslog:
| Índice Pri | Nombre de Pri |
|---|---|
| 0 | Ninguno |
| 1 | Kern |
| 2 | usuario |
| 3 | |
| 4 | daemon |
| 4 | auth |
| 5 | syslog |
| 6 | lpr |
| 7 | news |
| 8 | uucp |
| 9 | ftp |
| 10 | ntp |
| 11 | auditoría |
| 12 | alerta |
| 13 | mark |
| 14 | local0 |
| 15 | local1 |
| 16 | local2 |
| 17 | local3 |
| 18 | local4 |
| 19 | local5 |
| 20 | local6 |
| 21 | local7 |
Propiedades de registros de Syslog
Los registros de Syslog tienen un tipo Syslog y las propiedades que aparecen en la tabla siguiente.
| Propiedad | Descripción |
|---|---|
| Computer | Nombre del equipo desde el que se recopiló el evento. |
| Facility | Define la parte del sistema que ha generado el mensaje. |
| HostIP | Dirección IP del sistema que envía el mensaje. |
| HostName | Nombre del sistema que envía el mensaje. |
| SeverityLevel | Nivel de gravedad del evento. |
| SyslogMessage | Texto del mensaje. |
| ProcessID | Identificador del proceso que ha generado el mensaje. |
| EventTime | Fecha y hora en que se generó el evento. |
Consultas de registro de Syslog de ejemplo
La tabla siguiente proporciona ejemplos distintos de consultas de registro que recuperan registros de Syslog.
Todos los registros de Syslogs
SyslogTodos los registros de Syslog con gravedad de error
Syslog | where SeverityLevel == "error"Todos los registros de Syslog con el tipo de instalación de autenticación
Syslog | where facility == "auth"Número de registros de Syslog por instalación
Syslog | summarize AggregatedValue = count() by facility
Solución de problemas
Siga estos pasos si no recopila datos del registro JSON que espera.
- Compruebe que los datos se escriben en Syslog.
- Vea Comprobación de la operación para comprobar si el agente está operativo y se reciben datos.
Pasos siguientes
Más información sobre: