Publicada enLINUX

Monitoreo básico del sistema en Linux: comandos clave

No hay comentarios
monitoreo-basico-del-sistema-en-linux
monitoreo-basico-del-sistema-en-linux

El monitoreo básico del sistema en Linux consiste en revisar el estado real de una máquina para saber si trabaja con normalidad, si se está quedando sin recursos o si ya muestra señales de fallo.

Sin embargo, no hace falta empezar instalando una plataforma completa de observabilidad. Antes de usar Prometheus, Grafana, Zabbix u otras soluciones avanzadas, conviene dominar primero los comandos que ya permiten responder preguntas muy concretas.

De esta forma, puedes comprobar la carga del sistema, el consumo de CPU, la memoria disponible, el uso de swap, el espacio en disco, el estado de los servicios, los errores recientes y la conectividad de red.

Además, esta guía está pensada como una base práctica. Por tanto, el objetivo no es memorizar todos los comandos posibles, sino aprender un orden razonable de revisión y entender qué significa cada señal.

  • ¿Cuánto tiempo lleva encendido el sistema?
  • ¿La carga media es normal para la cantidad de CPU disponible?
  • ¿Qué procesos están consumiendo más recursos?
  • ¿Queda memoria RAM suficiente?
  • ¿Se está usando swap de forma preocupante?
  • ¿Hay espacio libre en disco?
  • ¿Los servicios importantes están activos?
  • ¿Los logs muestran errores recientes?
  • ¿El kernel está registrando problemas de hardware, memoria o disco?
  • ¿La red responde correctamente?

Esta guía está pensada como una base práctica. El objetivo no es memorizar todos los comandos posibles, sino aprender un orden razonable de revisión y entender qué significa cada señal.

Si después quieres profundizar en herramientas y métricas más específicas, también puedes consultar la guía de monitoreo de recursos en Linux.

Importancia del monitoreo básico del sistema en Linux

Un sistema Linux puede fallar de muchas formas. Por ejemplo, el disco puede llenarse, un proceso puede consumir toda la CPU, la memoria puede agotarse, un servicio puede dejar de responder, una interfaz de red puede caerse o el kernel puede registrar errores de entrada/salida.

Por eso, el monitoreo básico del sistema en Linux ayuda a separar síntomas de causas.

Por ejemplo, si una web responde lento, el origen puede estar en la aplicación, en la base de datos, en el disco, en la memoria, en la red o en una carga puntual de trabajo. Sin embargo, si no revisas el sistema, es fácil culpar al componente equivocado.

Una rutina sensata suele ir de lo general a lo específico:

  1. Ver estado general, uptime y carga.
  2. Revisar CPU y procesos.
  3. Comprobar memoria RAM y swap.
  4. Medir espacio en disco y directorios grandes.
  5. Revisar servicios activos o fallidos.
  6. Leer logs recientes.
  7. Consultar mensajes del kernel.
  8. Comprobar red, puertos y conexiones.
  9. Repetir medidas durante unos minutos si el problema cambia con el tiempo.

Ese orden evita perder tiempo en detalles pequeños cuando el problema está en algo evidente.

Vista rápida con uptime y carga media

El comando uptime muestra desde cuándo está encendido el sistema, cuántos usuarios hay conectados y cuál es la carga media.

uptime

Una salida típica puede ser:

20:15:03 up 12 days,  4:21,  2 users,  load average: 0.34, 0.41, 0.39

Los datos principales son:

  • up 12 days: el sistema lleva 12 días encendido.
  • 2 users: hay dos sesiones de usuario abiertas.
  • load average: carga media durante 1, 5 y 15 minutos.

La carga media no es un porcentaje de CPU. Representa cuántas tareas están ejecutándose o esperando recursos. Para interpretarla bien, hay que compararla con el número de procesadores lógicos.

Puedes verlo con:

nproc

En una máquina con 1 núcleo, una carga sostenida de 1.00 indica que el sistema está cerca de su límite. En una máquina con 4 núcleos, una carga de 1.00 suele ser cómoda. En esa misma máquina de 4 núcleos, una carga sostenida de 6.00 u 8.00 ya merece investigación.

