Sysadmin

Diagnóstico Linux: Resolución de Problemas en Producción

En una infraestructura IT moderna, la disponibilidad de los servicios es un requisito inquebrantable. El cumplimiento de normativas como NIS2 art.21 exige tiempos de respuesta mínimos ante incidentes. La continuidad operativa depende directamente de tu capacidad para identificar y resolver cuellos de botella antes de que afecten al negocio. Cuando migré 300 VMs a Proxmox para una organización sanitaria pública, un fallo en un nodo de cómputo amenazaba con dejar fuera de servicio a 2.000 usuarios. El problema no era la CPU, sino una espera de I/O disparada por un snapshot huérfano. Este artículo ofrece un enfoque metódico para el diagnóstico Linux. Veremos cinco comandos fundamentales con ejemplos prácticos y casos reales, para que puedas pasar de la alarma a la solución en minutos, no en horas.

Diagnóstico Linux: Requisitos Previos y Entorno de Prueba

Para seguir este tutorial, necesitas acceso root o privilegios sudo sobre un servidor Linux. Los ejemplos se han probado sobre Ubuntu 24.04 LTS y RHEL 9, pero son compatibles con cualquier distribución moderna. Asegúrate de tener instalado el paquete sysstat, que incluye iostat. En distribuciones basadas en Debian lo instalas así:

sudo apt update && sudo apt install sysstat -y
sudo sed -i 's/ENABLED="false"/ENABLED="true"/g' /etc/default/sysstat
sudo systemctl enable --now sysstat

Monitorización de recursos con top

El comando top permite observar en tiempo real el uso de CPU y memoria, mostrando los procesos más costosos.

top

Al ejecutarlo, obtendrás una salida similar a esta:

%Cpu(s): 75.3 us,  5.0 sy, 18.9 id,  0.5 wa
KiB Mem : 16323056 total, 1524300 free, 12567200 used

Un valor elevado de wa (I/O wait) indica que los procesos no están limitados por la CPU, sino por la lentitud del disco o la red. La CPU simplemente espera a que el disco termine de leer o escribir datos.

Una aplicación web respondía en 5 segundos pese a un uso de CPU del 15%. El análisis con top mostró una espera de I/O superior al 40%. La solución fue mover el volumen de la base de datos a un SSD NVMe y habilitar caching en Redis. El tiempo de respuesta cayó a 200 ms.

Control del espacio en disco con df

El comando df muestra el espacio disponible en las particiones. El flag -h presenta los valores en formatos legibles (KB, MB, GB).

df -h

Salida esperada:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        80G   72G  4.5G  95% /

Un uso superior al 90% en la partición root puede causar bloqueos críticos en los procesos, impidiendo incluso la escritura de logs del sistema.

Un servidor rechazaba conexiones SSH nuevas. df reveló la saturación de la partición root al 100%. La eliminación de logs rotados sin comprimir y la configuración estricta de la rotación automática en /etc/logrotate.d/ resolvieron el bloqueo en 3 minutos.

Análisis del rendimiento de disco con iostat

El comando iostat proporciona métricas detalladas sobre el rendimiento de los discos, esenciales para diagnosticar cuellos de botella de almacenamiento.

iostat -x 1 3

Salida:

Device:  r/s  w/s rkB/s wkB/s svctm %util
sda      2.0 45.0  120   3600  5.3  98.0

Un valor de %util cercano al 100% indica un disco saturado. El dispositivo no puede procesar más peticiones de lectura o escritura.

Un Oracle DBA reportaba consultas lentas en un servidor RHEL 9. iostat mostró un uso de disco del 98% en el dispositivo sdb. La migración a un volumen OCI Block Volume de alto rendimiento y la separación física de datafiles y redologs eliminaron el cuello de botella, reduciendo el tiempo de las consultas a la mitad.

Verificación de servicios activos con netstat y ss

El comando netstat enumera los servicios escuchando en puertos de red. En distribuciones modernas, ss ofrece un rendimiento muy superior y reemplaza a netstat.

ss -tulpn | grep LISTEN

Salida:

tcp6   0   0 :::22      :::*    LISTEN   1234/sshd
tcp6   0   0 :::5432    :::*    LISTEN   2345/postgres

Si un servicio escucha solo en 127.0.0.1, no será accesible desde el exterior. Para aceptar conexiones remotas, el servicio debe vincularse a 0.0.0.0 o a la IP de la interfaz de red correspondiente.

Un cliente remoto no lograba conectar a PostgreSQL. ss mostraba el servicio atado a 127.0.0.1. Modificar el parámetro listen_addresses en postgresql.conf y abrir la VLAN correspondiente en el FortiGate restablecieron el acceso inmediatamente.

Consulta de logs del kernel con dmesg

El comando dmesg muestra los mensajes del kernel. Resulta vital para encontrar errores de hardware o interrupciones forzadas por el sistema.

dmesg -T | tail -20

Salida:

[Mon Oct 1 19:33:45 2025] Out of memory: Kill process 3456 (java)

Este mensaje indica que el OOM killer del kernel terminó un proceso por falta de memoria RAM disponible. El sistema operativo sacrificó la aplicación para evitar un colapso total.

Un microservicio Java caía sin dejar rastro en el log de la aplicación. La revisión con dmesg reveló la intervención del OOM killer. Ajustar el heap JVM (-Xmx) a 2GB en un host con 4GB de RAM libre y configurar vm.swappiness a un valor bajo estabilizaron el servicio de forma permanente.

Errores Comunes y Resolución de Problemas

Muchos administradores reinician el servicio afectado sin investigar la causa raíz. Esto destruye las evidencias volátiles en memoria y el estado de I/O. Otro error frecuente es ignorar los valores de wa en top, asumiendo siempre que la lentitud proviene de la CPU. Si dmesg registra eventos del OOM killer, añadir más RAM sin ajustar el consumo de la aplicación solo retrasará el próximo fallo. Verifica siempre el uso de inodos con df -i. Una partición puede mostrar un 20% de espacio libre pero un 100% de inodos agotados si se generan millones de archivos diminutos, bloqueando la creación de nuevos ficheros.

Conclusiones con Puntos Clave Operativos

Comandos como top, df, iostat, ss y dmesg representan el primer nivel de diagnóstico para un administrador de sistemas. Permiten recopilar evidencias objetivas y reducen los tiempos de intervención, mejorando la resiliencia global de las infraestructuras Linux en producción.

Puntos clave operativos:

  • Revisa la espera de I/O (wa) antes de asumir un cuello de botella de CPU.
  • Configura alertas proactivas para el uso de disco superior al 85%.
  • Sustituye netstat por ss en distribuciones modernas para un escaneo de puertos más rápido.
  • Revisa dmesg inmediatamente cuando un servicio se detiene sin explicación.
  • Consulta la documentación oficial de sysstat para profundizar en métricas avanzadas de rendimiento.

Lee también: Hardening SSH en Linux: Guía Completa 2026

Comparte este artículo:

Escrito por

Rosario Giordano

Rosario Giordano es administrador de sistemas y consultor de TI especializado en c iberseguridad y cloud, con más de 20 años de experiencia en la gestión de infraestructuras Linux empresariales. Sus áreas de especialización incluyen el hardening de SSH, plataformas Kubernetes , bases de datos PostgreSQL, virtualización con VMware/Proxmox y el cumplimiento de los marcos de seguridad NIS2 e ISO 27001.