Gestión de registros en Linux: uso de comandos journalctl para registros de systemd

Nivel: Principiante
Tiempo estimado: ~20 minutos
Objetivo: Aprender a consultar, filtrar y gestionar los registros del sistema y de los servicios, utilizando los registros de Linux para solucionar problemas y mantener la disponibilidad del servidor.

Introducción

Una gestión de registros en Linux fiable es esencial para mantener la disponibilidad del servidor y realizar el diagnóstico de servidores Linux. Al administrar servidores web, necesita analizar los registros del sistema con journalctl para encontrar rápidamente la causa raíz de un problema. Systemd (el sistema de inicio y gestor de servicios de la mayoría de las distribuciones Linux modernas) recopila los registros del sistema (registros generales de las operaciones del sistema y de los eventos a nivel de sistema). Cada registro (log) (un registro de los eventos que ocurren dentro de un sistema operativo o una aplicación) es recopilado por Systemd-journald (un servicio del sistema que recopila y almacena datos de registro) y se guarda en el Journal (los datos de registro en formato binario generados y gestionados por systemd-journald). Para consultar estos datos usamos Journalctl (una utilidad de línea de comandos para consultar y mostrar los registros de systemd). Este tutorial se centra en el uso de los comandos de journalctl para consultar, filtrar y gestionar los registros de systemd con journalctl. Al terminar, podrá moverse con soltura por la línea de comandos y utilizar los registros de Linux para la resolución de problemas de forma eficiente.

Requisitos previos

Antes de empezar, asegúrese de cumplir las siguientes condiciones:

• Sistema operativo: Ubuntu 20.04/22.04/24.04 LTS, Debian 11/12/13 o AlmaLinux/Rocky 8/9/10
• Requisitos de hardware y red: ninguno (esta guía utiliza utilidades básicas de línea de comandos)
• Acceso: acceso sudo o root al servidor
• Conocimientos necesarios: uso básico de la línea de comandos de Linux

Paso 1: Gestión de registros en Linux: registros volátiles y persistentes

De forma predeterminada, algunos sistemas configuran el journal para usar registros volátiles (registros que se almacenan solo en la RAM y se pierden al reiniciar). Para una gestión de registros en Linux eficaz necesitamos registros persistentes (registros guardados en disco que se conservan entre reinicios), de modo que pueda investigar fallos después de un reinicio.

Ejecute el siguiente comando para comprobar la configuración de almacenamiento:

sudo grep -i 'storage' /etc/systemd/journald.conf

Salida esperada:

#Storage=auto

Debería ver una salida que indica si el almacenamiento está configurado como auto, persistent o volatile. Un #Storage=auto comentado significa que se usa el comportamiento predeterminado auto.

En Ubuntu 24.04 y Debian 13, el directorio /var/log/journal ya existe y el registro persistente funciona sin configuración adicional. Si el directorio no existe (por ejemplo, en una instalación nueva de AlmaLinux) y desea forzar el registro persistente, cree el directorio y reinicie el sistema de registro de systemd (el servicio systemd-journald gestiona este directorio):

sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald

En sistemas AlmaLinux/RHEL, además debe volcar (flush) los registros desde la ubicación volátil /run/log/journal al nuevo almacenamiento persistente en disco:

sudo journalctl --flush

No debería ver ninguna salida. Esto confirma que el servicio se reinició correctamente y que a partir de ahora escribirá datos persistentes en el disco.

Paso 2: Comandos básicos de journalctl para los registros de systemd

Para ver todas las entradas disponibles, utilice el comando predeterminado.

Ejecute el siguiente comando:

sudo journalctl

Salida esperada:

May 20 10:00:00 server systemd[1]: Started Logging Service.
May 20 10:00:01 server kernel: Linux version 5.15.0-101-generic...

Debería ver una lista paginada con todos los registros de systemd de su servidor. Pulse q para salir del paginador.

Para analizar los registros con journalctl de forma eficaz, rara vez le interesará leer todo desde el principio. Puede invertir la salida para ver primero las entradas más recientes con la opción -r.

Ejecute el siguiente comando:

sudo journalctl -r

Salida esperada:

May 23 20:00:00 server sshd[1234]: Accepted publickey for user from 192.168.1.50...
May 23 19:59:58 server systemd[1]: Session 4 created for user.

Debería ver las entradas de registro más recientes en la parte superior de la pantalla. Es una técnica clave para analizar los registros con journalctl rápidamente después de un incidente.

Paso 3: Cómo consultar los registros de un servicio

