Syslogd: el demonio de las bitácoras


BitacoraCuando un servicio falla este reporta lo que ha pasado o cuando algo va mal en tu máquina (por ejemplo un problema de hardware) esto también es reportado. Esos mensajes pueden ser encontrados en el directorio /var/log. Por ejemplo, muchos mensajes son reportados en el archivo /var/log/syslog o en el /var/log/messages. Por otro lado, si un servicio genera muchos mensajes muy probablemente estos serán escritos en un archivo separado como lo hace Apache o el servicio de correo.

Todo esto es hecho por un demonio llamado syslogd, el cual es una utilidad del sistema que provee soporte para el registro de mensajes en sistemas *nix. Pero las bitácoras no están reservadas únicamente para las aplicaciones del sistema, tú también puedes registrar tus mensajes usando syslogd, configurando una regla apropiada en el archivo /etc/syslog.conf. Así que , veamos como hacerlo…

Archivo de configuración

En el archivo /etc/syslog.conf (o en el /etc/rsyslog.conf) están definidas las reglas para las bitácoras usando syslogd, una regla por línea.  Cada regla sigue esta sintaxis:

selector acción

A su vez, el selector está compuesto de servicio.prioridad, entonces la sintaxis completa sería:

servicio.prioridad acción

El servicio puede ser uno de las siguientes palabras:

Servicio Descripción
auth Mensajes de seguridad/autenticación
authpriv Mensajes de seguridad/autenticación (privado)
cron Demonio de tiempo (cron y at)
daemon Demonios del sistema sin valor de servicio separado
kern Mensajes del kernel
lpr Mensajes del servicio de impresión
mail Mensajes del servicio de correo
mark Para uso interno. No usar al hacer las reglas
news Mensajes del servicio de noticias USENET
security (same as auth) Obsoleto, usar auth
syslog Mensajes generados internamente por syslogd
user Mensajes genéricos a nivel de usuario
uucp mensajes de UUCP
local0 a local7 Reservado para uso local

La prioridad puede ser una de las palabras listadas en la siguiente tabla. Los mensajes serán reportados por prioridad, deforma ascendente. Por ejemplo, si se especifica la prioridad alert se reportarán los mensajes con prioridad alert, emer y panic, mientras que los crit, error, hasta debug no serán reportados.

Prioridad Descripción
debug Usado para depurar servicios, por ejemplo si no están funcionando apropiadamente
info Usado para reportar mensajes informativos.
notice Como la prioridad info, pero haciendo notar algo que puede ser relevante
warning Usado para reportar advertencias. Puede darte pistas sobre errores (si los hubiera) o solo mostrarte que hay algo que no está trabajando como debería, pero que igual sigue funcionando.
warn Igual que warning
err Usado para reportar errores. Por ejemplo, si tienes un servicio mal configurado este reportará esos errores.
error Igual que err
crit Usado para reportar errores más críticos. Por ejemplo errores de hardware.
alert Usado para reportar errores aun más críticos. Se debe tomar algún correctivo inmediatamente. Por ejemplo, corrupción de una base de datos.
emerg Usado para reportar errores realmente críticos. Muy probablemente el servicio está inoperante
panic Igual que emerg
none Usado para deshabilitar el reporte de un servicio.

La acción describe qué se debe hacer con el mensaje reportado. Comúnmente, todos los mensajes son escritos a un archivo de bitácoras, pero también hay otras acciones como reenviar los mensajes a otra máquina. De forma que el campo acción puede ser uno de los siguientes:

Acción Descripción
/ruta/de/bitácora Escribir los mensajes a un archivo de bitácoras
| fifo Usar un fifo o una tubería como el destino de los mensajes. Esto es útil para depuración o enviar correos. Note que el fifo debe ser creado con el comando mkfifo(1) antes de que syslogd(8) sea iniciado
/dev/tty[1-6] Escribir mensajes en las consolas /dev/tty[1-6]. Note que /dev/console también funcionará
@192.168.0.1 Reenviar mensajes a la máquina 192.168.0.1 vía UDP. Debido a la naturaleza de UDP, probablemente se perderán mensajes en tránsito. Si esperas alto volumen de tráfico, debes esperar una pérdida considerable de mensajes. Nota: para aceptar mensajes, el servidor remoto debe correr syslogd con la opción -r (en Debian esta opción puede ser dada en el archivo /etc/default/syslogd o en el /etc/default/rsyslog)
:omrelp:192.168.0.1:2514 Si quieres prevenir la pérdida de mensajes UDP, usa RELP
lgallard, atorres Lista de usuarios. Por defecto, los mensajes críticos son enviados a root

Modificadores