Una lectura rápida:

  • Carga por debajo del número de núcleos: normalmente aceptable.
  • Carga similar al número de núcleos: sistema ocupado, conviene observar.
  • Carga muy superior al número de núcleos: posible saturación de CPU, disco o procesos bloqueados.

Error común: pensar que una carga de 2.00 siempre es mala. En un equipo con 8 o 16 núcleos puede ser completamente normal.

CPU y procesos en tiempo real con top y htop

Después de revisar la carga general, el siguiente paso es ver qué procesos consumen CPU y memoria en tiempo real. Para eso, el comando clásico es top.

top

La parte superior muestra un resumen del sistema: carga, tareas, uso de CPU, memoria y swap. Debajo aparece una lista de procesos, normalmente ordenada por consumo de CPU.

Columnas útiles en top:

  • PID: identificador del proceso.
  • USER: usuario que ejecuta el proceso.
  • %CPU: porcentaje de CPU usado.
  • %MEM: porcentaje de memoria usado.
  • TIME+: tiempo acumulado de CPU.
  • COMMAND: comando o programa asociado.

Teclas prácticas dentro de top:

  • P: ordenar por CPU.
  • M: ordenar por memoria.
  • k: enviar una señal a un proceso.
  • q: salir.

Si está instalado, htop ofrece una vista más cómoda e interactiva:

htop

A diferencia de top, htop permite desplazarse, buscar procesos, ordenar columnas y finalizar procesos con más claridad visual. No siempre viene instalado por defecto, pero es muy útil en servidores administrados manualmente.

Antes de matar un proceso, conviene entender qué es, quién lo lanzó y si forma parte de un servicio importante. De hecho, un proceso que aparece arriba en top puede estar haciendo trabajo legítimo: comprimir backups, indexar datos, compilar software o procesar una tarea pesada.

Por eso, un error común es matar el primer proceso con alto consumo sin comprobar su función. Eso puede interrumpir servicios críticos o dejar datos a medio escribir.

Procesos con ps y pgrep

Mientras top sirve para mirar en vivo, ps permite obtener una instantánea de los procesos.

Para ver todos los procesos:

ps aux

Para localizar uno concreto:

ps aux | grep nginx

Una alternativa más limpia es pgrep:

pgrep -a nginx

También puedes ordenar procesos por memoria:

ps aux --sort=-%mem | head

O por CPU:

ps aux --sort=-%cpu | head

De esta manera, puedes identificar rápidamente los procesos más pesados sin entrar en una interfaz interactiva.

En este punto, conviene recordar un error común: confundir proceso con servicio. Un servicio puede lanzar varios procesos, y un proceso puede depender de otro. Por eso, si el sistema usa systemd, muchas veces es mejor gestionar el servicio con systemctl que matar procesos manualmente.

Memoria RAM y swap con free

Después de revisar CPU y procesos, conviene comprobar la memoria. Para hacerlo, el comando más directo es:

free -h

La opción -h muestra valores legibles, como MiB o GiB.

               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       2.1Gi       1.0Gi       210Mi       4.6Gi       5.1Gi
Swap:          2.0Gi          0B       2.0Gi

En esta salida, la columna más importante para empezar suele ser available, no free.

Linux utiliza memoria libre como caché de disco para mejorar el rendimiento. Por eso puede parecer que queda poca memoria free, aunque el sistema esté sano. La memoria marcada como buff/cache puede liberarse cuando una aplicación la necesita.

Conviene preocuparse si:

  • available es muy bajo de forma constante.
  • La swap crece y se usa intensamente.
  • El sistema responde lento al mismo tiempo que hay poca memoria disponible.
  • Hay procesos grandes consumiendo RAM sin motivo claro.
  • Aparecen eventos OOM en logs o mensajes del kernel.

Aparecen eventos OOM en logs o mensajes del kernel.

En otras palabras, una RAM muy usada no siempre indica un problema. En Linux, memoria usada puede ser caché saludable; por tanto, lo importante es mirar disponibilidad, swap y síntomas.

Espacio en disco con df

Además de CPU y memoria, también hay que revisar el disco. Un servidor sin espacio puede fallar de muchas formas: bases de datos que no escriben, logs que se pierden, servicios que no arrancan, sesiones que no se guardan o actualizaciones incompletas.