A menudo necesita diagnosticar una unidad (unit) concreta (un objeto que systemd sabe gestionar), como una unidad de servicio (un tipo de unidad que controla un servicio, como nginx o sshd). Utilice la opción -u para consultar los registros de un servicio concreto, como el servidor web nginx.

Ejecute el siguiente comando (suponiendo que el servicio esté instalado, por ejemplo, mediante sudo apt install nginx -y o sudo dnf install nginx -y):

sudo journalctl -u nginx

Salida esperada:

May 23 18:00:00 server systemd[1]: Starting A high performance web server and a reverse proxy server...
May 23 18:00:01 server systemd[1]: Started A high performance web server and a reverse proxy server.

Debería ver únicamente las entradas generadas por el servicio nginx. Esto ayuda a aislar los errores del tráfico web de otros eventos del sistema en segundo plano. Si el servicio no está instalado, simplemente verá -- No entries --.

Para consultar los registros del demonio SSH, el nombre de la unidad varía según la distribución.

En Ubuntu/Debian, ejecute:

sudo journalctl -u ssh

En AlmaLinux/RHEL/Rocky, ejecute:

sudo journalctl -u sshd

Salida esperada:

May 23 19:50:00 server sshd[1234]: Invalid user admin from 10.0.0.5 port 55432
May 23 19:55:00 server sshd[1235]: Accepted publickey for root from 10.0.0.2 port 44322

Debería ver los intentos de autenticación y los eventos del demonio SSH.

Paso 4: Filtrado de registros con journalctl por tiempo y tipo

Cuando se manejan grandes volúmenes de datos, es necesario el filtrado de registros (el proceso de acotar la salida de los registros según criterios específicos). El filtrado de registros con journalctl por tiempo es muy útil cuando una interrupción ocurrió en un momento conocido.

Para ver los mensajes generados desde el último arranque, consultamos los registros de arranque (registros de los eventos que ocurren durante el proceso de inicio del sistema).

Ejecute el siguiente comando:

sudo journalctl -b

Salida esperada:

May 23 08:00:00 server kernel: Linux version 5.15.0-101-generic...
May 23 08:00:00 server kernel: Command line: BOOT_IMAGE=/boot/vmlinuz...

Debería ver la salida a partir del primer evento de la secuencia de arranque actual.

Para el filtrado de registros con journalctl basado en el tiempo, utilice --since y --until.

Ejecute el siguiente comando:

sudo journalctl --since "1 hour ago"

Salida esperada:

May 23 19:00:00 server cron[567]: (root) CMD (/usr/local/bin/backup.sh)
May 23 19:05:00 server sudo[580]: user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/bin/ls

Debería ver todos los eventos ocurridos en los últimos 60 minutos.

Para ver los registros del kernel (mensajes generados por el kernel de Linux, normalmente eventos de hardware y controladores), utilice la opción -k.

Ejecute el siguiente comando:

sudo journalctl -k

Salida esperada:

May 23 08:00:00 server kernel: e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex
May 23 08:00:01 server kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Debería ver mensajes de bajo nivel del kernel, útiles para diagnosticar problemas de hardware o de controladores.

Paso 5: Filtrado por prioridad

Cada entrada tiene una prioridad (el nivel de gravedad asignado a un mensaje de registro). Los niveles van desde Debug (el nivel de prioridad más bajo, utilizado para información detallada de diagnóstico) hasta Error (un nivel de prioridad que indica un fallo en un servicio o proceso). Un nivel que se consulta con frecuencia es Warning (un nivel de prioridad que indica posibles problemas que todavía no son errores).

Para el filtrado de registros con journalctl por prioridad, utilice la opción -p.

Ejecute el siguiente comando para ver solo los errores:

sudo journalctl -p err

Salida esperada:

May 23 10:15:20 server systemd[1]: Failed to start Custom Application Service.
May 23 14:30:00 server sshd[1122]: error: kex_exchange_identification: Connection closed by remote host

Debería ver una lista reducida que contiene solo mensajes de nivel de error, sin las operaciones normales.

Ejecute el siguiente comando para ver advertencias y errores:

sudo journalctl -p warning

Salida esperada:

May 23 10:15:15 server systemd-udevd[330]: vda: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/vda' failed with exit code 1.
May 23 10:15:20 server dhcpcd[400]: eth0: no IPv6 Routers available

Debería ver tanto advertencias como errores, lo que ofrece una visión más amplia de los posibles problemas. En un sistema operativo recién instalado es habitual ver mensajes de advertencia rutinarios de servicios como multipathd, irqbalance, dhcpcd o udev, en lugar de fallos críticos de servicios. La salida exacta depende en gran medida de la configuración y el entorno de su sistema.

Paso 6: Cómo supervisar los registros de Linux en tiempo real

