Antes de que journald existiera, y todavía hoy en paralelo con él, el sistema de logging de Linux descansaba sobre una idea simple: los mensajes se escriben en archivos de texto plano bajo /var/log/. No hay formato binario, no hay índices, no hace falta ninguna herramienta especial para leerlos — basta con grep, tail o less. Esa simplicidad es exactamente por qué el modelo sigue vivo en producción.
El actor central es rsyslog, un daemon que recibe mensajes del kernel, de procesos del sistema y de aplicaciones, y los distribuye a archivos según reglas de filtrado. La palabra clave es distribuye: rsyslog no es un receptor pasivo, es un enrutador de mensajes. Cada mensaje llega con una facility (quién lo genera: auth, kern, mail, daemon…) y una severity (qué gravedad tiene: emerg, alert, crit, err, warning, notice, info, debug). La combinación de ambas decide adónde va a parar.
En Debian el archivo que recibe los mensajes generales del sistema es /var/log/syslog. Los mensajes del kernel van a /var/log/kern.log. Los eventos de autenticación — logins SSH, intentos fallidos, sudo, su — van a /var/log/auth.log. Las instalaciones de paquetes dejan rastro en /var/log/dpkg.log y en /var/log/apt/history.log. Cada uno de esos archivos existe porque hay una regla en la configuración de rsyslog que lo dice explícitamente.
[Ubuntu]: En Ubuntu el archivo de logs generales se llama /var/log/messages en versiones antiguas, pero en versiones recientes con journald como fuente primaria puede estar ausente o vacío; /var/log/syslog es el equivalente habitual allí también.
En sistemas modernos con systemd, journald captura absolutamente todo primero — mensajes del kernel vía kmsg, salida de unidades systemd, llamadas a syslog() desde procesos. Rsyslog entonces puede conectarse al journal como fuente y re-escribir esos mensajes en archivos de texto. Esa coexistencia no es redundancia inútil: permite que herramientas de monitorización antiguas que solo saben parsear archivos planos (Nagios, scripts de grep heredados, SIEMs que leen por tail -f) sigan funcionando sin modificación.
El problema con archivos que solo crecen es evidente: sin gestión, /var/log/syslog puede comerse el disco en un servidor con logging verboso. Ahí entra logrotate, que se ejecuta diariamente desde cron (en /etc/cron.daily/logrotate) y aplica políticas de rotación definidas en /etc/logrotate.conf y en archivos individuales bajo /etc/logrotate.d/. Lo que podría salir mal si no está configurado correctamente: archivos de log que crecen sin límite hasta llenar el disco, lo que en muchos servicios provoca que el proceso que intenta escribir su log empiece a fallar en cascada.
# ── Exploración del estado actual ──────────────────────────────────────
# Ver qué archivos de log existen y cuándo se modificaron por última vez
ls -lh /var/log/syslog* /var/log/auth.log* /var/log/kern.log*
# Seguir los logs generales en tiempo real (equivalente a journalctl -f)
tail -f /var/log/syslog
# Buscar todos los intentos de autenticación fallida de las últimas 24h
grep "Failed password" /var/log/auth.log | tail -20
# Ver instalaciones de paquetes recientes
grep " install " /var/log/dpkg.log | tail -10
# ── Configuración de rsyslog ───────────────────────────────────────────
# Ver las reglas activas (facility.severity → destino)
grep -v "^#" /etc/rsyslog.conf | grep -v "^$"
# La configuración modular vive en /etc/rsyslog.d/
ls /etc/rsyslog.d/
# El módulo imjournal hace que rsyslog lea desde el journal de systemd
# en lugar de /dev/log directamente; así no se pierden mensajes previos
grep -r "imjournal\|imuxsock" /etc/rsyslog.conf /etc/rsyslog.d/
# ── Añadir una regla de rsyslog personalizada ──────────────────────────
# Crear un archivo de configuración para capturar solo errores críticos
# de cualquier facility en un archivo separado
cat > /etc/rsyslog.d/50-errores-criticos.conf << 'EOF'
# Captura mensajes de severidad err o superior de cualquier facility
# El signo - antes de la ruta activa escritura asíncrona (menos fsync)
*.err -/var/log/errores-criticos.log
EOF
# Verificar la sintaxis antes de recargar
rsyslogd -N1
# Recargar rsyslog para aplicar el cambio
systemctl reload rsyslog
# ── Inspeccionar la configuración de logrotate ─────────────────────────
# Ver la política global
cat /etc/logrotate.conf
# Ver la política específica para syslog (y auth.log, kern.log)
cat /etc/logrotate.d/rsyslog
# ── Crear una política de rotación personalizada ───────────────────────
cat > /etc/logrotate.d/errores-criticos << 'EOF'
/var/log/errores-criticos.log {
# Rotar semanalmente aunque el archivo no haya crecido
weekly
# Mantener 4 semanas de histórico
rotate 4
# Comprimir archivos rotados con gzip
compress
# No comprimir el último archivo rotado (puede estar siendo leído)
delaycompress
# No fallar si el archivo no existe todavía
missingok
# No rotar si el archivo está vacío
notifempty
# Crear el nuevo archivo con estos permisos tras rotar
create 0640 root adm
# Enviar SIGHUP a rsyslog después de rotar para que reabra el archivo
postrotate
/usr/lib/rsyslog/rsyslog-rotate
endscript
}
EOF
# Probar la rotación en modo simulación (--debug muestra qué haría)
logrotate --debug /etc/logrotate.d/errores-criticos
# Forzar una rotación real aunque no se cumpla la condición de tiempo
logrotate --force /etc/logrotate.d/errores-criticos
# Confirmar que el archivo rotado existe y el nuevo está vacío
ls -lh /var/log/errores-criticos.log*
Qué está pasando en cada decisión relevante
El grep -v "^#" /etc/rsyslog.conf | grep -v "^$" es el primer paso real cuando heredas un sistema: la configuración por defecto de rsyslog en Debian tiene muchas líneas comentadas y la estructura real queda oculta entre el ruido. Filtrando comentarios y líneas vacías ves exactamente qué facility/severity va a qué archivo, sin suposiciones.
La búsqueda de imjournal e imuxsock importa porque define el modelo de integración. Si imjournal está activo, rsyslog está leyendo del journal de systemd — lo que significa que los mensajes ya pasaron por journald antes de llegar a los archivos de texto. Si solo está imuxsock, rsyslog escucha en el socket /dev/log directamente, que es el mecanismo clásico. En Debian Bookworm la configuración por defecto usa imuxsock más imklog para el kernel; imjournal está disponible pero no habilitado por defecto para evitar duplicados.
En la regla de rsyslog, el guion delante de la ruta (-/var/log/errores-criticos.log) desactiva el fsync() síncrono después de cada escritura. Sin ese guion, rsyslog llama a fsync() en cada mensaje, lo que es seguro ante un crash pero destruye el rendimiento en un sistema con logging intenso. Para un archivo de errores críticos la sincronía tiene sentido, pero para /var/log/syslog con cientos de mensajes por segundo, el guion es imprescindible.
El rsyslogd -N1 antes de recargar hace una validación de sintaxis sin iniciar el daemon. El -N1 significa “nivel 1 de comprobación”: verifica la sintaxis básica del fichero de configuración. Omitir este paso y hacer directamente systemctl reload rsyslog con un error de sintaxis puede dejar rsyslog en un estado donde deja de escribir logs sin ningún aviso obvio.
En la configuración de logrotate, delaycompress trabaja junto con compress: el archivo recién rotado (errores-criticos.log.1) no se comprime inmediatamente porque rsyslog podría seguir escribiendo en él brevemente tras recibir el SIGHUP. El siguiente ciclo de rotación lo comprime ya con seguridad. Sin delaycompress, un script de monitorización que esté leyendo el archivo rotado encontraría que de repente se convirtió en un .gz que no puede leer con tail.
La directiva postrotate llama a /usr/lib/rsyslog/rsyslog-rotate, que en Debian es un script que envía la señal correcta a rsyslog para que cierre el descriptor de archivo antiguo y abra uno nuevo con el mismo nombre. Sin este paso, rsyslog seguiría escribiendo en el inodo del archivo rotado (el descriptor de archivo sigue siendo válido aunque el nombre haya cambiado), y el archivo nuevo que logrotate acaba de crear quedaría vacío para siempre mientras el rotado sigue creciendo.
N° 70