Los logs son lo primero que hay que mirar cuando un servicio falla, alguien intenta entrar por SSH o el servidor se reinicia sin motivo aparente. En Ubuntu 24.04 conviven dos sistemas: el diario de systemd (journald), que recoge todo, y rsyslog, que escribe copias en texto plano dentro de /var/log. En esta guía verás qué contiene cada fichero, cómo leerlos sin perderte y cómo responder a preguntas concretas con grep, awk, zgrep y journalctl.

Requisitos previos

  • Un servidor con Ubuntu 24.04 LTS, por ejemplo un VPS de CubePath.
  • Un usuario no root con privilegios sudo.
  • Soltura básica con la terminal y con tuberías (|).

Paso 1: Conocer los ficheros de /var/log

Lista el contenido del directorio:

ls -lh /var/log

Estos son los ficheros más útiles en Ubuntu 24.04:

FicheroContenido
/var/log/syslogMensajes generales del sistema y de los servicios (incluido cron)
/var/log/auth.logAutenticación: SSH, sudo, su, cambios de usuarios
/var/log/kern.logMensajes del kernel: hardware, discos, OOM killer, cortafuegos
/var/log/dpkg.logPaquetes instalados, actualizados o eliminados
/var/log/apt/history.logComandos apt ejecutados y qué cambiaron
/var/log/ufw.logConexiones bloqueadas por UFW (si el registro está activo)
/var/log/cloud-init.logConfiguración inicial de la máquina en el primer arranque
/var/log/wtmp, /var/log/btmpInicios de sesión correctos y fallidos (binarios, se leen con last y lastb)
/var/log/nginx/, /var/log/mysql/...Logs propios de cada aplicación

Verás también ficheros como syslog.1 y syslog.2.gz: son versiones antiguas rotadas por logrotate. La .1 está sin comprimir y las siguientes en gzip.

Paso 2: Dar permiso de lectura a tu usuario

La mayoría de estos ficheros pertenecen al grupo adm:

ls -l /var/log/syslog /var/log/auth.log

-rw-r----- 1 syslog adm 1843210 Sep 25 10:40 /var/log/auth.log
-rw-r----- 1 syslog adm 5210442 Sep 25 10:41 /var/log/syslog

En lugar de usar sudo para cada lectura, añade tu usuario al grupo adm, cambiando your_user por tu nombre de usuario:

sudo usermod -aG adm your_user

Cierra la sesión SSH y vuelve a entrar para que el cambio surta efecto. Comprueba que ya perteneces al grupo:

id -nG

your_user adm sudo

El grupo adm también permite leer el diario completo de systemd con journalctl sin sudo.

Paso 3: Leer logs con tail, less y grep

Para ver las últimas líneas y seguir las nuevas en directo:

tail -n 50 -f /var/log/syslog

Pulsa Ctrl+C para salir. Para ficheros grandes, less permite moverse y buscar sin cargarlo todo en memoria:

less +G /var/log/syslog

+G abre el fichero por el final. Dentro de less, ?texto busca hacia atrás, n salta a la siguiente coincidencia, F entra en modo seguimiento (como tail -f) y q sale.

En Ubuntu 24.04, rsyslog escribe las fechas en formato ISO 8601, lo que facilita filtrar por hora:

2026-09-25T10:41:07.512344+00:00 web01 systemd[1]: Started nginx.service - A high performance web server and a reverse proxy server.

Para buscar errores sin distinguir mayúsculas:

grep -i "error" /var/log/syslog | tail -n 20

Para acotar a una franja horaria, filtra por el principio de la línea. Este ejemplo muestra los errores del 25 de septiembre entre las 10:00 y las 12:59:

grep -E '^2026-09-25T1[0-2]:' /var/log/syslog | grep -i error

Los ficheros rotados y comprimidos se consultan con zgrep, que funciona igual sobre ficheros normales y .gz:

zgrep -i "out of memory" /var/log/kern.log*

Paso 4: Revisar accesos por SSH y uso de sudo

/var/log/auth.log es el fichero clave para la seguridad. Los accesos correctos por SSH quedan así:

grep "Accepted" /var/log/auth.log

2026-09-25T09:12:44.103882+00:00 web01 sshd[2210]: Accepted publickey for your_user from 192.0.2.50 port 60122 ssh2: ED25519 SHA256:...

Si ves accesos desde IP que no reconoces, investígalos de inmediato.

Los intentos fallidos generan líneas Failed password o Invalid user. Para ver qué IP lo intentan más veces, extrae la dirección que sigue a from y cuenta las repeticiones:

grep "Failed password" /var/log/auth.log | grep -oE 'from [0-9a-f.:]+' | awk '{print $2}' | sort | uniq -c | sort -rn | head

    412 203.0.113.77
    158 198.51.100.9
     37 192.0.2.201

Y qué nombres de usuario prueban:

grep "Invalid user" /var/log/auth.log | awk '{for (i=1; i<=NF; i++) if ($i == "user") print $(i+1)}' | sort | uniq -c | sort -rn | head

     96 admin
     41 test
     22 ubuntu

