Gestión de Logs con systemd-journald y rsyslog 2025-2026

[INFO] Este artículo asume un sistema Linux moderno con systemd (prácticamente todas las distribuciones hoy en día). Si usas SysVinit, los conceptos difieren.

La gestión de logs en Linux ha evolucionado drásticamente. Durante años, rsyslog fue el estándar de facto, un demonio maduro y flexible para el registro de eventos del sistema. Sin embargo, con la llegada de systemd y su subsistema de logging journald, el ecosistema se fragmentó y, a la vez, se enriqueció. La pregunta ya no es "¿cuál es mejor?", sino "¿cómo los integro para obtener lo mejor de ambos mundos?".

En este artículo, exploraremos a fondo la gestión de logs con systemd-journald y rsyslog. Verás por qué no son competidores, sino herramientas complementarias que, bien configuradas, te dan una visibilidad y control absolutos sobre el registro de eventos de tu servidor Linux.

¿Por qué dos sistemas de logging?

Para entender la necesidad de ambos, primero debemos comprender sus orígenes y fortalezas.

systemd-journald: El recolector nativo y estructurado

journald es el servicio de logging integrado en systemd. Su principal innovación es que no escribe en archivos de texto plano, sino en un journal binario. Esto le confiere ventajas únicas:

Captura estructurada: Cada entrada de log no es solo un texto. Incluye campos como _PID, _COMM, _EXE, _SYSTEMD_UNIT, PRIORITY, etc. Esto permite búsquedas extremadamente precisas con journalctl.
Integración total con systemd: Captura la salida estándar (stdout) y de error (stderr) de todos los servicios gestionados por systemd. Así, si un servicio escribe a la consola, journald lo captura automáticamente.
Bajo consumo de recursos: Al ser binario y no tener que parsear texto constantemente, es muy eficiente.

Sin embargo, journald tiene limitaciones:

No es persistente por defecto: En muchas distribuciones, los logs residen en /run/log/journal (en RAM). Si quieres persistencia, debes crear /var/log/journal.
Dificultad para reenvío tradicional: No está diseñado para enviar logs a servidores remotos vía syslog (puerto 514/UDP) de forma nativa y eficiente.
Herramientas de análisis limitadas: Aunque journalctl es potente, no ofrece las capacidades de filtrado, rotación y reenvío avanzadas de rsyslog.

rsyslog: El todoterreno del logging clásico

rsyslog es el heredero de syslogd. Es un demonio de logging extremadamente modular y configurable. Sus puntos fuertes son:

Formato de texto plano: Escribe en archivos legibles por humanos (ej. /var/log/syslog, /var/log/auth.log). Fácil de parsear con herramientas clásicas como grep, awk o tail.
Reenvío remoto: Soporta de forma nativa y eficiente el envío de logs a servidores centralizados usando protocolos UDP, TCP y TLS.
Filtrado y enrutamiento: Puedes crear reglas complejas para enviar logs de diferentes fuentes a diferentes destinos (archivos, bases de datos, comandos, etc.).
Rotación y compresión: Integración perfecta con logrotate para gestionar el tamaño y la antigüedad de los archivos de log.

Su principal desventaja es que no captura logs de servicios systemd de forma nativa. Necesita que los servicios escriban explícitamente a syslog o que se configure un socket de entrada.

El matrimonio perfecto: Cómo integrar journald y rsyslog

La estrategia ganadora es simple: dejar que journald capture todo (es su punto fuerte) y configurar rsyslog para que lea del journal y realice las tareas que journald no hace bien (persistencia, reenvío remoto, filtrado complejo).

Esta integración se logra mediante el módulo imjournal de rsyslog.

Paso 1: Asegurar la persistencia de journald

Por defecto, muchos sistemas borran los logs de journald al reiniciar. Para hacerlos persistentes:

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

# Ajustar permisos (importante)
sudo systemd-tmpfiles --create --prefix /var/log/journal

# Forzar la rotación y reiniciar journald
sudo journalctl --rotate
sudo systemctl restart systemd-journald

[TIP] Verifica que /var/log/journal contenga ahora subdirectorios con hashes. Ahí estarán los logs binarios persistentes.

Paso 2: Configurar rsyslog para leer de journald

Abre el archivo de configuración principal de rsyslog (normalmente /etc/rsyslog.conf o /etc/rsyslog.d/50-default.conf). Busca y descomenta o añade las siguientes líneas:

# Cargar el módulo imjournal
module(load="imjournal" StateFile="/var/lib/rsyslog/imjournal.state")

# Opcional: Cargar el módulo omuxsock para enviar logs de vuelta a journald (si es necesario)
# module(load="omuxsock" Socket="/run/systemd/journal/syslog")

El archivo StateFile es crucial. Rsyslog lo usa para recordar qué entradas del journal ya ha procesado, evitando duplicados.

