En los sistemas con systemd, el demonio systemd-journald recoge en un único sitio los mensajes del kernel, de los servicios y de syslog, y journalctl es la herramienta para consultarlos. En este tutorial aprenderás a filtrar esos logs por servicio, prioridad, fecha, arranque y texto en Ubuntu 24.04, y a configurar journald para que conserve el historial entre reinicios sin llenar el disco.

Requisitos previos

Para seguir esta guía necesitas:

  • Un servidor con Ubuntu 24.04 LTS, por ejemplo un VPS de CubePath. Todo aplica también a Debian 12 y Rocky Linux 9, salvo lo indicado en el paso 5.
  • Un usuario no root con privilegios sudo. Los miembros de los grupos adm o systemd-journal pueden leer el journal sin sudo, pero en los ejemplos se usa sudo para que funcionen con cualquier usuario.

Paso 1: Leer el journal

Sin argumentos, journalctl muestra todo el journal desde la entrada más antigua, dentro de un paginador (less). Casi siempre te interesa lo más reciente, así que empieza con estas dos formas:

sudo journalctl -n 50 --no-pager

-n 50 muestra las 50 últimas líneas y --no-pager las imprime directamente en la terminal. Para seguir los mensajes nuevos en tiempo real, como con tail -f, usa -f y pulsa Ctrl+C para salir:

sudo journalctl -f

Si lees un rango grande dentro del paginador, -r invierte el orden para ver primero lo más reciente, y -e salta directamente al final.

Paso 2: Filtrar por servicio y por arranque

El filtro que más usarás es -u, que muestra solo lo que ha escrito una unidad de systemd, incluidos los mensajes de systemd sobre ella (arranques, paradas, fallos):

sudo journalctl -u ssh -n 20 --no-pager

En Ubuntu y Debian la unidad de OpenSSH se llama ssh; en Rocky Linux es sshd.

Puedes repetir -u para ver varios servicios intercalados por orden temporal:

sudo journalctl -u nginx -u php8.3-fpm --since today

Cada arranque del sistema tiene su propio identificador. Lista los arranques registrados:

sudo journalctl --list-boots

IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
 -2 5c1f0e8a0a2d4c1c9a3e0b7c2d9f1a11 Mon 2026-09-21 08:02:11 UTC Tue 2026-09-22 17:40:03 UTC
 -1 9e7b3d6a4f1c4e0d8b2a6c5d3e1f0a22 Tue 2026-09-22 17:41:25 UTC Wed 2026-09-23 23:10:47 UTC
  0 2a4c6e8f0b1d4f3a9c7e5b3d1f2e4a33 Wed 2026-09-23 23:12:02 UTC Thu 2026-09-24 12:35:10 UTC

Con -b limitas la salida a un arranque: sin valor es el actual y -b -1 el anterior. Es la forma más rápida de averiguar qué pasó justo antes de un reinicio inesperado:

sudo journalctl -b -1 -n 50 --no-pager

Para ver solo los mensajes del kernel del arranque actual (equivalente a dmesg), usa -k:

sudo journalctl -k -b --no-pager | tail -20

Paso 3: Filtrar por fecha y por prioridad

--since y --until aceptan fechas absolutas ("2026-09-24 10:00") y expresiones relativas como yesterday, today, "1 hour ago" o "-30min":

sudo journalctl -u nginx --since "2026-09-24 10:00" --until "2026-09-24 11:00"

sudo journalctl --since "30 min ago" --no-pager

Cada entrada lleva una prioridad de syslog, de 0 (emerg) a 7 (debug). Con -p muestras esa prioridad y todas las más graves, así que -p err incluye err, crit, alert y emerg:

sudo journalctl -p err -b --no-pager

También puedes indicar un rango, por ejemplo solo avisos y errores:

sudo journalctl -p warning..err --since today --no-pager
ValorNombreUso típico
0emergEl sistema no es utilizable
3errErrores de servicios
4warningAvisos que conviene revisar
6infoMensajes informativos normales
7debugDepuración

Paso 4: Buscar texto y filtrar por campos

-g (o --grep) filtra por una expresión regular sobre el mensaje. Es más rápido y más preciso que pasar la salida por grep, porque se combina con el resto de filtros. Por ejemplo, los intentos de acceso SSH con contraseña incorrecta de hoy:

sudo journalctl -u ssh -g "Failed password|Invalid user" --since today --no-pager

Si el patrón está todo en minúsculas, la búsqueda ignora mayúsculas y minúsculas; en cuanto incluye alguna mayúscula, la distingue.

Además de las unidades, cada entrada tiene campos estructurados que puedes usar como filtro con la sintaxis CAMPO=valor. Para descubrir qué campos tiene una entrada, muéstrala en formato detallado:

sudo journalctl -u ssh -n 1 -o verbose --no-pager

Algunos filtros útiles:

sudo journalctl -t sudo --since today --no-pager

-t filtra por identificador de syslog; aquí muestra cada comando ejecutado con sudo. Para filtrar por el ejecutable o por el proceso:

sudo journalctl _COMM=cron --since today --no-pager
sudo journalctl _PID=1234 --no-pager

Si indicas varios campos distintos, deben cumplirse todos a la vez; si repites el mismo campo, basta con que se cumpla uno de ellos.

Elegir el formato de salida

La opción -o cambia el formato. Los más útiles son:

  • -o short-iso: marca de tiempo ISO 8601, cómoda para comparar con otros sistemas.
  • -o cat: solo el mensaje, sin fecha ni host, ideal para copiar un error.
  • -o json: una entrada JSON por línea, lista para procesar con jq u otras herramientas.

Por ejemplo, para exportar los errores de Nginx de las últimas 24 horas a un archivo de texto que puedas adjuntar a un ticket:

sudo journalctl -u nginx -p err --since "24 hours ago" -o short-iso --no-pager > ~/nginx-errores.txt

Paso 5: Activar el almacenamiento persistente

journald puede guardar el journal en memoria (/run/log/journal, se pierde al reiniciar) o en disco (/var/log/journal). Con el valor por defecto, Storage=auto, usa el disco solo si el directorio /var/log/journal existe. En Ubuntu 24.04 y Rocky Linux 9 ese directorio ya viene creado; en algunas imágenes mínimas de Debian no.

Comprueba dónde se está guardando:

ls -d /var/log/journal
sudo journalctl --disk-usage

/var/log/journal
Archived and active journals take up 184.0M in the file system.

Para no depender de que exista el directorio, fija el modo persistente de forma explícita. En lugar de editar /etc/systemd/journald.conf, crea un archivo en el directorio de drop-ins, que no se toca en las actualizaciones:

sudo mkdir -p /etc/systemd/journald.conf.d
sudo nano /etc/systemd/journald.conf.d/10-persistente.conf

[Journal]
Storage=persistent

Con Storage=persistent, journald crea /var/log/journal si no existe. Reinicia el servicio para aplicar el cambio y vuelca a disco lo que haya en memoria:

sudo systemctl restart systemd-journald
sudo journalctl --flush

Tras el próximo reinicio del servidor, journalctl --list-boots mostrará también los arranques anteriores.

Paso 6: Limitar el espacio que ocupa el journal

Por defecto, journald usa hasta el 10 % del sistema de archivos donde vive el journal (con un máximo de 4 GB) y deja libre al menos el 15 %. En un servidor pequeño conviene fijar límites propios. Crea otro drop-in:

sudo nano /etc/systemd/journald.conf.d/20-retencion.conf

[Journal]
SystemMaxUse=1G
SystemKeepFree=2G
SystemMaxFileSize=100M
MaxRetentionSec=1month

Qué hace cada opción:

  • SystemMaxUse=1G: tamaño máximo total del journal en disco.
  • SystemKeepFree=2G: espacio que journald deja siempre libre en el sistema de archivos.
  • SystemMaxFileSize=100M: tamaño de cada archivo antes de rotarlo. Los archivos se borran enteros, así que archivos pequeños permiten ajustar mejor el límite.
  • MaxRetentionSec=1month: borra las entradas de más de un mes aunque quede espacio.

Aplica la configuración y comprueba los valores efectivos:

sudo systemctl restart systemd-journald
sudo journalctl -u systemd-journald -n 3 --no-pager

Sep 24 12:48:02 web01 systemd-journald[4321]: Journal started
Sep 24 12:48:02 web01 systemd-journald[4321]: System Journal (/var/log/journal/2a4c6e8f0b1d4f3a9c7e5b3d1f2e4a33) is 184.0M, max 1.0G, 839.9M free.

La línea max 1.0G confirma que el límite está activo.

Liberar espacio a mano

Si necesitas espacio de inmediato, --vacuum-size y --vacuum-time borran archivos archivados hasta cumplir el criterio. Primero rota el archivo activo para que también pueda eliminarse:

sudo journalctl --rotate
sudo journalctl --vacuum-time=2weeks

Deleted archived journal /var/log/journal/2a4c.../[email protected] (48.0M).
Vacuuming done, freed 96.0M of archived journals from /var/log/journal/2a4c6e8f0b1d4f3a9c7e5b3d1f2e4a33.

O limita por tamaño:

sudo journalctl --vacuum-size=500M

No hace falta programar esto con cron: con los límites del paso anterior, journald aplica la limpieza por sí mismo.

Paso 7: Controlar servicios que escriben demasiado

journald limita cuántos mensajes acepta de cada servicio: por defecto 10.000 mensajes cada 30 segundos. Si un servicio supera el límite, verás un aviso como este y los mensajes sobrantes se descartan:

sudo journalctl -u systemd-journald -g "Suppressed" --no-pager

Sep 24 13:02:11 web01 systemd-journald[4321]: Suppressed 3124 messages from nginx.service

Lo correcto suele ser reducir el nivel de log del servicio. Si necesitas conservar esos mensajes, puedes ajustar el límite solo para ese servicio con LogRateLimitIntervalSec= y LogRateLimitBurst= en su override (sudo systemctl edit nombre_del_servicio), en lugar de subirlo para todo el sistema:

[Service]
LogRateLimitIntervalSec=30s
LogRateLimitBurst=50000

Solución de problemas

  • No journal files were found o solo ves tus propios procesos: estás ejecutando journalctl sin permisos suficientes. Usa sudo o añade tu usuario al grupo systemd-journal o adm.
  • El journal no conserva arranques anteriores: revisa que exista /var/log/journal y que Storage no esté fijado a volatile en algún archivo de /etc/systemd/journald.conf.d/. Con systemd-analyze cat-config systemd/journald.conf ves la configuración combinada.
  • Mensajes de archivos corruptos: tras un apagado brusco, sudo journalctl --verify indica qué archivos están dañados. journald los aparta y sigue escribiendo en uno nuevo; puedes eliminarlos con --vacuum-* cuando ya no los necesites.

Conclusión

Ya sabes filtrar el journal por servicio, arranque, fecha, prioridad, texto y campos, exportar lo que necesitas y configurar journald para guardar el historial en disco con un tamaño y una antigüedad máximos. Con esto puedes investigar la mayoría de incidencias de un servidor sin instalar nada más.

Como siguientes pasos puedes:

  • Enviar los logs de varios servidores a un punto central con systemd-journal-remote o con un agente como Vector o Promtail.
  • Configurar reinicios y avisos automáticos para tus servicios con systemd.
  • Revisar periódicamente journalctl -p err -b como parte del mantenimiento del servidor.