Monitorear Linux: CPU, memoria, disco y registros
Monitorear un servidor Linux sirve para detectar cambios y explicar problemas. Una cifra aislada, como memoria utilizada o carga elevada, rara vez basta para decidir que debes ampliar recursos o reiniciar servicios.
Esta guía propone un recorrido de diagnóstico principalmente de lectura. Los ejemplos usan Ubuntu o Debian; algunas herramientas necesitan paquetes adicionales y permisos para mostrar información completa. No incluyen un instalador automático ni un servicio de correo supuesto.
Empieza por el síntoma del servicio
Anota qué falla, desde cuándo y para quién: peticiones lentas, errores HTTP, rechazos de conexión o interrupciones. Comprueba desde un cliente exterior y compara con una prueba local.
Identifica cambios recientes de despliegue, configuración, certificados o volumen de datos. Si solo observas el servidor, podrías pasar por alto una dependencia remota o un problema de DNS.
date -Is
uptime
nproc
systemctl --failedLa fecha ayuda a correlacionar registros. nproc muestra procesadores disponibles para el proceso, algo relevante cuando existen restricciones de recursos.
Distingue carga y porcentaje de CPU
La carga media refleja tareas ejecutables y ciertas esperas no interrumpibles; no es un porcentaje de CPU. Sus valores de 1, 5 y 15 minutos necesitan contexto de procesadores y tipo de trabajo.
top
ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head -n 12top permite observar cambios; la salida de ps es otra vista y no necesariamente utiliza el mismo intervalo de cálculo. Una tarea que ocupa un núcleo completo puede aparecer con un porcentaje distinto según la herramienta y su modo.
Si sospechas saturación, identifica el proceso y el momento. No lo termines solo por estar arriba de la lista: puede estar realizando un trabajo legítimo o esperando otra dependencia.
Interpreta memoria disponible y swap
free -h
vmstat 1 5En free, available estima memoria que podría utilizarse sin intercambiar páginas. Linux aprovecha RAM para cachés; un valor bajo en free no equivale automáticamente a falta de memoria.
En vmstat revisa actividad de swap, procesos y cambios durante las muestras. La primera salida suele resumir desde el arranque, mientras las siguientes corresponden al intervalo.
Busca presión sostenida y eventos de falta de memoria antes de atribuir lentitud a la RAM. Un proceso puede estar limitado por su contenedor o cgroup aunque el host todavía tenga memoria disponible.
Separa espacio, inodos y latencia de disco
df -h
df -i
sudo du -xhd1 /vardf muestra ocupación de sistemas de archivos; df -i ayuda a detectar agotamiento de inodos por muchos archivos pequeños. du estima el espacio de archivos accesibles en un recorrido y puede tardar o generar carga.
Si df y du difieren, considera archivos borrados que un proceso mantiene abiertos, montajes y permisos. No borres carpetas al azar para igualar ambas cifras.
Para observar actividad de dispositivos, instala sysstat si no está disponible:
sudo apt install sysstat
iostat -xz -y 1 5-y omite el primer informe acumulado. Relaciona latencias, cola y transferencias con el almacenamiento que realmente utiliza la aplicación. Un %util alto no demuestra por sí solo saturación en cualquier SSD o dispositivo paralelo.
Comprueba escucha y registros
sudo ss -ltnp
ss -s
sudo journalctl -u nginx --since '30 minutes ago' --no-pager
sudo journalctl -k --since '30 minutes ago' --no-pagerCambia nginx por la unidad real. Un puerto en escucha demuestra que existe un proceso esperando conexiones en esa dirección; no confirma que el firewall lo permita ni que la aplicación responda bien.
Los registros pueden mostrar errores de disco, falta de memoria o reinicios. Conserva el intervalo relacionado con el incidente y retira secretos o datos personales antes de compartirlo. Evita recopilar todo el journal sin una necesidad concreta.
Pasa de observación a alertas útiles
Para el seguimiento continuo utiliza un recolector mantenido, almacenamiento de métricas y un canal de notificación probado. El panel por sí solo no avisa a nadie.
Define alertas sobre impacto, como tasa de errores o latencia, y señales preventivas como tiempo estimado hasta llenar el volumen. Si eliges un umbral de CPU o RAM, decide duración y contexto; un pico breve puede ser normal.
Una alerta debe indicar sistema, hora, condición y una primera comprobación. Prueba entrega, repetición y resolución. Ejecutar mail desde cron no garantiza que exista un transporte configurado ni que el mensaje llegue.
Si instalas un panel, limita su acceso y autenticación desde el principio. Mantén una comprobación externa: cuando el servidor completo cae, su propio monitor puede dejar de enviar señales.
Preguntas frecuentes
¿RAM utilizada al 90 % significa que necesito ampliar el servidor?
No necesariamente. Revisa available, actividad de swap, límites del proceso y síntomas. La caché recuperable cambia la interpretación.
¿Una carga de 4 siempre es mala?
Depende de los recursos y del trabajo en espera. Compárala con procesadores disponibles, uso de CPU, latencia de disco y comportamiento del servicio.
¿Cuánto historial necesito guardar?
El suficiente para comparar con ciclos normales y revisar incidentes, según volumen y costos. Empieza con una retención explícita y ajusta tras observar el uso real.
En pocas palabras
Las métricas del sistema explican una parte del problema. Relaciona consumo, latencia, errores y cambios recientes, y conserva suficiente historial para distinguir una variación normal de una degradación.
Conclusión
Construye una línea base y prueba tus alertas antes de necesitarlas. La mejora consiste en detectar síntomas útiles, reunir evidencia y confirmar la recuperación desde la perspectiva del usuario.
Para continuar, revisa Docker: qué es y cómo usarlo para ejecutar contenedores y Cómo instalar Docker en Ubuntu 24.04: guía práctica paso a paso.
Fuentes y documentación
Documentación de manpages.debian.org.
Documentación de manpages.debian.org.
Documentación de manpages.debian.org.