Además, las aplicaciones individuales a veces escriben en sus propios archivos de registro. A menudo también verá directorios completos como /var/log/apache2/ o /var/log/mysql/ creados para recibir datos de la aplicación.
La redirección de registros también se puede controlar a través de cualquiera de los ocho niveles de prioridad, además del símbolo * (para todos los niveles de prioridad) que vio antes.
| Nivel | Descripción |
|---|
| depurar | Útil para la depuración |
| información | Informativo |
| aviso | Condiciones normales |
| advertir | Condiciones que requieren advertencias |
| err | Condiciones de error |
| crítico | Condiciones críticas |
| alerta | Se requiere acción inmediata |
| emergencia | Sistema inutilizable |
Administración de archivos de registro con sysglogd
De manera predeterminada, syslogd maneja la rotación, compresión y eliminación de registros en segundo plano sin su ayuda. Pero debe saber cómo se hace en caso de que alguna vez tenga troncos que necesiten un tratamiento especial.
¿Qué tipo de tratamiento especial podría requerir un simple registro? Bueno, suponga que su empresa debe cumplir con las reglas de informes de transacciones asociadas con los estándares regulatorios o de la industria como Sarbanes-Oxley o PCI-DSS. Si los registros de su infraestructura de TI deben permanecer accesibles durante períodos de tiempo más largos, entonces definitivamente querrá
para saber cómo orientarse a través de los archivos clave.
Para ver el sistema logrotate en acción, enumere algunos de los contenidos del directorio /var/log/. El archivo auth.log, por ejemplo, aparece en tres formatos diferentes:
- auth.log - La versión que está actualmente activa, con nuevos mensajes de autenticación escritos en ella.
- auth.log.1 - El archivo más reciente que se ha rotado fuera de servicio. Se mantiene en formato sin comprimir para que sea más fácil volver a activarlo rápidamente en caso de que sea necesario.
- auth.log.2.gz - Una colección más antigua (como puede ver en la extensión de archivo .gz en la siguiente lista) que ha sido comprimida para ahorrar espacio.
Después de siete días, cuando llegue la próxima fecha de rotación, auth.log.2.gz pasará a llamarse auth.log.3.gz, auth.log.1 se comprimirá y pasará a llamarse auth.log.2.gz, auth.log se convertirá en auth.log.1 y se creará un nuevo archivo al que se le asignará el nombre auth.log.
El ciclo de rotación de registros predeterminado se controla en el archivo /etc/logrotate.conf. Los valores ilustrados en esta lista rotan los archivos después de una sola semana activa y eliminan los archivos antiguos después de cuatro semanas.
# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
# create new (empty) log files after rotating old ones
create
# packages drop log rotation information into this directory
include /etc/logrotate.
El directorio /etc/logrotate.d/ también contiene archivos de configuración personalizados para administrar la rotación de registros de servicios o aplicaciones individuales. Al enumerar el contenido de ese directorio, verá estos archivos de configuración:
$ ls /etc/logrotate.d/
apache2 apt dpkg mysql-server
rsyslog
samba
unattended-upgrade
Puede ver su contenido para ver qué tipo de configuración tienen en la rotación de registros.
💡Muchos administradores optan por redirigir las entradas de registro a servidores de registro remotos especialmente diseñados donde los datos pueden recibir toda la atención especializada que merecen. Esto puede liberar servidores de aplicaciones para sus tareas inmediatas y consolidar los datos de registro en una única ubicación central de fácil acceso. Cómo leer los archivos syslog
Sabes que tienes mejores cosas que hacer con tu tiempo que leer millones de líneas de entradas de registro.
El uso de cat debe evitarse por completo aquí. Simplemente volcará miles de líneas en tu pantalla.
Sugiero usar grep para filtrar texto a través de los archivos.
El uso del comando tail -f le permite leer el archivo de registro actual en tiempo real. Puede combinarlo con grep para filtrar el texto deseado.
En algunos casos, es posible que necesite acceder a los registros comprimidos antiguos. Siempre puede extraer el archivo primero y luego usar grep, less y otros comandos para leer su contenido, sin embargo, hay una mejor opción. Hay comandos z como zcat, zless, etc. que le permiten trabajar en los archivos comprimidos sin extraerlos explícitamente.
Un ejemplo práctico de análisis de logs
Aquí hay un ejemplo obvio que buscará en el archivo auth.log evidencia de intentos de inicio de sesión fallidos. Buscar la palabra fracaso
devolver cualquier línea que contenga la frase fallo de autenticación.
Verificar esto de vez en cuando puede ayudarlo a detectar intentos de comprometer una cuenta al adivinar la contraseña correcta. Cualquiera puede estropear una contraseña una o dos veces, pero demasiados intentos fallidos deberían hacerte sospechar:
$ cat /var/log/auth.log | grep 'Authentication failure'
Sep 6 09:22:21 workstation su[21153]: pam_authenticate: Authentication failure
Si usted es el tipo de administrador que nunca comete errores, entonces esta búsqueda podría quedar vacía. Puede garantizarse al menos un resultado generando manualmente una entrada de registro utilizando un programa llamado registrador. Pruébalo haciendo algo como esto:
logger "Authentication failure"
También puede preseleccionar un error genuino iniciando sesión en una cuenta de usuario e ingresando la contraseña incorrecta.
Como puede ver, grep hizo el trabajo por usted, pero todo lo que puede ver en los resultados es que hubo una falla de autenticación. ¿No sería útil saber de quién es la cuenta involucrada? Puede expandir los resultados que devuelve grep diciéndole que incluya las líneas inmediatamente antes y después del partido.
Este ejemplo imprime la coincidencia junto con las líneas que la rodean. Te dice que alguien que usa la cuenta david intentó sin éxito usar su (cambiar de usuario) para iniciar sesión en la cuenta del estudio:
$ cat /var/log/auth.log | grep -C1 failure
Sep 6 09:22:19 workstation su[21153]: pam_unix(su:auth): authentication
failure; logname= uid=1000 euid=0 tty=/dev/pts/4 ruser=david rhost=
user=studio
Sep 6 09:22:21 workstation su[21153]: pam_authenticate:
Authentication failure
Sep 6 09:22:21 workstation su[21153]: FAILED su for studio by david
¿Qué sigue?
Conocer los conceptos básicos es una cosa y aplicar el conocimiento es otra cosa. Sin embargo, el conocimiento de los fundamentos ayuda en varias situaciones.
Ahora que conoce los aspectos básicos de los syslogs en Linux, es posible que le resulte un poco mejor trabajar con los registros.
Este artículo es un extracto del libro Linux in Action de David Clinton. Lo publica Manning Publication y puedes obtener un 30 % de descuento en cualquier libro de Manning usando el código nlitsfoss22 a la hora de pagar.
Libro Linux en acción
Disfruta aprendiendo Linux.