Básicamente existen tres modificadores: =, ! y *. El modificador “=” le indica a syslogd que debe reportar solo los mensajes con la prioridad exacta. Por ejemplo:

mail.=error                       /var/log/mail.error

Aquí syslogd reportará solo los mensajes de error. Sin el modificador =, syslogd reportaría los mensajes tipo error, crit, alertpanic. Este modificador solo puede usarse con las prioridades.

El segundo modificador es “!”, el cual invierte el significado de la regla. Por ejemplo:

mail.!error                       /var/log/mail.error

Syslogd reportará los mensajes con menos prioridad que error, ergo warning, notice, info y debug. Si quieres excluir solo una prioridad, debes usar la combinación !=.

Finalmente, el modificador “*” te permite seleccionar entre los distintos servicios y prioridades. Por ejemplo:

mail.*                       /var/log/mail.log

Aquí, todos los mensajes provenientes del servicio de correo serán guardados en el archivo /var/log/mail.log, no importando su prioridad. Otro ejemplo:

*.info                       /var/log/info.log

No importa el servicio, todos los mensajes cuya prioridad sean info serán guardados en el archivo /var/log/info.log.

Operadores coma, y punto y coma

El operador punto y coma te permite escribir varias reglas en una forma más compacta. Por ejemplo:

mail.=info                       /var/log/info.log
mail.=notice                     /var/log/info.log
auth.=info                       /var/log/info.log

Las reglas anteriores pueden ser escrita en una sola línea:

mail.=info;mail.=notice;auth.=info   /var/log/info.log

Por otro lado, si quieres seleccionar varios servicios, puedes usar el operador coma. Por ejemplo:

mail.info                       /var/log/info.log
auth.info                       /var/log/info.log

Puedes escribir las reglas anteriores en una línea, de la siguiente forma:

mail,auth.info                  /var/log/info.log

La gran diferencia entre el operador coma y el operador punto y coma es que el primero solo separa servicios y el ultimo puede separar prioridades y servicios, incluso si estos son incompatibles entre sí.

Registro síncrono

Algunas bitácoras deben ser monitoreadas en tiempo real, por ejemplo cuando se está depurando un servicio. El asunto es que syslogd escribe mensajes solo cuando su buffer está lleno, es decir, de forma asíncrona. Si quieres escribir mensajes síncronamente debes colocar un “-” antes de la ruta del archivo donde se guardará las bitácoras.

Ejemplos

Aquí hay unos ejemplos inventados por mí y otros tomados del archivo /etc/syslog.conf:

local3.info                     /var/log/milog

Usar el servicio local3, reportando mensajes tipo info al archivo /var/log/milog.

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

Reportar todas las prioridades para los servicios auth y authpriv en el archivo /var/log/auth.log.

mail.warn                       -/var/log/mail.warn

Los mensajes de warn del servicio de correo serán guardados en el archivo /var/log/mail.warn síncronamente.

mail.!=error                       /var/log/mail.error

Todos los mensajes excepto los de error serán guardados en el archivo /var/log/mail.error.

*.=debug;\
	auth,authpriv.none;\
	news.none;mail.none	-/var/log/debug

Todos los mensajes serán guardados en el archivo /var/log/debug de forma síncrona, excepto aquellos provenientes de los servicios auth, authpriv, news y mail.

El comando logger

Si quieres comunicarte con syslogd, puedes utilizar el comando logger. Por ejemplo, para enviar un mensaje con prioridad info y servicio local3, solo escribe:

logger -p local3.info “Esto es un mensaje”

Referencias


,

  1. #1 by emmanuel on 08/02/2017 - 6:53

    hola que tal!!! cual es la linea que debo usar para colocar una command line syslog en un servidor solaris 9 para que este pueda conectar con un colector de eventos

    este ejemplo lo coloque en otros servidores pero en 9 no jala

    *.*debug +ip

    Sabran cual linea puedo usar?

    gracias por el apoyo
    saludos…

  2. #2 by Luis Gallardo on 29/04/2010 - 3:29

    @leoj Debe aplicar porque son conceptos de Unix. Revisa en la documentación de Solaris…

  3. #3 by leoj on 29/04/2010 - 2:52

    leoj :hola que tal!! oye una pregunta todo esto de los demonios de syslogd se pueden aplicar en solaris 10 ??? saludos!!

  4. #4 by leoj on 29/04/2010 - 1:09

    hola que tal!! oye una pregunta todo esto de los demonios de syslogd se pueden aplicar en solaris 10 ??? saludos!!

  5. #5 by Luis Gallardo on 19/02/2010 - 9:48

    @Luis gracias por tus comentarioss!!

  6. #6 by Luis on 19/02/2010 - 7:06

    En todas tocallo, que buen blog esta solo yogurt

Los Comentarios están cerrados