Cuando algo falla en un servidor Linux, tu primer instinto es revisar los logs. En cualquier distribucion Linux moderna con systemd, la herramienta principal para esa tarea es journalctl. Proporciona una interfaz unica para consultar logs estructurados de cada servicio, el kernel y el proceso de arranque — todo indexado y filtrable por tiempo, prioridad, unidad de servicio y docenas de otros campos.

Esta guia cubre todo lo que necesitas para usar journalctl de forma efectiva en la administracion diaria y la resolucion de incidentes, desde consultas basicas hasta filtrado avanzado, configuracion de almacenamiento persistente e integracion con herramientas externas de analisis de logs.

Requisitos Previos

Antes de comenzar, asegurate de tener:

  • Un sistema Linux con systemd (Ubuntu 20.04+, Debian 11+, RHEL/CentOS 8+, Fedora, Arch o similar)
  • Acceso al terminal con privilegios sudo
  • Familiaridad basica con servicios systemd (systemctl start, systemctl status)

Entendiendo el Journal de systemd

El journal de systemd es un sistema de logging centralizado gestionado por el servicio systemd-journald. A diferencia del syslog tradicional, que escribe texto plano en archivos de /var/log/, el journal almacena entradas en un formato binario estructurado que incluye metadatos con cada linea de log:

  • Marca de tiempo con precision de microsegundos
  • ID de arranque — que sesion de arranque produjo la entrada
  • Nombre de unidad — que servicio systemd la genero
  • PID y UID — identificadores de proceso y usuario
  • Nivel de prioridad — desde emergencia (0) hasta depuracion (7)
  • ID de maquina — util en configuraciones multi-servidor

Esta estructura es lo que hace tan poderoso a journalctl: puedes filtrar por cualquier combinacion de estos campos sin escribir patrones grep complejos.

Verifica que journald esta ejecutandose en tu sistema:

systemctl status systemd-journald

Consulta cuanto espacio en disco usa actualmente el journal:

journalctl --disk-usage

Uso Basico de journalctl

Ver Todos los Logs

journalctl

Esto abre el journal completo en un paginador (normalmente less). Presiona q para salir, / para buscar y G para ir al final (entradas mas recientes).

Ver las Entradas Mas Recientes

# Mostrar las ultimas 50 lineas
journalctl -n 50

# Mostrar las ultimas 100 lineas sin paginador (salida directa)
journalctl -n 100 --no-pager

Seguir Logs en Tiempo Real

journalctl -f

Funciona como tail -f pero para todo el journal. Presiona Ctrl+C para detenerlo. Puedes combinar -f con cualquier filtro:

# Seguir solo logs de nginx
journalctl -f -u nginx.service

Orden Inverso (Mas Recientes Primero)

journalctl -r

Filtrado por Tiempo

El filtrado por tiempo es una de las funcionalidades mas utiles de journalctl para investigacion de incidentes.

Rangos de Tiempo Absolutos

# Logs desde una fecha y hora especifica
journalctl --since "2025-12-26 08:00:00"

# Logs entre dos marcas de tiempo
journalctl --since "2025-12-25 18:00" --until "2025-12-26 06:00"

# Logs de un dia especifico (dia completo)
journalctl --since "2025-12-25" --until "2025-12-26"

Rangos de Tiempo Relativos

# Logs de la ultima hora
journalctl --since "1 hour ago"

# Logs de los ultimos 30 minutos
journalctl --since "30 min ago"

# Desde ayer
journalctl --since yesterday

# Solo hoy
journalctl --since today

Arranque Actual vs. Arranques Anteriores

# Logs solo del arranque actual
journalctl -b

# Logs del arranque anterior
journalctl -b -1

# Logs de hace dos arranques
journalctl -b -2

# Listar todos los arranques disponibles
journalctl --list-boots

La salida de --list-boots muestra IDs de arranque y marcas de tiempo, lo cual es invaluable para investigar que sucedio antes de un reinicio inesperado.

Filtrado por Unidad de Servicio

Aqui es donde journalctl ahorra mas tiempo comparado con el analisis de logs tradicional.

Servicio Individual

# Todos los logs de nginx
journalctl -u nginx.service

# Todos los logs del demonio SSH
journalctl -u sshd.service

# Todos los logs de PostgreSQL
journalctl -u postgresql.service

Multiples Servicios

# Logs de nginx y PHP-FPM
journalctl -u nginx.service -u php8.1-fpm.service

Combinar Filtros de Servicio y Tiempo

