Monitorización¶

Para qué se monitoriza¶

Monitorizar es mirar cómo está funcionando un sistema para responder a cuatro preguntas:

Pregunta	Ejemplo
¿Por qué va lento?	Un proceso se ha quedado acaparando la CPU
¿Cuánto me queda?	El disco está al 92 %, hay que actuar antes de que se llene
¿Está funcionando?	El servidor web ha dejado de responder
¿Está pasando algo raro?	400 intentos fallidos de acceso por SSH esta noche

La diferencia entre un usuario y un administrador está en cuándo se mira: el usuario mira cuando ya ha fallado; el administrador vigila para que no falle.

Qué se mide y cómo se interpreta¶

CPU. Porcentaje de uso, y sobre todo el reparto: us (programas del usuario), sy (sistema) y wa (esperando al disco). Si wa está alto, el problema no es la CPU, es el disco.

Carga media (load average). Los tres números que muestra uptime son la carga de 1, 5 y 15 minutos. Se interpretan comparándolos con el número de núcleos: una carga de 4,0 en un equipo de 4 núcleos significa saturación; en uno de 16, holgura. Los tres juntos indican si el problema es puntual o va a más.

Memoria. En Linux, ver poca memoria «libre» no es un problema: el sistema aprovecha la RAM sobrante como caché y la suelta cuando hace falta. La columna que importa es available. La señal de alarma real es que el sistema esté usando swap de forma continuada.

Disco. Dos cosas distintas: el espacio (df -h) y los inodos (df -i). Un disco puede dar «espacio insuficiente» teniendo gigas libres si se han agotado los inodos por acumular miles de ficheros diminutos.

Red. Qué puertos están abiertos y quién está conectado (ss -tulpn).

Herramientas¶

Para ver…	Comando
Todo a la vez	`htop` (o `top`)
Carga y tiempo encendido	`uptime`
Memoria	`free -h`
Espacio en disco	`df -h`, `df -i`
Qué ocupa una carpeta	`du -sh *`, `ncdu`
Puertos abiertos	`ss -tulpn`
Temperaturas	`sensors`
Hardware y estado general	`inxi -Fxz`

En el escritorio de LliureX está además el Monitor del sistema de Plasma, con la misma información en gráficas.

Los registros del sistema¶

Cuando algo falla, la respuesta casi siempre está escrita en un registro. En LliureX se consultan con journalctl:

journalctl -xe                 # últimas entradas, con contexto
journalctl -u ssh -n 30        # solo de un servicio
journalctl -p err -b           # solo errores del arranque actual
journalctl -b -1               # arranque anterior: útil tras un cuelgue
journalctl -f                  # en vivo
dmesg -T                       # mensajes del núcleo: discos, USB, hardware

Los registros clásicos siguen en /var/log (auth.log para los accesos, syslog para el sistema). Y se analizan con lo que ya sabéis de la UD6.3: grep, sort, uniq -c.

Cómo se diagnostica una avería¶

Delimitar: qué falla exactamente, desde cuándo, y qué cambió justo antes.
Medir, no suponer: cada sospecha se confirma con una herramienta.
Un cambio cada vez, comprobando el efecto antes del siguiente.
Documentar lo que se ha probado, funcione o no.

Síntoma	Por dónde empezar
Va lento	`htop`: ¿CPU, memoria o `wa` alto?
No queda espacio	`df -h` y `df -i`, luego `ncdu`
Un servicio no responde	`systemctl status` → `journalctl -u`
No hay red	`ip a` → `ip route` → `ping`
Se reinicia solo	`journalctl -b -1 -p err`, `sensors`