Cuando un servidor Linux deja de responder, la tentación suele ser entrar por SSH y empezar a ejecutar comandos. top, free, df, systemctl, journalctl. Todos son útiles, pero no deberían ser siempre el primer paso. Antes de diagnosticar CPU, memoria o disco, conviene responder una pregunta más básica: ¿el servidor está realmente caído o solo ha dejado de ser accesible por una ruta concreta?

Por eso, en un incidente real, el primer comando no suele ser uno dentro del servidor. Suele ser algo tan simple como:

ping -c 4 <IP_DEL_SERVIDOR>

O, si se quiere algo un poco más útil para ver saltos intermedios:

mtr <IP_DEL_SERVIDOR>

La razón es sencilla. Si no hay conectividad, todo lo demás cambia. Puede que el sistema operativo esté funcionando, pero haya un problema de red, firewall, routing, switch, VPN, balanceador, proveedor cloud o regla de seguridad. Si se empieza directamente por SSH y no responde, se puede llegar a una conclusión equivocada: “el servidor está muerto”. A veces no lo está. Solo está aislado.

El buen diagnóstico en sistemas empieza separando síntomas. No es lo mismo que no cargue una web, que no responda el puerto 22, que no haya ICMP, que el servidor esté congelado, que el kernel siga vivo pero sin procesos útiles, o que el disco esté al 100 % y no pueda escribir logs.

Primero, saber si hay camino hasta la máquina

El primer minuto de un incidente debería servir para confirmar alcance. ¿Falla un servidor o varios? ¿Falla un servicio o toda la máquina? ¿Falla desde una ubicación o desde cualquier red? ¿Hay usuarios afectados o solo una monitorización concreta?

Un flujo razonable sería empezar con conectividad:

ping -c 4 <IP>

Después comprobar ruta:

mtr <IP>

Y si el servidor responde a red, probar el servicio afectado:

curl -I https://dominio.com
nc -vz <IP> 22
nc -vz <IP> 443

Esto permite saber si el problema está en la red, en el puerto, en el servicio o en una capa intermedia. Si ping responde pero SSH no, el servidor no está necesariamente caído. Puede haber un problema con sshd, firewall, saturación de procesos, límites de conexión o carga tan alta que la sesión no llega a abrir.

Si no responde nada, el siguiente paso no es reiniciar a ciegas. Es revisar desde consola alternativa: KVM, iLO, iDRAC, IPMI, consola del hipervisor, consola del proveedor cloud o acceso serie si existe. Reiniciar puede recuperar servicio, pero también puede borrar evidencias útiles y convertir un incidente diagnosticable en una anécdota sin causa raíz.

Síntoma inicial	Primera lectura	Siguiente paso razonable
No responde ping	Posible red, firewall, caída total o ICMP bloqueado	Revisar ruta, consola, proveedor, switch o seguridad
Responde ping, no responde SSH	Sistema vivo, pero acceso bloqueado o saturado	Probar puerto 22, consola alternativa, logs
Responde SSH lento	Carga alta, I/O wait, DNS, PAM, disco o procesos	Entrar y lanzar diagnóstico rápido
Web caída, SSH responde	Servicio o aplicación, no máquina completa	Revisar systemctl, logs, puertos y recursos
Todo responde lento	CPU, RAM, disco, red o dependencia externa	Medir antes de actuar

Si SSH responde, el primer comando útil es uptime

Una vez dentro del servidor, el primer comando que suele dar una fotografía rápida es:

uptime

No arregla nada, pero orienta. Muestra cuánto tiempo lleva encendida la máquina, cuántos usuarios hay conectados y, sobre todo, la carga media. Si el load average está disparado, ya hay una pista. Si una máquina con 4 vCPU marca cargas de 80, 120 o 300, el sistema puede estar vivo pero prácticamente inutilizable.

Después tiene sentido mirar procesos:

top -b -n 1 | head -20

O una vista más directa por CPU:

ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head

Y por memoria:

free -h
ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%mem | head

En ese momento ya se empieza a distinguir si el problema apunta a CPU, RAM, swap, procesos en bucle, fuga de memoria o demasiadas tareas bloqueadas.

Un detalle importante: si hay muchos procesos en estado D, el problema puede estar en disco o almacenamiento, no en CPU. Un servidor puede parecer congelado porque espera operaciones de I/O que no terminan. Ahí matar procesos sin entender puede empeorar el escenario.

Disco, inodos y logs: tres clásicos que siguen tumbando servidores

Muchos incidentes de Linux siguen teniendo causas poco glamur. Un disco lleno. Un directorio de logs fuera de control. Un backup mal programado. Una aplicación escribiendo millones de ficheros pequeños. Una partición /var al 100 %. Un volumen sin inodos aunque todavía quede espacio en GB.