# Errores de nginx en las ultimas 2 horas
journalctl -u nginx.service --since "2 hours ago" -p err

Servicios de Usuario

# Logs de un servicio a nivel de usuario
journalctl --user -u myapp.service

Filtrado por Prioridad

Los niveles de prioridad syslog van de 0 (emergencia) a 7 (depuracion):

PrioridadPalabra claveDescripcion
0emergSistema inutilizable
1alertAccion inmediata requerida
2critCondiciones criticas
3errCondiciones de error
4warningCondiciones de advertencia
5noticeNormal pero significativo
6infoInformativo
7debugMensajes de depuracion

Filtrar por Prioridad Maxima

# Mostrar errores y superiores (0-3)
journalctl -p err

# Mostrar advertencias y superiores (0-4)
journalctl -p warning

# Mostrar criticos y superiores (0-2)
journalctl -p crit

Rango de Prioridad

# Mostrar solo advertencias y errores (excluir criticos/emergencia)
journalctl -p warning..err

Combinar con Otros Filtros

# Errores de nginx en las ultimas 24 horas
journalctl -u nginx.service -p err --since "24 hours ago"

Filtrado por Otros Campos

journalctl puede filtrar por cualquier campo almacenado en el journal. Lista los campos disponibles:

journalctl --fields

Filtros de Campos Comunes

# Logs de un PID especifico
journalctl _PID=1234

# Logs de un usuario especifico
journalctl _UID=1000

# Logs del kernel
journalctl -k
# o equivalentemente:
journalctl _TRANSPORT=kernel

# Logs de un binario especifico
journalctl /usr/sbin/sshd

# Logs de un hostname especifico (en configuraciones multi-servidor)
journalctl _HOSTNAME=webserver01

Combinar Filtros de Campo

Cuando especificas multiples campos diferentes, se combinan con logica AND:

# Logs del UID 1000 Y prioridad error
journalctl _UID=1000 -p err

Cuando especificas el mismo campo multiples veces, se combinan con logica OR:

# Logs del PID 1234 O PID 5678
journalctl _PID=1234 _PID=5678

Formatos de Salida

journalctl soporta varios formatos de salida para diferentes casos de uso:

# Formato corto predeterminado (similar a syslog)
journalctl -o short

# Formato corto con marcas de tiempo ISO
journalctl -o short-iso

# Salida estructurada completa
journalctl -o verbose

# Formato JSON (un objeto por linea)
journalctl -o json

# JSON con formato legible
journalctl -o json-pretty

# Solo el mensaje (sin metadatos)
journalctl -o cat

# Formato de exportacion binario (para journalctl --merge)
journalctl -o export

Salida JSON para Analisis de Logs

El formato JSON es particularmente util para enviar a herramientas de analisis:

# Extraer todos los errores de nginx como JSON
journalctl -u nginx.service -p err -o json --no-pager | jq '.'

# Obtener campos especificos
journalctl -u sshd.service -o json --no-pager | jq '{timestamp: .__REALTIME_TIMESTAMP, message: .MESSAGE, pid: ._PID}'

Configuracion de Almacenamiento Persistente

Por defecto, algunas distribuciones almacenan los logs del journal solo en memoria (/run/log/journal/), lo que significa que se pierden al reiniciar.

Habilitar Almacenamiento Persistente

# Crear el directorio de almacenamiento persistente
sudo mkdir -p /var/log/journal

# Establecer la propiedad correcta
sudo systemd-tmpfiles --create --prefix /var/log/journal

# Reiniciar journald
sudo systemctl restart systemd-journald

Configurar Limites de Retencion

Edita /etc/systemd/journald.conf:

[Journal]
# Espacio maximo en disco para archivos del journal
SystemMaxUse=500M

# Tamano maximo de archivos individuales del journal
SystemMaxFileSize=50M

# Tiempo maximo para mantener entradas
MaxRetentionSec=1month

# Espacio maximo en disco para journal en memoria (volatil)
RuntimeMaxUse=100M

Despues de editar, reinicia el servicio:

sudo systemctl restart systemd-journald

Limpieza Manual

# Eliminar entradas anteriores a 2 semanas
sudo journalctl --vacuum-time=2weeks

# Reducir el journal a un maximo de 500MB
sudo journalctl --vacuum-size=500M

# Mantener solo los 5 archivos de journal mas recientes
sudo journalctl --vacuum-files=5

Verificar la Configuracion

# Verificar uso de disco actual
journalctl --disk-usage

