Cualquier sistema, incluso el más silencioso y tranquilo, gusta de hablar sobre sus problemas. En Linux esas confesiones se registran en archivos de registro — desde el modesto /var/log/messages hasta el coro polifónico del systemd-journal. Leer y analizar los registros correctamente es como entender el lenguaje de tu propio servidor: útil, interesante y a veces salva nervios y carrera. Veamos dónde viven los mensajes, con qué leerlos y cómo convertir el caos de líneas en conocimientos valiosos.
Para qué sirven los registros
Alguien escribe un diario para recordar momentos destacados, y el sistema escribe registros para que el administrador encuentre más rápido ese pequeño error que tumba un servicio en hora punta. Los registros ayudan a:
- rastrear errores y fallos;
- entender el comportamiento de las aplicaciones bajo carga;
- investigar incidentes de seguridad;
- recopilar estadísticas y crear métricas.
En resumen, los registros son una linterna que ilumina los rincones del sistema. Solo queda aprender a dirigir el haz hacia donde está más oscuro.
/var/log: el miembro más veterano de la familia
Antes de la llegada de systemd casi todos los eventos se almacenaban en el directorio /var/log. Aquí aún se guardan:
- /var/log/messages — mensajes generales del sistema;
- /var/log/auth.log o secure — autenticación y sudo;
- /var/log/kern.log — la voz del kernel;
- registro del servidor web en /var/log/nginx/ o apache2/;
- y una docena más de archivos que recuerdas cuando algo va mal.
Leer los registros clásicos es posible con el conjunto viejo pero fiable de herramientas: less, tail -f para lectura en vivo y el poderoso grep. Por ejemplo:
tail -f /var/log/auth.log | grep "Failed"
¿Aburrido? Sí, pero funciona incluso en una distribución de rescate minimalista.
La transición a la era systemd y journalctl
Cuando systemd llegó a muchas distribuciones, buscó una fuente única de la verdad sobre los eventos. Así nació el diario binario, legible con el comando journalctl. Sus ventajas:
- centralización — recopila mensajes del kernel, de los servicios y del propio systemd;
- metadatos — nivel de importancia, usuario, PID, y a veces incluso el nombre del perro del desarrollador (broma, por ahora);
- filtrado por tiempo, servicio, prioridad sin scripts externos.
Ejemplos que ahorran canas:
# últimas 50 líneas del registro del servicio sshd journalctl -u sshd -n 50 # errores del kernel en los últimos 30 minutos journalctl -k --since "30 min ago" -p err # ver lo que ocurrió durante el último reinicio journalctl -b -1
Y si se desea una línea en tiempo real:
journalctl -f -u nginx.service
Configuración del tamaño del registro
Por defecto el registro se almacena en /var/log/journal y puede crecer. Cambiamos los límites en /etc/systemd/journald.conf:
SystemMaxUse=1G RuntimeMaxUse=500M
Tras el cambio hay que reiniciar el demonio:
systemctl restart systemd-journald
rsyslog: clásico que aún sigue en servicio
rsyslog sigue siendo popular, especialmente si se necesita enviar registros a un servidor remoto o realizar filtrado específico. Su configuración en /etc/rsyslog.conf y /etc/rsyslog.d/ puede parecer intimidante, pero las reglas para enviar todo el tráfico auth a un host central se escriben en un par de líneas:
auth.* @log.example.com:514
De este modo se construyen agregadores corporativos de registros donde un host recoge todo. Por cierto, si se necesita TLS, basta con añadir dos "@@".
Trucos útiles para filtrar y buscar
Como leer registros a mano con frecuencia se convierte en la búsqueda de una aguja, es importante saber:
- Reducir la ventana temporal: journalctl --since "2025-05-16 10:00:00" --until "2025-05-16 12:00".
- Filtrar por prioridad: -p warning..crit — todo lo amarillo y rojo.
- Combinar criterios: tiempo + unidad + PID.
- Eliminar lo innecesario con grep -v o el filtro incorporado _PID.
No olvide jq si exporta el diario a JSON (journalctl -o json):
journalctl -u docker -o json | jq 'select(.MESSAGE | test("error"))'
Escenarios típicos: desde «Nginx no arranca» hasta «quién intentó entrar por SSH»
Tomemos dos problemas populares y mostremos brevemente cómo los registros ayudan a resolverlos.
Nginx no arranca tras cambiar la configuración
journalctl -u nginx -n 20
Lo más habitual es ver «bind() to 0.0.0.0:80 failed»: el puerto ya está ocupado por otra aplicación. lsof -i :80 mostrará rápidamente al culpable.
Ataques de fuerza bruta contra SSH
journalctl -u sshd -p warning --since yesterday | grep "Failed password"
Desde ahí es fácil extraer las direcciones IP de los atacantes y bloquearlas, por ejemplo, con Fail2Ban.
Rotación y almacenamiento: no dejes que el disco reviente
Incluso los registros más modestos pueden, sin avisar, convertirse en una novela voluminosa. Aquí entra en juego logrotate. Revisemos la configuración:
cat /etc/logrotate.d/nginx
/var/log/nginx/*.log {
weekly
rotate 4
compress
missingok
notifempty
}
Esta magia dejará cuatro archivos archivados y los comprimirá en gzip. Ejecutamos manualmente para comprobar: logrotate -f /etc/logrotate.conf.
Análisis y visualización: cuando ya hay demasiadas líneas
Leer registros de varios megabytes a mano es un placer dudoso. Entran en escena:
- GoAccess — informes instantáneos para registros web;
- Loki + Grafana — la moda de paneles gráficos;
- Graylog — interfaz web para grandes despliegues;
- Logwatch — informes diarios por correo «resumen de lo más importante».
Conectar, por ejemplo, Loki no es más difícil que montar un mueble de IKEA en el primer intento: algo de frustración, pero el resultado merece la pena. Basta configurar promtail, que lee archivos locales y los envía a Loki. Luego Grafana dibuja paneles agradables por los que el jefe otorga un punto extra a la bonificación.
Seguridad de los registros
No olvide: los registros con frecuencia contienen datos personales y contraseñas en la línea de error (sí, sabemos que «no debería pasar», pero ocurre). Por eso:
- limite el acceso al directorio /var/log con permisos adecuados;
- envíe los registros a un servidor remoto para que un atacante no pueda borrarlos localmente;
- enmascare datos sensibles con filtros de rsyslog o desde la propia aplicación;
- revise regularmente qué datos llegan al registro — a veces se filtra información de más.
Conclusión
Los registros son como los chismes en la cocina de la oficina: mucho ruido innecesario, pero entre ellos se oculta información vital. Aprendiendo a filtrar, ordenar y visualizar eventos, ahorrará horas (o incluso días) buscando las causas de fallos. Use journalctl para diagnóstico operativo, /var/log para la clásica tradición, rsyslog cuando necesite flexibilidad de enrutamiento, y Loki o Graylog para sorprender gratamente a los gerentes con informes «a color». Y que su servidor cuente solo buenas historias.