Que haya intentos de fuerza bruta es normal en cualquier IP pública. Lo que importa es que ninguno tenga éxito: si todavía permites contraseñas, cambia a autenticación solo por clave (PasswordAuthentication no en la configuración de SSH) y valora instalar Fail2ban.

El historial de inicios de sesión también se puede consultar con last (correctos) y lastb (fallidos):

last -n 10
sudo lastb -n 10

Para auditar el uso de sudo, busca las líneas con COMMAND=:

grep "sudo:.*COMMAND=" /var/log/auth.log | tail -n 20

2026-09-25T10:02:31.884120+00:00 web01 sudo: your_user : TTY=pts/0 ; PWD=/home/your_user ; USER=root ; COMMAND=/usr/bin/apt upgrade

Paso 5: Investigar el kernel y los reinicios

El kernel registra fallos de disco, errores de red y, sobre todo, las actuaciones del OOM killer cuando se agota la memoria. Busca procesos matados por falta de memoria:

grep -i "killed process" /var/log/kern.log

2026-09-24T03:17:52.004981+00:00 web01 kernel: Out of memory: Killed process 1873 (mysqld) total-vm:2894112kB, anon-rss:1702344kB, file-rss:0kB, shmem-rss:0kB, UID:113 pgtables:3904kB oom_score_adj:0

Si aparece, el servicio no falló por sí mismo: el sistema se quedó sin memoria y el kernel eligió matarlo.

Para ver el buffer del kernel desde el último arranque, con fechas legibles, usa dmesg. En Ubuntu requiere sudo:

sudo dmesg -T | tail -n 30

Para saber cuándo se reinició el servidor:

last -x reboot shutdown | head

Si hay un reboot sin un shutdown justo antes, el reinicio no fue ordenado (corte, pánico del kernel o reinicio forzado desde el hipervisor).

Paso 6: Consultar el diario de systemd con journalctl

Todo lo que ves en /var/log/syslog pasa antes por journald, que además guarda metadatos como la unidad, la prioridad y el arranque. Eso permite filtros que con grep serían engorrosos.

Logs de un servicio concreto en la última hora:

journalctl -u nginx --since "1 hour ago"

Solo errores y mensajes más graves desde el arranque actual:

journalctl -p err -b

Logs del arranque anterior, útil tras un reinicio inesperado (-e salta al final):

journalctl -b -1 -e

Seguir en directo los mensajes de SSH (en Ubuntu 24.04 la unidad se llama ssh):

journalctl -u ssh -f

Mensajes del kernel, equivalentes a kern.log:

journalctl -k --since today

Para saber qué unidades han fallado y ver su log, combina systemctl con journalctl:

systemctl --failed
journalctl -u nombre-del-servicio -n 50 --no-pager

Comprueba cuánto ocupa el diario:

journalctl --disk-usage

Archived and active journals take up 184.0M in the file system.

Paso 7: Vigilar el espacio que ocupan los logs

Un log que crece sin control puede llenar el disco y tumbar servicios. Muestra lo que ocupa cada elemento de /var/log, ordenado de menor a mayor:

sudo du -sh /var/log/* | sort -h | tail -n 10

Si el diario de systemd ocupa demasiado, redúcelo:

sudo journalctl --vacuum-size=500M

Para fijar un límite permanente, crea un fichero de configuración adicional:

sudo mkdir -p /etc/systemd/journald.conf.d
sudo nano /etc/systemd/journald.conf.d/size.conf

[Journal]
SystemMaxUse=500M

Aplica el cambio:

sudo systemctl restart systemd-journald

Los ficheros de texto de /var/log los rota logrotate. Si uno crece demasiado, la solución es ajustar su regla en /etc/logrotate.d/, no borrarlo a mano. Si necesitas vaciar un log que un proceso tiene abierto, trúncalo en lugar de eliminarlo, porque borrarlo no libera el espacio mientras el proceso siga escribiendo:

sudo truncate -s 0 /var/log/nombre-del-log.log

Solución de problemas

grep: /var/log/auth.log: Permission denied. Tu usuario no está en el grupo adm o no has vuelto a iniciar sesión después de añadirlo. Revisa el paso 2.

No existe /var/log/syslog ni /var/log/auth.log. Algunas imágenes mínimas no incluyen rsyslog. Usa journalctl, que tiene la misma información, o instálalo con sudo apt install rsyslog.

journalctl solo muestra el arranque actual. El diario no es persistente. Comprueba que existe /var/log/journal; si no, créalo con sudo mkdir -p /var/log/journal y reinicia systemd-journald.

El disco sigue lleno tras borrar un log. Algún proceso mantiene el fichero abierto. Localízalo con sudo lsof +L1 y reinicia ese servicio.

Conclusión

Ya sabes dónde guarda Ubuntu 24.04 cada tipo de evento, cómo leer los ficheros de /var/log con tail, less, grep y zgrep, cómo detectar accesos sospechosos, reinicios y muertes por falta de memoria, y cómo filtrar el diario con journalctl. Como siguientes pasos, configura la rotación de los logs de tus aplicaciones con logrotate, protege SSH con Fail2ban a partir de los patrones de auth.log y, si gestionas varios servidores, centraliza los logs con rsyslog remoto o Grafana Loki.