Para ver el espacio disponible en los sistemas de archivos:

df -h

Columnas importantes:

  • Filesystem: dispositivo o sistema de archivos.
  • Size: tamaño total.
  • Used: espacio usado.
  • Avail: espacio disponible.
  • Use%: porcentaje de uso.
  • Mounted on: punto de montaje.

Presta especial atención a:

  • /: raíz del sistema.
  • /var: logs, cachés, paquetes, colas y datos de muchos servicios.
  • /home: datos de usuarios.
  • Puntos de montaje de bases de datos, backups o aplicaciones.

Como regla práctica, un disco por encima del 85% merece revisión. Por encima del 95%, el riesgo operativo aumenta bastante.

Error común: mirar solo / y olvidar particiones separadas. Un sistema puede tener la raíz con espacio libre y, al mismo tiempo, /var o una partición de datos completamente llena.

Directorios grandes con du

Cuando df -h muestra una partición llena, el siguiente paso es localizar qué directorios ocupan más.

Por ejemplo:

du -h --max-depth=1 /var

Para ordenar por tamaño:

du -h --max-depth=1 /var | sort -h

En sistemas Linux comunes, –max-depth suele estar disponible porque se usa GNU du. En otros entornos puede no existir o comportarse de forma distinta.

Directorios que suelen crecer:

  • /var/log
  • cachés de paquetes
  • directorios de backups
  • datos de bases de datos
  • uploads de aplicaciones
  • colas de correo o trabajos pendientes

Antes de borrar, verifica qué es cada archivo y si algún proceso lo mantiene abierto. Borrar un log enorme no siempre libera espacio al instante si el servicio todavía tiene el archivo abierto.

Error común: borrar archivos grandes sin comprobar el proceso asociado. A veces hay que reiniciar o recargar el servicio para liberar realmente el espacio.

Servicios con systemctl

En muchas distribuciones actuales, systemd gestiona los servicios. Para comprobar el estado de un servicio

Para obtener solo si está activo:

systemctl is-active nginx

Para listar servicios en ejecución:

sudo systemctl list-units --type=service --state=running

Para ver servicios fallidos:

systemctl list-units --type=service --state=failed

Si un servicio aparece como failed, revisa su estado y sus logs antes de reiniciarlo:

systemctl status nombre-del-servicio
journalctl -u nombre-del-servicio --since "1 hour ago"

Reiniciar puede ser necesario para recuperar disponibilidad, pero no sustituye al diagnóstico. Si la causa sigue ahí, el servicio puede volver a caer.

Error común: ejecutar systemctl restart sin leer el motivo del fallo. Es rápido, pero puede ocultar la pista principal.

Logs del sistema con journalctl

Los logs son una de las mejores fuentes para entender qué ocurrió antes de un fallo.

En sistemas con systemd, journalctl permite consultar el journal.

Ver las últimas líneas:

journalctl -n 100

Seguir logs en tiempo real:

sudo journalctl -f

Ver logs del arranque actual:

journalctl -b

Ver errores recientes:

sudo journalctl -p err --since "today"

Los logs suelen revelar permisos incorrectos, puertos ocupados, archivos ausentes, errores de configuración, fallos de conexión, problemas de disco o reinicios inesperados.

Una forma práctica de usarlos durante una incidencia es combinar tiempo y servicio:

journalctl -u nginx --since "30 minutes ago"

Error común: leer solo la última línea del error. Muchas veces la causa aparece unas líneas antes, y la última línea solo muestra la consecuencia.

Mensajes del kernel con dmesg

dmesg muestra mensajes del kernel. Es especialmente útil para problemas de hardware, discos, drivers, memoria, interfaces de red o eventos de bajo nivel.

dmesg

Para verlo con marcas de tiempo más legibles:

sudo dmesg -T

Para buscar errores o advertencias:

dmesg -T | grep -i -E "error|fail|warn"

Algunos sistemas requieren permisos de administrador para leer dmesg.

Señales que conviene investigar:

  • Errores de disco o I/O.
  • Mensajes OOM.
  • Fallos de drivers.
  • Interfaces de red que se desconectan.
  • Problemas de memoria.
  • Mensajes relacionados con kernel panic o reinicios.

