La gestión de logs del sistema en linux es una habilidad básica para administrar cualquier equipo o servidor con criterio. Los logs no son solo archivos que se revisan cuando algo falla: son el historial operativo del sistema. Registran arranques, servicios que se detienen, errores de autenticación, mensajes del kernel, tareas programadas, eventos de red y señales de seguridad que ayudan a entender qué ha ocurrido.
Además, aprender a leerlos permite diagnosticar incidencias más rápido, detectar comportamientos sospechosos y mantener sistemas más previsibles. En esta guía verás cómo se organizan los logs en Linux, cómo consultar registros con journalctl, qué papel tienen syslog y rsyslog, dónde mirar dentro de /var/log, cómo funciona la rotación y qué buenas prácticas conviene aplicar.
👉 Y recuerda, si quieres aprender más de Linux, pincha en este curso de Linux gratis
👉 También te dejo por aquí una guía de comandos Linux por categorías
Qué son los logs del sistema en Linux
Un log es un registro cronológico de eventos. Cada entrada suele incluir una marca de tiempo, el nombre del equipo, el proceso que genera el mensaje, un identificador de proceso y una descripción del evento.
Una línea de log puede avisar de algo rutinario, como que un servicio ha arrancado correctamente, o de algo crítico, como un intento fallido de acceso por SSH. Por eso los logs sirven tanto para administración diaria como para análisis de seguridad.
En Linux conviven dos grandes enfoques:
- El journal de systemd, consultado normalmente con journalctl.
- Los archivos clásicos en /var/log, gestionados por herramientas como syslog, rsyslog u otros demonios de logging.
De hecho, en muchas distribuciones modernas ambos sistemas funcionan al mismo tiempo. systemd-journald recoge eventos del sistema y los conserva en un formato estructurado, mientras que rsyslog puede escribir parte de esos eventos en archivos de texto tradicionales.
Por qué es importante gestionar los logs
Por ejemplo, los logs ayudan a responder preguntas concretas: qué falló, cuándo empezó el problema, qué servicio estaba implicado, qué usuario ejecutó una acción y si el error se repite.
Una buena gestión de logs permite:
- Diagnosticar fallos de servicios.
- Revisar errores durante el arranque.
- Investigar accesos, sesiones y errores de autenticación.
- Detectar intentos de fuerza bruta o patrones anómalos.
- Auditar cambios importantes del sistema.
- Comprobar tareas programadas con cron o timers de systemd.
- Medir la frecuencia de errores repetitivos.
- Evitar que el disco se llene por registros sin rotación.
Sin embargo, cuando no existe una estrategia mínima, los problemas suelen aparecer tarde. Un servicio deja de arrancar, el disco se llena, los registros antiguos ya no están disponibles o los permisos impiden consultar información importante justo en el momento más urgente.
Dónde se guardan los logs en Linux
La ubicación tradicional de los logs del sistema es /var/log. Dentro de ese directorio puedes encontrar archivos y subdirectorios como estos:
- /var/log/syslog: mensajes generales en Debian, Ubuntu y derivadas.
- /var/log/messages: mensajes generales en muchas distribuciones basadas en Red Hat.
- /var/log/auth.log: autenticación, sudo, SSH y sesiones en Debian/Ubuntu.
- /var/log/secure: autenticación y seguridad en Red Hat, CentOS, Fedora y derivadas.
- /var/log/kern.log: mensajes del kernel en sistemas que separan este registro.
- /var/log/dmesg: mensajes del arranque del kernel, si la distribución lo mantiene.
- /var/log/boot.log: información del proceso de arranque en algunas distribuciones.
- /var/log/cron: eventos de cron en sistemas que lo separan.
- /var/log/apt/: historial de instalaciones y actualizaciones en Debian/Ubuntu.
- /var/log/nginx/ o /var/log/apache2/: logs de servidores web, si están instalados.
Sin embargo, no todas las distribuciones usan los mismos nombres. Por eso conviene empezar comprobando qué archivos existen realmente:
ls -lh /var/logTambién es normal encontrar archivos numerados o comprimidos, como syslog.1, syslog.2.gz o auth.log.1. Son versiones antiguas creadas por la rotación de logs.
El papel de systemd-journald
En sistemas modernos, systemd-journald recoge mensajes del kernel, servicios de systemd, salida estándar y error de unidades, eventos de arranque y otros mensajes del sistema. Su herramienta principal de consulta es journalctl.
La diferencia importante frente a un archivo clásico es que el journal no es simplemente texto plano. Guarda registros estructurados y permite filtrar por unidad, prioridad, fecha, arranque, usuario, proceso y otros campos.
Para ver los registros generales:
journalctlEn la práctica, este comando puede mostrar muchas líneas. En la práctica se usa casi siempre con filtros para reducir el ruido.
Consultar logs con journalctl
journalctl es una de las herramientas más útiles para troubleshooting en Linux. Permite revisar registros con precisión sin tener que recordar todos los archivos de /var/log.
Para ver los eventos del arranque actual:
journalctl -bPara ver los logs de un servicio concreto:
journalctl -u nginxTambién puedes usar el nombre completo de la unidad:
journalctl -u nginx.servicePara seguir los logs en tiempo real:
journalctl -fY para seguir solo un servicio:
journalctl -u ssh -fSegún la distribución, el servicio SSH puede llamarse ssh.service o sshd.service. Puedes comprobarlo con:
systemctl list-units | grep -i sshEsta forma de trabajar es especialmente práctica cuando estás reproduciendo un error y quieres ver qué aparece en el registro justo en ese momento.
Filtrar logs por fecha y hora
Cuando investigas una incidencia, casi siempre tienes una ventana aproximada de tiempo. journalctl permite acotar los resultados con fechas absolutas o expresiones relativas.
Ver logs desde una hora concreta:
journalctl --since "2026-07-02 09:00"Ver logs entre dos momentos:
journalctl --since "2026-07-02 09:00" --until "2026-07-02 10:30"Usar una expresión relativa:
journalctl --since "1 hour ago"Revisar lo ocurrido hoy:
journalctl --since todayEstos filtros evitan leer miles de líneas irrelevantes y ayudan a relacionar eventos de varios servicios dentro de la misma ventana temporal.
Filtrar logs por prioridad
Los mensajes del sistema tienen niveles de prioridad. Los más habituales son:
- emerg: emergencia; el sistema puede estar inutilizable.
- alert: requiere acción inmediata.
- crit: condición crítica.
- err: error.
- warning: advertencia.
- notice: evento normal pero destacable.
- info: información general.
- debug: detalle para depuración.
Para ver errores y eventos más graves:
journalctl -p errPara revisar errores del arranque actual:
journalctl -b -p errEste último comando suele ser uno de los primeros que se ejecutan cuando un servidor se comporta de forma extraña. No todos los mensajes de error explican por sí solos la causa, pero permiten identificar por dónde empezar.
Revisar arranques anteriores
Si el equipo se reinició o el problema ocurrió antes del último arranque, puedes listar los arranques registrados:
journalctl --list-bootsLa salida muestra identificadores y fechas. Para consultar el arranque anterior:
journalctl -b -1Esto es muy útil cuando una máquina se reinicia sin explicación clara. Puedes buscar errores del kernel, problemas de energía, fallos de servicios o mensajes previos al apagado.
Ver mensajes del kernel
Los mensajes del kernel pueden consultarse con:
journalctl -kTambién puedes usar:
dmesgdmesg muestra el buffer de mensajes del kernel y ayuda a detectar problemas de hardware, discos, controladores, interfaces de red o errores durante el arranque.
Para una lectura más cómoda:
dmesg -TLa opción -T muestra marcas de tiempo legibles para humanos. Aun así, en contextos de auditoría conviene tener cuidado, porque esa conversión de tiempo puede no ser la fuente más precisa.
Syslog y rsyslog
syslog es un estándar histórico para enviar, clasificar y almacenar mensajes del sistema. rsyslog es una implementación muy usada que puede recibir logs, filtrarlos, escribirlos en archivos, reenviarlos a servidores remotos y aplicar reglas avanzadas.
En muchas distribuciones, rsyslog toma mensajes del sistema y los escribe en archivos como /var/log/syslog, /var/log/messages, /var/log/auth.log o /var/log/secure.
Puedes comprobar si rsyslog está activo con:
systemctl status rsyslogSus reglas suelen estar en:
/etc/rsyslog.conf
/etc/rsyslog.d/De esta forma, estas reglas definen qué mensajes se guardan y dónde. Por ejemplo, una configuración puede enviar mensajes de autenticación a un archivo específico y mensajes generales a otro.
Leer archivos de log clásicos
Los archivos de /var/log suelen ser texto plano. Puedes leerlos con herramientas básicas:
less /var/log/syslogVer las últimas líneas:
tail -n 100 /var/log/syslogSeguir un archivo en tiempo real:
tail -f /var/log/syslogSi quieres profundizar en esta herramienta, puedes revisar la guía del comando tail para monitoreo de archivos en tiempo real.
Buscar una palabra concreta:
grep -i "error" /var/log/syslogBuscar varias coincidencias útiles:
grep -Ei "error|failed|denied|timeout" /var/log/syslogCuando el log está comprimido, puedes usar zgrep:
zgrep -i "failed password" /var/log/auth.log.*.gzEstas herramientas siguen siendo imprescindibles porque muchos servicios de aplicación escriben sus propios logs fuera del journal.
Permisos para consultar logs
No todos los usuarios pueden leer todos los logs. Es normal que archivos de autenticación, seguridad o registros del sistema requieran privilegios.
Si recibes un error de permisos, usa sudo:
sudo journalctl -u sshO:
sudo less /var/log/auth.logRotación de logs con logrotate
Los logs crecen con el tiempo. Si no se rotan, pueden llenar el disco y provocar fallos graves: servicios que no arrancan, bases de datos que no escriben o actualizaciones que se interrumpen.
La herramienta clásica para rotar logs en Linux es logrotate. Su configuración principal suele estar en:
/etc/logrotate.conf
/etc/logrotate.d/La rotación puede:
- Renombrar el archivo actual.
- Crear un archivo nuevo.
- Comprimir logs antiguos.
- Eliminar registros pasados ciertos días o cierto número de rotaciones.
- Ejecutar acciones después de rotar, como recargar un servicio.
Gestionar el tamaño del journal
El journal de systemd también puede ocupar espacio. Para ver su uso actual:
journalctl --disk-usagePara limpiar registros antiguos dejando solo los últimos 7 días:
sudo journalctl --vacuum-time=7dLa configuración persistente está en:
/etc/systemd/journald.confConclusión
La gestión de logs del sistema en Linux combina herramientas modernas y métodos clásicos. journalctl ofrece una forma potente de consultar eventos estructurados de systemd, mientras que syslog y rsyslog mantienen el enfoque basado en archivos de texto dentro de /var/log.
Administrar bien un sistema no consiste solo en saber que los logs existen. Hay que saber dónde están, cómo filtrarlos, qué permisos requieren, cómo se rotan, cuánto espacio ocupan y cómo usarlos para troubleshooting y seguridad.
Una buena base es revisar el arranque actual con journalctl -b, filtrar errores con journalctl -p err, conocer los archivos principales de /var/log, verificar la rotación con logrotate y proteger los registros sensibles. Con esa práctica, los logs dejan de ser ruido y se convierten en una herramienta diaria para operar Linux con más control.