# Mostrar configuracion del journal
systemd-analyze cat-config systemd/journald.conf

Mensajes del Kernel

Para diagnostico a nivel de kernel, journalctl reemplaza el comando dmesg con mejor filtrado:

# Todos los mensajes del kernel
journalctl -k

# Mensajes del kernel del arranque actual
journalctl -k -b

# Solo errores del kernel
journalctl -k -p err

# Mensajes del kernel de un arranque anterior
journalctl -k -b -1

Esto es esencial para diagnosticar problemas de hardware, controladores, errores del sistema de archivos y OOM (falta de memoria).

Ejemplos Practicos de Diagnostico

Investigar una Caida de Servicio

# Verificar cuando fallo el servicio por ultima vez
systemctl status myapp.service

# Ver las ultimas 200 lineas antes de la caida
journalctl -u myapp.service -n 200 --no-pager

# Buscar OOM kills alrededor del mismo tiempo
journalctl -k --since "1 hour ago" | grep -i "oom\|killed process"

Diagnosticar Fallos de Inicio de Sesion SSH

# Todos los mensajes de autenticacion SSH
journalctl -u sshd.service | grep -i "failed\|invalid\|accepted"

# Intentos SSH fallidos en las ultimas 24 horas
journalctl -u sshd.service --since "24 hours ago" -p warning

Monitorear Problemas de Disco y Sistema de Archivos

# Errores del sistema de archivos desde el kernel
journalctl -k | grep -i "ext4\|xfs\|btrfs\|i/o error\|read-only"

# Mensajes relacionados con disco
journalctl -k | grep -i "sd[a-z]\|nvme\|ata"

Verificar Problemas de Arranque

# Log completo del ultimo arranque fallido
journalctl -b -1 -p err

# Listar todos los arranques para encontrar el problematico
journalctl --list-boots

# Mostrar solo servicios que fallaron al iniciar durante el arranque
journalctl -b -p err | grep "Failed to start"

Integracion con Herramientas Externas

Reenviar a rsyslog

Si necesitas archivos de log tradicionales junto con el journal, configura rsyslog para leer del journal. En /etc/rsyslog.conf:

module(load="imjournal")

Exportar para Elasticsearch/Loki

# Exportar como JSON para ingesta
journalctl -o json --since "1 hour ago" --no-pager > /tmp/journal-export.json

# Enviar a un endpoint remoto
journalctl -f -o json | curl -X POST -H "Content-Type: application/json" -d @- http://logserver:9200/journal/_bulk

Usar con systemd-journal-remote

Para logging centralizado en multiples servidores, systemd proporciona systemd-journal-remote:

# Instalar en el servidor central
sudo apt install systemd-journal-remote

# Habilitar el receptor
sudo systemctl enable --now systemd-journal-remote.socket

Solucion de Problemas

Archivos del Journal Corruptos

# Verificar integridad del journal
journalctl --verify

# Si estan corruptos, rotar y empezar de nuevo
sudo journalctl --rotate
sudo journalctl --vacuum-time=1s

Sin Logs de un Servicio Especifico

  1. Verifica que el servicio usa salida estandar:
systemctl show myapp.service | grep -i "standard\|log"
  1. Asegurate de que el archivo de unidad redirige la salida al journal:
[Service]
StandardOutput=journal
StandardError=journal

journalctl es Lento con Journals Grandes

# Usa --since para limitar el rango de busqueda
journalctl --since "1 hour ago" -u myapp.service

# Reduce el tamano del journal
sudo journalctl --vacuum-size=200M

Resumen

journalctl es la herramienta estandar para consultar logs en sistemas Linux basados en systemd. Puntos clave:

  • Usa -u para filtrar por servicio, -p para filtrar por prioridad, y --since/--until para rangos de tiempo
  • Combina filtros para busquedas especificas: journalctl -u nginx -p err --since "1 hour ago"
  • Usa -b para limitar consultas al arranque actual o sesiones de arranque anteriores
  • Habilita almacenamiento persistente con mkdir -p /var/log/journal si tu distribucion usa almacenamiento volatil por defecto
  • Configura limites de retencion en /etc/systemd/journald.conf para evitar el agotamiento de disco
  • Usa -o json para integracion con pipelines de analisis de logs como Elasticsearch o Loki
  • Usa journalctl -f en lugar de tail -f para monitoreo en tiempo real con filtrado

Para temas relacionados, consulta nuestras guias sobre Logrotate: Gestionar Archivos de Log en Linux y Configuracion de Elasticsearch para Analisis de Logs.