Error común: ignorar dmesg porque el problema parece de aplicación. A veces una aplicación falla porque debajo hay errores de disco, memoria, red o hardware.

Carga, CPU e I/O con vmstat

vmstat ofrece una vista compacta de procesos, memoria, CPU y actividad de entrada/salida.

vmstat 1

El 1 indica que actualiza cada segundo.

Columnas útiles:

  • r: procesos esperando CPU.
  • b: procesos bloqueados, normalmente por entrada/salida.
  • swpd: memoria swap usada.
  • si y so: entrada y salida de swap.
  • us: CPU usada por procesos de usuario.
  • sy: CPU usada por el sistema.
  • id: CPU inactiva.
  • wa: espera por I/O.

Si wa está alto de forma sostenida, puede haber cuello de botella de disco. Si r es muy superior al número de núcleos durante bastante tiempo, puede haber saturación de CPU.

vmstat es más útil observando varias muestras, no una sola línea. Déjalo correr unos segundos y fíjate en la tendencia.

Error común: sacar conclusiones por una única muestra. Un pico puntual no significa necesariamente un problema persistente.

Rendimiento de disco con iostat

iostat ayuda a revisar actividad de CPU y dispositivos de bloque. Suele venir en el paquete sysstat, por lo que puede no estar instalado por defecto.

iostat -xz 1

Opciones usadas:

  • -x: estadísticas extendidas.
  • -z: oculta dispositivos sin actividad.
  • 1: actualiza cada segundo.

Valores importantes:

  • %util: utilización del dispositivo.
  • await: tiempo medio de espera de operaciones.
  • r/s y w/s: lecturas y escrituras por segundo.

Un disco con %util muy alto y await elevado puede estar saturado. Eso puede explicar lentitud aunque la CPU y la memoria parezcan normales.

Error común: asumir que si hay espacio libre, el disco está bien. El espacio disponible y el rendimiento de I/O son problemas distintos.

Red básica con ss, ping y DNS

Para ver conexiones y puertos en escucha, ss es una herramienta moderna y rápida.

ss -tulpen

Opciones habituales:

  • -t: TCP.
  • -u: UDP.
  • -l: sockets en escucha.
  • -p: proceso asociado.
  • -e: información extendida.
  • -n: no resolver nombres, mostrar números.

Para comprobar conectividad básica:

ping 8.8.8.8

Para ver conexiones TCP establecidas:

ss -tn state established

Para comprobar resolución DNS:

ping example.com

Si funciona el ping a una IP pero falla el ping a un dominio, el problema puede estar en DNS. Si no responde ninguna IP externa, puede haber un problema de ruta, firewall, interfaz o proveedor.

En servidores, ping puede estar bloqueado por firewalls. Una falta de respuesta ICMP no siempre significa que el host esté caído.

Error común: diagnosticar red solo con ping. Una aplicación puede depender de TCP, DNS, TLS, reglas de firewall, rutas o balanceadores.

Repetir comprobaciones con watch

Uno de los pilares del monitoreo básico del sistema en Linux es cuando el problema cambia con el tiempo, utilizar el comando watch. Este comando ejecuta una orden cada cierto intervalo y muestra la salida actualizada.

Para ver espacio en disco cada 5 segundos:

sudo watch -n 5 df -h

Para seguir memoria:

watch -n 2 free -h

Además, para observar el número de conexiones establecidas:

sudo watch -n 2 'ss -tn state established | wc -l'

Tabién puedes vigilar servicios fallidos:

watch -n 5 'systemctl list-units --type=service --state=failed'

De esta forma, watch ayuda a distinguir entre un pico temporal y una tendencia. Si un valor sube sin parar, como uso de disco, memoria o conexiones, probablemente hay que investigar más.

Aun así, un error común es dejar watch abierto y olvidar que solo muestra una vista temporal. Para análisis histórico hacen falta logs, métricas persistentes o herramientas de monitorización.

Revisar uptime y reinicios inesperados

Además de uptime, puedes consultar el momento del último arranque con:

who -b

Si el sistema usa journal persistente, también puedes listar arranques:

sudo journalctl --list-boots

Para revisar logs del arranque anterior:

journalctl -b -1

Esto ayuda a detectar reinicios inesperados. Si un servidor se reinició y nadie lo hizo manualmente, conviene investigar posibles causas: kernel panic, falta de memoria, cortes eléctricos, actualizaciones automáticas, errores de hardware o acciones programadas.

Aun así, un error común es dejar watch abierto y olvidar que solo muestra una vista temporal. Para análisis histórico hacen falta logs, métricas persistentes o herramientas de monitorización.

Chequeo rápido de salud del sistema

Cuando necesitas una revisión rápida, puedes ejecutar esta secuencia:

uptime
nproc
free -h
df -h
top
systemctl list-units --type=service --state=failed
journalctl -p err --since "1 hour ago"
ss -tulpen

Con esos comandos obtienes una primera imagen del sistema:

  • Carga general y tiempo encendido.
  • Número de procesadores lógicos para interpretar la carga.
  • Memoria disponible y uso de swap.
  • Espacio en disco.
  • Procesos activos.
  • Servicios fallidos.
  • Errores recientes.
  • Puertos y conexiones.

No sustituye a una investigación completa, pero sirve para decidir dónde mirar primero.

Cómo interpretar problemas frecuentes

Si el sistema está lento y la carga media es alta, empieza por top, vmstat e iostat. Así puedes distinguir si el cuello de botella parece estar en CPU, procesos bloqueados o disco.

Si la memoria disponible es baja, identifica procesos grandes con top, htop o:

ps aux --sort=-%mem | head

Después revisa si la swap crece y si aparecen eventos OOM:

dmesg -T | grep -i oom

Por otro lado, si el disco está lleno, usa df -h para localizar la partición afectada y du para encontrar los directorios más grandes. En servidores, conviene revisar especialmente logs, cachés, backups y datos de aplicaciones.

Cuando un servicio está caído, combina el estado del servicio con sus logs recientes:

systemctl status nombre-del-servicio
journalctl -u nombre-del-servicio --since "1 hour ago"

Además, si hay problemas de red, usa ss para revisar puertos y conexiones. A continuación, separa la conectividad IP de la resolución DNS haciendo pruebas contra una IP y contra un dominio.

Buenas prácticas para empezar

Para aprender monitoreo básico del sistema en Linux, practica en una máquina de prueba. Observa cómo cambian los valores al abrir programas, copiar archivos, descargar paquetes, ejecutar tareas pesadas o detener servicios no críticos.

También es útil ejecutar tus comandos de diagnóstico cuando el sistema está sano. Así conoces su comportamiento normal y puedes reconocer anomalías con más criterio.

Una rutina sencilla puede ser:

  • Revisar uptime para carga y tiempo encendido.
  • Comprobar nproc para interpretar la carga.
  • Usar free -h para memoria.
  • Usar df -h para espacio.
  • Entrar en top o htop para procesos.
  • Revisar servicios fallidos con systemctl.
  • Mirar errores recientes con journalctl.
  • Consultar dmesg si sospechas de kernel, disco, memoria o hardware.
  • Comprobar red con ss y ping.
  • Usar watch si necesitas ver cambios en tiempo real.

El monitoreo básico del sistema en Linux no consiste en ejecutar muchos comandos al azar. Consiste en mirar lo correcto, en el orden adecuado, y relacionar los datos entre sí.

Conclusión

El monitoreo básico del sistema en Linux es una habilidad esencial para administrar servidores, estaciones de trabajo y entornos de desarrollo. Con comandos como uptime, top, free, df, du, ps, systemctl, journalctl, dmesg, vmstat, iostat, ss, ping y watch, puedes obtener una imagen bastante clara del estado de una máquina.

La clave para un buen monitoreo básico del sistema en Linux no está solo en ejecutar comandos, sino en interpretar sus resultados. CPU, RAM, disco, procesos, servicios, logs, kernel y red forman parte de la misma historia. Por eso, cuando se revisan juntos, permiten diagnosticar problemas con más calma y tomar mejores decisiones.

Comentarios

No hay comentarios aún. ¿Por qué no comienzas el debate?

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *