Registro de logs en Linux
En todo sistema operativo muy necesario contar un sistema que nos provea información sobre los eventos que están ocurriendo en todo momento y aplicación. Esto se logra a través del registro de logs en Linux, los cuales, estaremos viendo los tipos, función y ubicación en este apartado.
Table of Contents
ToggleIntroducción
Tener un sistema que nos provea de información con respecto de lo que sucede en nuestro equipo es de vital importancia, ya que que podemos entender cómo está funcionando nuestro equipo desde diferentes puntos de vista. Si las aplicaciones o funciones críticas informan cada evento en el equipo, a partir de esto, podemos generar estadísticas para solucionar problemas repetitivos, detectar fallas que nos ayudarán a solucionar problemas, mejorar la seguridad del sistema, etc.
A continuación, veremos en detalle las características que componen el registro de logs en Linux
Clasificación y ubicación de logs
Los eventos que ocurren en el sistema generan dos tipos de mensajes:
Mensajes que pueden ser generados por los programas, los cuales se encargan de registrar la información de forma cronológica de la aplicación que estamos usando.
Mensajes de logs que registra el sistema con respecto al sistema operativo. Por ejemplo, el registro de información acerca de los mensajes del sistema, los accesos de los usuarios, el funcionamientos de los servicios, etc.
Estos archivos se encuentran dentro del directorio /var/log y los subdirectorios del mismo /var/log/*
# ls –ld /var/log/*
Cabe mencionar que existe un demonio que se puede encargar de administrar los mensajes de logs tanto de los programas como del sistema. Este proceso es rsyslog (aunque algunos sistemas pueden llegar a usar el anterior demonio syslog).
En cuanto a la configuración del mismo lo podemos encontrar en /etc/rsyslog.conf y para saber si el servicio está activo podemos colocar el siguiente comando:
# systemctl status rsyslog
Función de los logs
El sistema divide en categorías a las prioridades y servicios que componen los logs. Este tipo de combinación se conoce como “Reglas”, las cuales definen el futuro comportamiento de cada evento para tomar una acción. En otras palabras, las reglas están divididas en selector (compuesta por los servicios y los tipos de prioridad) y la acción, cuyo funcionamiento define el lugar donde se van a guardar los eventos por parte del selector.
SELECTOR
A continuación, describiremos los tipos de servicios y prioridad dentro del selector:
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. |
Mensajes del servicio de correo. | |
mark | Para uso interno. No usar al hacer las reglas. |
news | Mensajes del servicio de noticias USENET. |
security | 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 definir por el usuario. |
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 aún 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. |
Los mensajes serán reportados por prioridad, de forma ascendente. Por ejemplo, si se especifica la prioridad crit , se reportarán los mensajes con prioridad alert , emer y panic , y none mientras que los error , err, warn, hasta debug no serán reportados.
ACCIÓN
Como dijimos anteriormente, la acción define el lugar donde se van a guardar los mensajes. Sin embargo, existe más de una posibilidad donde guardar dichos eventos. Veamos el siguiente cuadro:
LUGAR | DESCRIPCIÓN |
/ruta/de/registro de evento | Escribir los mensajes a un archivo de registros de eventos (ej: /var/log/archivo.log). |
| (tubería o pipe) | Usar un pipe como el destino de los mensajes. Esto es útil para depuración o enviar correos. |
/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. |
@@192.168.0.1 | Reenviar mensajes a la máquina 192.168.0.1 vía TCP, evita perdida de paquetes. Hay que cargar el módulo imtcp para que funcione. |
omrelp:192.168.0.1:2514 | Si quieres prevenir la pérdida de mensajes UDP, usa RELP. |
Usuario1,2,3.. | Lista de usuarios. Por defecto, los mensajes críticos son enviados a root. |
Modificadores y Operadores
El registro de logs en Linux cuenta con modificadores y operadores especiales. Los mismos podemos clasificarlos como caracteres «comodines» ya que nos simplifican la funcionalidad especificando una o varias acciones a tomar con respecto el selector.
Modificadores
Los modificadores son aquellos que usamos con el selector para especificar una orden. Existen tres tipos de modificadores, estos son: ‘!’, ‘=’ y ‘*’.
Veamos sus funciones a continuación:
1) El modificador “=” le indica a rsyslog que debe reportar solo los mensajes con la prioridad exacta. Por ejemplo:
SELECTOR = Servicio.Prioridad | ACCIÓN |
mail.=error | /var/log/mail.error |
Se reportarán los mensajes de error. Sin el modificador =, rsyslog reportaría los mensajes tipo error , crit , alert y emerg.
2) El segundo modificador es “ ! ”, que invierte el significado de la regla. Por ejemplo:
SELECTOR = Servicio.Prioridad | ACCIÓN |
mail.!error | /var/log/mail.error |
Se reportarán los mensajes con menor prioridad que error , o sea, warning , notice , info y debug . Si queremos excluir sólo una prioridad, debemos usar la combinación !=
Por Ejemplo:
mail!=error /var/log/mail.error
3) Finalmente, el modificador “ * ” permite seleccionar entre los distintos servicios y prioridades. Por ejemplo:
SELECTOR = Servicio.Prioridad | ACCIÓN |
mail.* | /var/log/mail.log |
Aquí, todos los mensajes provenientes del servicio de correo serán guardados en el archivo /var/log/mail.log , sin importar su prioridad. Por 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
A continuación veremos el uso de los operadores coma (,) y punto y coma (;).
A) El operador punto y coma permite escribir varias reglas en una forma más compacta.
Por ejemplo:
apache.=info /var/log/info.log
apache.=notice /var/log/notice.log
auth.=info /var/log/info.log
Las reglas anteriores pueden ser escrita en una sola línea:
apache.=info;apache.=notice;auth.=info /var/log/info.log
B) Por otro lado, si queremos seleccionar varios servicios, podemos usar el operador coma.
Veamos a continuación:
apache.=info /var/log/info.log
auth.=info /var/log/info.log
Podemos escribir las reglas anteriores en una línea, de la siguiente forma:
apache,auth.=info /var/log/info.log
Como podemos ver, la gran diferencia entre el operador coma y el operador punto y coma, es que el primero solo separa servicios, mientras que el último puede separar servicios y prioridades.
Dato a considerar
Algunos registros deben ser monitoreados en tiempo real, por ejemplo, cuando se está depurando un servicio. El asunto es que rsyslog escribe mensajes solo cuando su buffer está lleno, es decir, de forma asincrónica. Si queremos escribir mensajes sincrónicamente debemos colocar un “ – ” (guion) antes de la ruta del archivo donde se guardarán los registros de eventos.
Miremos el siguiente ejemplo:
SELECTOR = Servicio.Prioridad | ACCIÓN |
apache.info | -/var/log/apache.log |
# cat /etc/rsyslog.conf