Cuando un servidor Linux empieza a fallar, lo más peligroso no suele ser la falta de comandos. Lo peligroso es empezar a ejecutar comandos sin orden. Reiniciar servicios, borrar logs, tocar configuración o cambiar permisos sin entender el alcance puede empeorar una incidencia y, además, eliminar pistas importantes.
Una revisión inicial debe responder preguntas muy concretas: qué está afectado, desde cuándo, qué síntomas existen, qué cambió recientemente, qué recursos están comprometidos y qué servicio concreto está fallando. Esta guía recoge una forma práctica de empezar sin perder tiempo.
Antes de mirar CPU, memoria o logs, conviene entender el alcance. No es lo mismo un usuario afectado que un servicio completo caído, ni una aplicación lenta que un servidor inaccesible.
¿Afecta a todos los usuarios? ¿Afecta solo desde fuera? ¿Afecta solo a una aplicación? ¿El servidor responde por SSH? ¿El servicio escucha en el puerto esperado? ¿El problema es intermitente o permanente?
hostname date uptime who last -n 10
uptime da una primera pista: tiempo encendido, usuarios conectados y carga media. Si el servidor se ha reiniciado hace poco y nadie lo esperaba, eso ya es un dato importante.
top ps aux --sort=-%cpu | head vmstat 1 5
CPU alta no siempre significa incidencia. Hay que mirar si hay carga sostenida, procesos bloqueados, iowait o saturación real del servicio. Un servidor puede estar al 80% de CPU y funcionar perfectamente si ese es su patrón normal.
free -m ps aux --sort=-%mem | head dmesg -T | grep -i "out of memory\|oom" journalctl -k | grep -i "out of memory\|oom"
Si aparece OOM Killer, el sistema ha matado procesos por falta de memoria. Reiniciar puede recuperar temporalmente, pero no resuelve la causa: fuga de memoria, límite insuficiente, carga anómala o proceso descontrolado.
df -h
df -i
du -sh /* 2>/dev/null
journalctl --disk-usage
find /var/log -type f -size +500M -exec ls -lh {} \;
lsof | grep deleted
El disco lleno es una de las causas más comunes de fallos raros: servicios activos que no procesan, bases de datos bloqueadas, logs que dejan de escribirse, colas paradas o aplicaciones devolviendo errores inesperados.
ip a ip r ss -lntp resolvectl status cat /etc/resolv.conf ping -c 4 8.8.8.8 dig dominio.com nc -vz host puerto curl -v http://localhost:puerto/health
Si el servicio funciona en localhost pero no desde fuera, probablemente el problema no está en la aplicación: puede estar en firewall, DNS, rutas, proxy, balanceador o certificado.
systemctl --failed systemctl status nombre-servicio journalctl -u nombre-servicio -n 200 --no-pager ss -lntp | grep puerto
Un servicio puede aparecer como activo y aun así no estar funcionando bien. Hay que validar puerto, logs y respuesta funcional.
journalctl -p err -n 100 --no-pager journalctl --since "30 minutes ago" journalctl -u nombre-servicio --since "30 minutes ago" grep -i "error\|fail\|timeout\|denied\|refused" /var/log/syslog 2>/dev/null grep -i "error\|fail\|timeout\|denied\|refused" /var/log/messages 2>/dev/null
No hay que mirar logs al azar. Hay que mirar por ventana temporal y buscar el primer error relevante, no solo el último.
last last reboot systemctl list-timers grep -i "install\|upgrade\|remove" /var/log/dpkg.log 2>/dev/null grep -i "install\|upgrade\|remove" /var/log/yum.log 2>/dev/null grep -i "install\|upgrade\|remove" /var/log/zypp/history 2>/dev/null
Muchas incidencias aparecen después de un cambio: despliegue, actualización, firewall, certificado, DNS, credenciales, cron, permisos o storage.
Alcance identificado Servidor accesible Uptime revisado Carga revisada Memoria revisada Disco e inodos revisados Servicios fallidos comprobados Puertos revisados DNS y red comprobados Logs revisados por ventana temporal Cambios recientes revisados Dependencias validadas Acción de recuperación documentada
Revisar un servidor Linux cuando algo falla no consiste en lanzar comandos de memoria. Consiste en seguir un orden que te permita descartar capas: sistema, recursos, red, servicios, logs y cambios. Cuanto más ordenado sea el diagnóstico, menos tiempo se pierde y menos riesgo hay de empeorar la incidencia.