Por eso los siguientes comandos deberían estar siempre cerca:

df -h
df -i
du -xhd 1 / 2>/dev/null | sort -hr | head

df -h muestra espacio en disco. df -i muestra inodos. Este segundo se olvida demasiado. Si los inodos están agotados, el sistema puede no crear archivos nuevos aunque el disco aparente tener espacio libre.

Los logs recientes también son esenciales:

journalctl -xe --no-pager | tail -50
journalctl -p err --since "1 hour ago"
dmesg -T | tail -100

Ahí pueden aparecer errores de kernel, fallos de disco, OOM Killer, servicios reiniciando en bucle, problemas de red o mensajes de I/O. Antes de reiniciar, conviene mirar. El reinicio puede borrar el contexto temporal que explica el fallo.

Mitigar no es lo mismo que diagnosticar

En un incidente hay dos objetivos que compiten: recuperar servicio y entender la causa. El equilibrio depende del impacto. Si hay una caída grave, se mitiga rápido, pero sin destruir toda la evidencia.

Algunas acciones comunes:

Síntoma	Causa probable	Acción de mitigación
CPU al 100 %	Proceso en bucle o carga anómala	Identificar PID y parar con cuidado
RAM agotada	Fuga de memoria o exceso de procesos	Reiniciar servicio afectado, no todo el servidor si no hace falta
Disco lleno	Logs, temporales, backups o dumps	Limpiar temporales, truncar logs controladamente
Inodos llenos	Muchos archivos pequeños	Localizar directorios y eliminar/mover con criterio
Servicio caído	Fallo de aplicación	systemctl status y reinicio controlado
Muchas conexiones	Pico, abuso o fuga	Revisar límites, aplicación, firewall y balanceador

Un comando como este puede ser necesario:

kill -9 <PID>

Pero debería ser una decisión, no un reflejo. kill -9 no permite al proceso cerrar limpiamente. A veces es inevitable; otras, basta con reiniciar un servicio o cortar una cola de trabajo.

Lo mismo ocurre con el reinicio del servidor:

systemctl reboot --force

Debe ser último recurso. Si el sistema está completamente congelado y no hay forma de recuperar, puede tocar usar consola o SysRq, pero hay que saber lo que se hace. La recuperación rápida no debe convertirse en pérdida de datos.

El incidente no termina cuando vuelve el servicio

Uno de los errores más caros en operaciones es cerrar el incidente cuando la web vuelve a responder. Ese es el final de la caída, no del trabajo. Falta documentar qué ocurrió, cuánto duró, qué impacto tuvo, qué se hizo, qué funcionó y qué hay que cambiar para que no se repita.

Un buen post-incidente debería responder:

Pregunta	Por qué importa
¿Qué falló exactamente?	Evita quedarse en síntomas
¿Cuándo empezó y cuándo terminó?	Permite medir impacto real
¿Qué usuarios o servicios se vieron afectados?	Ayuda a priorizar prevención
¿Qué señales avisaron?	Mejora monitorización
¿Qué acción recuperó el servicio?	Documenta respuesta útil
¿Qué acción preventiva falta?	Convierte el incidente en mejora

La regla de oro es sencilla: no adivinar. Observar, medir y entender antes de actuar. Un buen administrador de sistemas no es quien ejecuta más comandos, sino quien sabe en qué orden ejecutarlos y cuándo parar antes de romper algo más.

Si hay que elegir una respuesta corta a la pregunta inicial, sería esta: primero compruebo conectividad con ping o mtr; si SSH responde, ejecuto uptime. Lo primero separa red de sistema. Lo segundo da una lectura rápida de carga y estado general. A partir de ahí, el diagnóstico ya no va a ciegas.

Preguntas frecuentes

¿Cuál es el primer comando ante un servidor que no responde?
Desde fuera, ping -c 4 <IP> o mtr <IP> para comprobar conectividad. Si SSH responde, dentro del servidor el primer comando útil suele ser uptime.

¿Por qué no empezar directamente con top?
Porque quizá ni siquiera haya acceso real al servidor. Antes conviene saber si el problema es de red, acceso, puerto, servicio o sistema completo.

¿Qué comando ayuda a detectar disco lleno?
df -h para espacio y df -i para inodos. Ambos son importantes, porque un sistema puede quedarse sin inodos aunque todavía tenga espacio disponible.

¿Qué logs conviene mirar en los primeros minutos?
journalctl -xe --no-pager, journalctl -p err --since "1 hour ago" y dmesg -T | tail -100 suelen dar señales rápidas de errores recientes.

¿Cuándo reiniciar un servidor?
Cuando ya se ha descartado una mitigación menos agresiva o cuando el sistema está completamente irrecuperable. Reiniciar sin diagnóstico puede borrar evidencias y ocultar la causa raíz.