Al aplicar cambios de configuración o reproducir un problema, lo mejor es supervisar los registros de Linux en tiempo real. Utilice la opción -f (follow).

Ejecute el siguiente comando:

sudo journalctl -f

Salida esperada:

May 23 20:05:00 server sudo[2001]: user : TTY=pts/1 ; PWD=/ ; USER=root ; COMMAND=/bin/bash
May 23 20:05:00 server su[2002]: (to root) user on pts/1
May 23 20:05:00 server su[2002]: pam_unix(su:session): session opened for user root by user(uid=1000)

Debería ver las últimas entradas de registro, y el terminal quedará a la espera mostrando los nuevos eventos a medida que se produzcan. Pulse Ctrl+C para salir.

Para supervisar en tiempo real los registros del demonio SSH, el nombre de la unidad varía según la distribución.

En Ubuntu/Debian, ejecute:

sudo journalctl -u ssh -f

En AlmaLinux/RHEL/Rocky, ejecute:

sudo journalctl -u sshd -f

Salida esperada:

May 23 20:10:15 server sshd[2100]: Connection from 192.168.1.100 port 45678
May 23 20:10:17 server sshd[2100]: Accepted publickey for admin from 192.168.1.100 port 45678
May 23 20:10:17 server sshd[2100]: pam_unix(sshd:session): session opened for user admin by (uid=0)

Debería ver los intentos de autenticación SSH en directo, a medida que ocurren.

Paso 7: Espacio en disco y rotación de registros

El journal de systemd puede crecer mucho con el tiempo. La práctica de archivar y eliminar registros antiguos para ahorrar espacio se denomina rotación de registros. Puede comprobar cuánto espacio ocupa actualmente el journal de systemd.

Ejecute el siguiente comando:

sudo journalctl --disk-usage

Salida esperada:

Archived and active journals take up 200.0M in the file system.

Debería ver una salida que indica el espacio total ocupado por sus archivos de registro.

Para realizar una rotación manual de registros y liberar espacio en disco, puede depurar los datos (vacuum) por tiempo o por tamaño.

Ejecute el siguiente comando para conservar solo los últimos 500 MB de datos:

sudo journalctl --vacuum-size=500M

Salida esperada:

Vacuuming done, freed 0B of archived journals from /var/log/journal.

Debería ver una salida que indica que se han eliminado los archivos antiguos hasta que el tamaño total es inferior a 500 MB.

Verificación

Para asegurarse de que la configuración de registro funciona correctamente y el almacenamiento persistente está activo:

1. Compruebe que se ha creado la ubicación de almacenamiento de los registros:

   ls -ld /var/log/journal

   Debería ver un directorio propiedad de root. Según la distribución, el grupo puede ser systemd-journal o root (ambos son normales).

2. Confirme que journald se está ejecutando:

   sudo systemctl status systemd-journald

   Debería ver que el servicio está en estado active (running).

Solución de problemas

Si encuentra problemas al gestionar los registros, compruebe estos casos habituales:

• Registros de servicio vacíos (-- No entries --): Asegúrese de que el servicio esté realmente instalado y en ejecución. Compruebe también que utiliza el nombre de unidad correcto para su distribución (por ejemplo, ssh en Debian/Ubuntu frente a sshd en RHEL/AlmaLinux).
• Falta /var/log/journal: En algunos sistemas (como AlmaLinux), debe crear manualmente este directorio y reiniciar el servicio de registro para habilitar los registros persistentes. Si omite este paso, los registros permanecerán en la memoria volátil (/run/log/journal).
• Permiso denegado (Permission denied): Si no puede leer los registros sin sudo, asegúrese de que su usuario pertenezca al grupo systemd-journal o adm (sudo usermod -aG systemd-journal $USER).

Revertir los cambios

Si desea desactivar el registro persistente y volver a los registros volátiles (por ejemplo, para ahorrar espacio en disco):

1. Elimine el directorio de almacenamiento persistente:

   sudo rm -rf /var/log/journal

2. Reinicie el servicio de registro para recrear el almacenamiento volátil en /run/log/journal:

   sudo systemctl restart systemd-journald

Conclusión

Eso es todo. Ya conoce lo esencial de la gestión de registros en Linux. Con los comandos de journalctl adecuados, puede navegar con eficacia por los registros de systemd, aplicar filtros y gestionar el espacio en disco. Tanto si necesita analizar los registros con journalctl tras un fallo como si solo quiere comprobar el estado de un servicio, dominar journalctl es un paso fundamental para mantener una infraestructura saludable.

Versión del documento: 1.0
Última actualización: mayo de 2026
Responsable: Equipo de documentación técnica