syslog: Conceptos y configuraciones en GNU/Linux

En sistemas GNU/Linux, siempre que instalamos un servicio, lo configuramos y lo echamos a andar, necesitamos saber si se ejecutó bien, si todo va sobre rieles a la hora de proveer el servicio a los clientes, etc.
Toda esta información podemos obtenerla y monitorearla gracias a que los servicios generalmente generan eventos que son capturados por alguna implementación del protocolo syslog.
Por lo tanto, podremos configurar la forma en que los eventos son administrados por el syslog, y saber y administrar los archivos de registros de logs.

El protocolo y los mensajes

syslog es un protocolo de mensajería de eventos, y existen distintas implementaciones de software para darle vida. syslog-ng y rsyslog son dos muy conocidas. Hoy veremos la configuración de rsyslog, primeramente porque es la implementación que está disponible en el Debian por defecto.
Los mensajes se componen de dividen en tres partes:

• priority: que a su vez se divide en numero de recurso y severidad del mensaje. Recursos válidos son por ejemplo, kernel, daemon, clock, ftp, mail, authentication, etc (no entraremos en detalles particulares, solo a modo práctico). Las severidades van desde 0 como una severidad alta, o emerg (de emergency) hasta 7 como severidad baja, o mensaje de depuración (debug), pasando por alert, critic, error, warning, notice e info.
• header: un header con información de estampa de tiempo en la que se generó el evento, equipo que lo generó, con su hostname o ip.
• text: texto propio del mensaje, que describe a nivel de usuario/administrador, el motivo del evento.

Rsyslog y su configuración

La implementación que veremos es rsyslog, que viene por default en Debian, y que puede instalarse desde la mayoría de los gestores de repositorios en las demás distribuciones.
El archivo de configuración por defecto es /etc/rsyslog.conf

En este archivo podremos establecer entre otros parámetros, las reglas de logs según la siguiente estructura por línea:

servicio.prioridad    accion

Donde servicio es alguno de los mencionados más arriba, prioridad es una severidad del mensaje, y acción representa qué es lo que haremos cuando el rsyslog reciba un mensaje de cierto servicio/prioridad especificados.

Veamos algunos ejemplos sencillos de su uso. Una línea típica sería, por ejemplo:

auth,authpriv.* /var/log/auth.log

Aquí vemos que los servicios auth y authpriv, servicios que generan mensajes de autenticación, por ejemplo, enviados desde el proceso login, serán logueados en el archivo /var/log/auth.log, sin importar la prioridad que tengan, de ahí el ‘*’.

Como se puede apreciar, podemos separar varios servicios con la misma prioridad utilizando comas, y la misma acción para todos. Si quisiéramos separar varios servicios y prioridades para aplicarles la misma acción, podremos utilizar punto y coma de esta forma:

auth.warn;kernel.crit /var/log/log_de_prueba.log

Cabe aclarar que aquí, por ejemplo, será logueado todo mensaje de warning de autenticación, y todos los mensajes de prioridades superiores también. Para loguear solo una prioridad, podemos utilizar el signo ‘=’ de esta forma:

mail.=info /var/log/solo_mail_info.log

Las acciones posibles.

Las acciones que podemos llevar a cabo con cada mensaje de log incluye alguna de las siguientes:

• Archivo: se puede enviar el log a un archivo de texto, como ocurre generalmente.
• Usuario: se puede enviar el mensaje de log a la terminal de un usuario específico, o lista de usuarios separados por espacio, o a todos los usuarios utilizando *. Por ejemplo:

auth.warn root

• Dispositivo: podemos enviar el log a un dispositivo particular. Generalmente se suelen usar dispositivos de caracter, como una terminal de usuario, por ejemplo:

mail.log    /dev/tty2

• Equipo remoto: también podemos enviar el mensaje a un daemon de syslog que esté corriendo en un equipo remoto usando como acción @ip_del_syslog_remoto, o mediante su hostname. Cabe aclarar que el equipo remoto deberá estar atendiendo logs en red. Por defecto, syslog atiende, si se configura, en el puerto udp514, y se configura, particularmente para rsyslog, desomentando la línea «$UDPServerRun 514» en el archivo de configuración.

Testeando nuestro syslog

Una vez configurado el syslog, podremos testearlo enviando un log generado manualmente según nuestro gusto, y mediante el comando «logger» de esta forma:
logger -p servicio.prioridad «mensaje de log»
Veamos un ejemplo de su uso:
logger mail.warn «mensaje de warning de mail»

Si hemos configurado alguna linea de syslog con algo parecido a esto:

mail.* /var/log/mail_all.log

En dicho archivo veremos una entrada similar a esta:

Oct 7 21:20:59 tuta2 die: mensaje de warning de mail
Con su estampa de tiempo, el equipo y usuario que lo generó, y el mensaje en cuestión.