---
title: "Cómo analizar los logs de /var/log en Ubuntu 24.04"
description: "Aprende qué guarda cada log de /var/log en Ubuntu 24.04 y cómo buscar errores, accesos SSH fallidos y fallos de servicios con grep, awk, zgrep y journalctl."
category: "Monitoring Logging"
language: es
source: https://cubepath.com/es/docs/monitoring-logging/analisis-de-logs-del-sistema-linux-var-log
updated: 2026-09-25
---

# Cómo analizar los logs de /var/log en Ubuntu 24.04

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:

```bash
ls -lh /var/log
```

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

| Fichero | Contenido |
|---------|-----------|
| `/var/log/syslog` | Mensajes generales del sistema y de los servicios (incluido cron) |
| `/var/log/auth.log` | Autenticación: SSH, `sudo`, `su`, cambios de usuarios |
| `/var/log/kern.log` | Mensajes del kernel: hardware, discos, OOM killer, cortafuegos |
| `/var/log/dpkg.log` | Paquetes instalados, actualizados o eliminados |
| `/var/log/apt/history.log` | Comandos `apt` ejecutados y qué cambiaron |
| `/var/log/ufw.log` | Conexiones bloqueadas por UFW (si el registro está activo) |
| `/var/log/cloud-init.log` | Configuración inicial de la máquina en el primer arranque |
| `/var/log/wtmp`, `/var/log/btmp` | Inicios 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.

> Nota: en Rocky Linux y otras distribuciones de la familia Red Hat, el equivalente de `syslog` es `/var/log/messages`, el de `auth.log` es `/var/log/secure` y cron escribe en `/var/log/cron`.

## Paso 2: Dar permiso de lectura a tu usuario

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

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

```output
-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:

```bash
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:

```bash
id -nG
```

```output
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:

```bash
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:

```bash
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:

```output
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:

```bash
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:

```bash
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`:

```bash
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í:

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

```output
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:

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

```output
    412 203.0.113.77
    158 198.51.100.9
     37 192.0.2.201
```

Y qué nombres de usuario prueban:

```bash
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
```

```output
     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):

```bash
last -n 10
sudo lastb -n 10
```

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

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

```output
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:

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

```output
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`:

```bash
sudo dmesg -T | tail -n 30
```

Para saber cuándo se reinició el servidor:

```bash
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:

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

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

```bash
journalctl -p err -b
```

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

```bash
journalctl -b -1 -e
```

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

```bash
journalctl -u ssh -f
```

Mensajes del kernel, equivalentes a `kern.log`:

```bash
journalctl -k --since today
```

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

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

Comprueba cuánto ocupa el diario:

```bash
journalctl --disk-usage
```

```output
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:

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

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

```bash
sudo journalctl --vacuum-size=500M
```

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

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

```ini
[Journal]
SystemMaxUse=500M
```

Aplica el cambio:

```bash
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:

```bash
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.