Luego, define las reglas de filtrado y destino. Por ejemplo, para separar logs por facilidad y prioridad:

# Reglas tradicionales de rsyslog
auth,authpriv.*                 /var/log/auth.log
*.*;auth,authpriv.none          -/var/log/syslog
cron.*                          /var/log/cron.log
daemon.*                        -/var/log/daemon.log
kern.*                          -/var/log/kern.log
lpr.*                           -/var/log/lpr.log
mail.*                          -/var/log/mail.log
user.*                          -/var/log/user.log

Finalmente, reinicia rsyslog:

sudo systemctl restart rsyslog

A partir de este momento, rsyslog leerá del journal binario y escribirá en los archivos de texto clásicos. ¡Tienes lo mejor de ambos mundos!

Gestión avanzada con journalctl

Aunque rsyslog te da los archivos de texto, journalctl sigue siendo la herramienta más potente para consultas rápidas y precisas sobre el journal binario.

Filtrado por servicio

# Logs de un servicio específico
journalctl -u nginx.service

# Logs desde la última hora
journalctl -u nginx.service --since "1 hour ago"

# Logs en tiempo real (como tail -f)
journalctl -u nginx.service -f

Filtrado por prioridad

# Solo errores y superiores (0=emerg, 1=alert, 2=crit, 3=err)
journalctl -p err

# Mensajes de info y superiores
journalctl -p info

Filtrado por campos estructurados

Aquí está la magia de journald. Puedes buscar por cualquier campo:

# Logs de un PID específico
journalctl _PID=1234

# Logs de un ejecutable
journalctl _EXE=/usr/sbin/sshd

# Logs de un usuario específico
journalctl _UID=1000

# Logs de una sesión de sistema
journalctl _BOOT_ID=$(journalctl --list-boots | tail -n 1 | awk '{print $1}')

Combinación de filtros

# Errores de SSH en la última hora
journalctl -u ssh.service -p err --since "1 hour ago"

# Todos los logs del kernel de la sesión actual
journalctl -k -b 0

[WARNING] El journal puede crecer mucho si no se gestiona. Por defecto, journald limita el tamaño al 10% del sistema de archivos. Puedes ajustarlo en /etc/systemd/journald.conf con la variable SystemMaxUse=500M.

Reenvío remoto de logs con rsyslog

Una de las razones principales para usar rsyslog es el reenvío centralizado. Aquí te muestro una configuración básica y segura con TCP.

Configuración del servidor central

En el servidor que recibirá los logs (ej. logserver.example.com), edita /etc/rsyslog.conf:

# Hacer que rsyslog escuche en TCP (puerto 514)
module(load="imtcp")
input(type="imtcp" port="514")

# Almacenar logs por host remoto
$template RemoteLogs,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?RemoteLogs

Configuración del cliente

En cada máquina que enviará logs, edita /etc/rsyslog.conf:

# *.* = todas las facilidades y prioridades
# @@ = TCP (una @ sería UDP)
*.* @@logserver.example.com:514

[TIP] Para entornos de producción, usa siempre TCP en lugar de UDP. Aunque UDP es más rápido, no garantiza la entrega. Además, considera usar TLS para cifrar el tráfico.

Rotación de logs con logrotate

Aunque journald gestiona su propio tamaño, los archivos de texto de rsyslog necesitan rotación. logrotate es la herramienta estándar. Un ejemplo de configuración en /etc/logrotate.d/rsyslog:

/var/log/syslog
/var/log/auth.log
/var/log/kern.log
{
    rotate 7
    daily
    missingok
    notifempty
    compress
    delaycompress
    sharedscripts
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

[INFO] La directiva sharedscripts con postrotate ejecuta el script de rsyslog una vez después de rotar todos los archivos, no por cada uno. Esto evita reinicios múltiples del demonio.

Conclusión: Un ecosistema de logging robusto

La gestión de logs en Linux moderno no tiene por qué ser una dicotomía entre systemd-journald y rsyslog. Al integrarlos, obtienes:

Captura total y estructurada gracias a journald.
Persistencia en texto plano y filtrado avanzado con rsyslog.
Reenvío remoto fiable y seguro.
Herramientas de consulta potentes (journalctl para búsquedas rápidas, grep para análisis en archivos).

Esta arquitectura es la base de cualquier sistema de monitoreo y auditoría en Linux. Dominarla te permitirá diagnosticar problemas con rapidez, cumplir con requisitos de compliance y mantener la salud de tus servidores.

Ahora que conoces la teoría, te animo a implementarla. Empieza por hacer persistentes los logs de journald, configura rsyslog para leer de él, y luego explora el reenvío remoto. Tu yo del futuro (cuando un servicio falle a las 3 AM) te lo agradecerá.