Cómo se registran los eventos en Linux: systemd, journald, rsyslog y auditd

Cuando empiezas a administrar Linux aparecen varios nombres que parecen hacer lo mismo: systemd, journald, syslog, rsyslog y auditd.

No hacen lo mismo.

La forma más útil de entenderlos es pensar en quién produce eventos, quién los recoge, dónde se guardan y con qué herramienta se consultan.

El mapa mental completo

                 Linux
                   │
        ┌──────────┴──────────┐
        │                     │
     systemd                kernel
        │                     │
  administra units            │
  y servicios                 │
        │                     │
        └──────┬──────────────┘
               │ logs/eventos
               ▼
        systemd-journald
               │
       journal estructurado
               │
       ┌───────┴────────┐
       │                │
  journalctl         rsyslog
                        │
                  archivos texto
                        │
                  /var/log/*

kernel ── Linux Audit subsystem ── auditd
                                  │
                                  ▼
                       /var/log/audit/audit.log
                                  │
                         ausearch / aureport

La separación importante es esta:

• systemd administra servicios y otras units.
• journald recoge logs del sistema.
• syslog es un mecanismo/formato tradicional de logging.
• rsyslog es un daemon que implementa syslog y normalmente escribe archivos de texto.
• auditd registra eventos de auditoría orientados a seguridad y trazabilidad.

1. systemd: el administrador

systemd es normalmente el proceso PID 1 y coordina el arranque y buena parte de los servicios del sistema.

Por ejemplo:

systemctl status ssh
systemctl restart ssh
systemctl enable ssh

Una aplicación gestionada por systemd suele estar definida mediante una unit como:

ssh.service
nginx.service
postgresql.service

systemd no es, en sí mismo, el almacén de logs. Para eso utiliza principalmente systemd-journald.

2. journald: el recolector central de logs

systemd-journald recibe eventos de distintas fuentes:

kernel
servicios de systemd
stdout/stderr de servicios
mensajes enviados mediante syslog
otros componentes del sistema

Por eso puedes hacer:

journalctl

Y ver una gran parte de la actividad del sistema desde un único lugar.

Para un servicio concreto:

journalctl -u ssh

Desde el boot actual:

journalctl -b

Seguir nuevos mensajes:

journalctl -f

Solo errores:

journalctl -p err

Y combinarlo con herramientas Unix tradicionales:

journalctl -u ssh | grep -i failed

Ese último patrón es especialmente útil: journalctl selecciona la fuente y grep filtra el contenido.

¿Dónde guarda journald los datos?

Puede utilizar dos ubicaciones principales:

/run/log/journal/
/var/log/journal/

/run/log/journal/ es almacenamiento volátil: normalmente se pierde al reiniciar.

/var/log/journal/ es persistente.

La configuración está en:

/etc/systemd/journald.conf

Un valor común es:

Storage=auto

Con auto, journald utiliza almacenamiento persistente cuando el directorio correspondiente está disponible; de lo contrario puede trabajar de forma volátil.

Puedes inspeccionar el espacio usado por el journal con:

journalctl --disk-usage

3. syslog no es exactamente un programa

Aquí aparece una confusión frecuente.

Syslog es una familia de mecanismos y convenciones para enviar y clasificar mensajes de log. Cuando alguien dice “mira el syslog”, muchas veces se refiere a un archivo como:

/var/log/syslog

Pero quien escribe ese archivo suele ser un daemon concreto.

En Ubuntu, históricamente, ese daemon suele ser rsyslog.

4. rsyslog: logs tradicionales en archivos de texto

rsyslog puede recibir mensajes y escribirlos en archivos bajo /var/log.

Ejemplos típicos:

/var/log/syslog
/var/log/auth.log
/var/log/kern.log

No todos los sistemas modernos tendrán exactamente esos archivos: depende de la distribución, los paquetes instalados y la configuración.

La gran ventaja frente al journal binario/estructurado es que estos son archivos de texto normales:

less /var/log/syslog

tail -f /var/log/syslog

grep sshd /var/log/auth.log

Por eso en una máquina Ubuntu puedes encontrar el mismo tipo de evento accesible de dos maneras:

journalctl -u ssh

Y:

grep sshd /var/log/auth.log

No significa necesariamente que dos subsistemas independientes hayan detectado el evento. Muchas veces el mensaje pasó primero por la infraestructura de logging y después fue persistido también por rsyslog en un archivo tradicional.

5. auditd: cuando necesitas saber quién hizo qué

journald y rsyslog son excelentes para saber qué dijeron el kernel y las aplicaciones.

Pero seguridad plantea preguntas más específicas:

¿qué usuario modificó este archivo?
¿qué proceso ejecutó esta syscall?
¿quién intentó autenticarse?
¿qué ejecutable originó la acción?
¿qué identidad de login estaba detrás del proceso?

Ahí entra Linux Audit y su daemon auditd.

Su log habitual es:

/var/log/audit/audit.log

Y las herramientas principales son:

ausearch
aureport
auditctl

Por ejemplo:

ausearch -m USER_LOGIN -ts today -i

O un resumen de autenticaciones:

aureport -au

auditctl sirve, entre otras cosas, para inspeccionar o configurar reglas de auditoría:

auditctl -l

Una diferencia esencial es que auditd puede trabajar con eventos generados por el Linux Audit subsystem del kernel, incluyendo información de syscalls, procesos, UIDs y reglas de vigilancia que los logs normales no tienen por qué registrar.

journald vs rsyslog vs auditd

Sistema	Pregunta principal	Lectura típica	Almacenamiento típico
journald	¿qué está diciendo el sistema?	journalctl	/run/log/journal o /var/log/journal
rsyslog	¿qué logs tradicionales tengo en texto?	less, tail, grep	/var/log/*
auditd	¿quién hizo qué desde el punto de vista de auditoría?	ausearch, aureport	/var/log/audit/audit.log

Un ejemplo: investigar SSH

Supongamos que queremos investigar accesos SSH.

Primero podemos mirar el servicio:

systemctl status ssh

Después sus logs:

journalctl -u ssh

Filtrar fallos:

journalctl -u ssh | grep -i failed

Si rsyslog está configurado para autenticación:

grep sshd /var/log/auth.log

Y si queremos revisar eventos de auditoría relacionados con login:

ausearch -m USER_LOGIN,USER_AUTH -ts today -i

Cada herramienta responde a una capa diferente del problema.

Cómo comprobar qué tienes funcionando

systemctl status systemd-journald
systemctl status rsyslog
systemctl status auditd

También puedes comprobar si existen los almacenamientos:

ls -ld /run/log/journal /var/log/journal 2>/dev/null
ls -l /var/log/syslog /var/log/auth.log 2>/dev/null
ls -l /var/log/audit/audit.log 2>/dev/null

La regla práctica

Cuando estés diagnosticando Linux, piensa así:

¿El servicio está funcionando?
    -> systemctl

¿Qué dijo el servicio o el kernel?
    -> journalctl

¿Quiero buscar en logs tradicionales de texto?
    -> /var/log/* + grep/tail/less

¿Necesito trazabilidad de seguridad sobre quién hizo qué?
    -> auditd + ausearch/aureport

Con ese mapa mental, los distintos sistemas dejan de parecer herramientas duplicadas y empiezan a verse como capas complementarias de observabilidad y auditoría en Linux.