Para revisar el estado de un servidor Linux por SSH conviene comenzar con comandos de diagnóstico que no modifiquen la configuración. El objetivo es reunir evidencias sobre carga, memoria, disco, procesos y servicios antes de reiniciar o cambiar parámetros.
Los ejemplos siguientes están orientados a un VPS o servidor con permisos administrativos. En una cuenta de hosting compartido, algunos comandos pueden estar limitados y solamente mostrarán los procesos o archivos del propio usuario.
Antes de iniciar el diagnóstico
Registrá la hora exacta del incidente, el síntoma observado y las URLs o servicios afectados. Una carga alta durante unos segundos no tiene el mismo significado que un problema sostenido. También conviene conservar la salida de los comandos para compararla después.
Si todavía no configuraste la conexión, consultá cómo acceder por SSH y verificá que estés utilizando el usuario y puerto correctos.
Tiempo encendido y promedio de carga
uptimeEl comando muestra la hora, el tiempo desde el último arranque, la cantidad de sesiones y tres promedios de carga correspondientes aproximadamente a 1, 5 y 15 minutos. Esos números representan tareas ejecutándose o esperando recursos; no son un porcentaje directo de CPU.
Para interpretarlos hay que considerar la cantidad de núcleos y si la carga se mantiene. Un valor elevado durante un trabajo programado puede ser normal; un aumento sostenido junto a lentitud requiere revisar procesos, disco y servicios.
Memoria RAM y swap
free -hRevisá las columnas total, used, free, buff/cache y available. En Linux, una cantidad baja en free no significa por sí sola falta de memoria: el sistema aprovecha RAM como caché y puede liberarla cuando una aplicación la necesita. La columna available ofrece una referencia más útil.
El uso ocasional de swap puede ser normal. Si aumenta continuamente y el servidor responde con lentitud, identificá qué procesos consumen memoria antes de modificar límites o reiniciar.
Espacio en disco
df -hComprobá especialmente las particiones cercanas al 100 %. Un sistema sin espacio puede impedir que la base de datos escriba, que el correo reciba mensajes o que los servicios creen archivos temporales y logs.
El espacio disponible no es la única restricción. También pueden agotarse los inodos, es decir, la cantidad de archivos que admite el sistema de archivos:
df -iNo borres archivos de forma apresurada. Primero localizá qué directorio creció y confirmá si contiene backups, logs, cachés, sesiones o datos activos. Una eliminación incorrecta puede impedir la recuperación.
Procesos con mayor consumo
Para observar la actividad en tiempo real:
topPresioná q para salir. Para obtener una lista puntual ordenada por CPU o memoria:
ps aux --sort=-%cpu | head
ps aux --sort=-%mem | headUn proceso que aparece primero no es necesariamente defectuoso. MariaDB, Apache, PHP, un backup o un escáner pueden consumir recursos legítimamente. Compará el nombre, usuario, duración y comandos antes de intervenir.
Servicios fallidos con systemd
systemctl --failedEste comando lista unidades que actualmente figuran en estado fallido. Para revisar una en particular sin modificarla:
systemctl status NOMBRE-SERVICIO --no-pager -lReemplazá NOMBRE-SERVICIO por el nombre real. El estado muestra actividad, mensajes recientes y código de salida. Que una unidad esté fallida no implica que sea la causa del incidente; algunos servicios opcionales pueden permanecer desactivados.
Errores del arranque actual
journalctl -p err -b --no-pager-p err filtra por prioridad de error y -b limita la consulta al arranque actual. Para un servicio concreto:
journalctl -u NOMBRE-SERVICIO -b --no-pagerLos logs pueden contener dominios, usuarios, rutas o direcciones IP. Antes de compartirlos públicamente, ocultá información sensible, tokens y contraseñas.
Escuchar puertos y conexiones
ss -lntupPermite revisar qué servicios escuchan en puertos TCP o UDP. Parte de la información puede requerir privilegios. Utilizalo para confirmar si un servicio está escuchando, no para concluir automáticamente que el firewall permite conexiones desde Internet.
Fecha, hora y zona horaria
date
timedatectlUna hora incorrecta puede afectar certificados, tareas programadas, logs y autenticación. timedatectl indica también la zona horaria y el estado de sincronización cuando systemd administra el reloj.
Revisar únicamente la cuenta de hosting
Si no tenés root, concentrá el análisis en espacio, inodos, procesos propios y registros de la aplicación. CloudLinux puede imponer límites de CPU, memoria, procesos o solicitudes simultáneas a la cuenta. En ese caso, el panel puede ofrecer métricas más útiles que los valores globales del servidor.
La guía sobre el error Resource Limit Is Reached explica cómo reconocer esos límites sin confundirlos con una caída completa del servidor.
No reiniciar antes de reunir evidencia
Un reinicio puede recuperar temporalmente un servicio, pero también elimina procesos y cambia el contexto que ayudaba a identificar la causa. Antes de hacerlo, guardá la salida de carga, memoria, disco, procesos, servicios y logs.
No detengas procesos ni servicios solamente porque consumen recursos. Primero verificá qué función cumplen, qué usuarios afectan y si existe una operación legítima en curso.
Orden recomendado de revisión
- Anotá la hora y el síntoma.
- Ejecutá
uptimeyfree -h. - Comprobá espacio e inodos con
df -hydf -i. - Observá los procesos con
topyps. - Revisá unidades fallidas y el estado del servicio afectado.
- Consultá los logs del período del incidente.
- Compará los datos antes de decidir un cambio.
Qué información enviar al soporte
Incluí la hora con zona horaria, el servicio afectado, duración, mensaje de error, salida relevante y acciones realizadas. Indicá también si el problema afecta a todos los sitios o solamente a una cuenta. No envíes claves privadas, contraseñas, tokens ni archivos completos con información sensible.
Este diagnóstico inicial no reemplaza el monitoreo histórico, pero permite diferenciar falta de recursos, disco lleno, servicio fallido y problemas de aplicación sin realizar cambios innecesarios.
