El servidor que nadie revisa: 7 señales de que tu infraestructura está a punto de fallar
Los servidores rara vez mueren de golpe. Avisan durante semanas con síntomas que casi nadie mira. Te enseñamos los 7 más comunes y qué hacer con cada uno.
Un viernes a las 4:40 de la tarde, el servidor de facturación de una distribuidora en Monterrey dejó de responder. No hubo aviso, no hubo alerta, no hubo nadie viendo. El lunes por la mañana, cuando por fin se pudo restaurar, ya se habían perdido dos días de operación y la confianza de tres clientes grandes.
Lo interesante es lo que encontramos al revisar los registros: ese servidor llevaba once semanas avisando. Un disco reportaba sectores reasignados desde agosto. La memoria disponible bajaba un poco cada semana. El log del sistema repetía el mismo error cada madrugada. Todo estaba ahí. Simplemente nadie lo estaba mirando.
Los servidores casi nunca mueren de golpe: se degradan. Y esa degradación deja huellas medibles. Estas son las siete señales que aparecen con más frecuencia antes de una falla mayor, cómo detectar cada una y qué hacer cuando la encuentras.
Sumario
- 01El disco que se llena de a poquito
- 02Memoria que nunca regresa
- 03Discos que ya avisan en SMART
- 04El mismo error en los logs
- 05Temperatura y ventiladores
- 06Carga alta con el CPU ocioso
- 07El servidor que nadie sabe explicar
El disco que se llena de a poquito
Es la causa número uno de caídas evitables. Un disco al 100% no solo impide guardar archivos: detiene bases de datos, corrompe transacciones y bloquea el arranque de servicios.
Lo peligroso no es el disco lleno, es la tendencia. Un sistema que crece 2% por semana te da poco más de un año de aviso; uno que crece 2% diario te da menos de un mes.
df -h # uso por sistema de archivos
df -i # inodos: se agotan antes que el espacio
du -xh / | sort -rh | head -20 # los 20 directorios más pesadosAlerta al 80% y otra al 90%, y registra el uso semanalmente para ver la pendiente. Si df reporta lleno pero du no encuentra el espacio, casi siempre hay archivos borrados que un proceso mantiene abiertos: revísalo con lsof +L1.
Memoria que nunca regresa
Un servidor sano usa mucha memoria: es normal y deseable. La señal de alarma es distinta: memoria que se consume y no se libera aunque baje la carga, acompañada de uso creciente de swap.
Cuando el sistema empieza a intercambiar contra disco, el rendimiento cae en picada y el usuario lo describe como «todo está lentísimo» mucho antes de que algo falle formalmente.
free -h
vmstat 1 10 # columnas si/so: intercambio hacia disco
dmesg | grep -i "out of memory"Identifica el proceso que crece con ps aux --sort=-%mem | head. Si es una aplicación propia, tienes una fuga de memoria y el reinicio programado solo esconde el problema.
Si aparece oom-killer en el log del kernel, el sistema está matando procesos para sobrevivir. Eso es un incidente en curso, no una señal temprana.
Discos que ya avisan en SMART
Los discos duros llevan un registro interno de su propia salud. Casi nadie lo consulta. Y sin embargo, ahí aparecen los sectores reasignados semanas antes de la falla.
smartctl -H /dev/sda # veredicto general
smartctl -A /dev/sda # atributos detallados| Atributo | Qué significa | Umbral |
|---|---|---|
| Reallocated_Sector_Ct | Sectores dañados que el disco ya sustituyó por reserva | Debe ser 0. Creciente: reemplazar |
| Current_Pending_Sector | Sectores sospechosos aún no reasignados | Cualquier valor mayor a 0 es urgente |
| Power_On_Hours | Horas encendido acumuladas | Más de 50,000 h: planear reemplazo |
Programa una revisión SMART semanal automatizada y una prueba larga mensual.
Un arreglo RAID degradado que nadie ve es un servidor sin redundancia, operando con la falsa tranquilidad de tenerla. Y RAID nunca fue, ni será, un respaldo.
El mismo error repitiéndose en los logs
Los logs de un servidor sano son aburridos. Cuando aparece un mensaje que se repite cada noche a la misma hora, o un patrón que empezó hace tres semanas y no se ha ido, hay algo que se está degradando en silencio.
journalctl -p err -S "-7 days" | sort | uniq -c | sort -rn | head -20
dmesg -T --level=err,warnNo busques leerlo todo, busca lo que cambió. Compara la frecuencia de cada tipo de error contra la semana anterior. Errores de entrada/salida, reintentos de red y fallos de autenticación son los tres que más veces anteceden un incidente serio.
Temperatura y ventiladores
El calor mata electrónica, y en la mayoría de las PyMEs el «cuarto de servidores» es un clóset con un minisplit que alguien apaga el fin de semana para ahorrar luz.
sensors # requiere lm-sensors
ipmitool sdr type temperature # servidores con BMC / iDRAC / iLORegistra la temperatura como una métrica más, igual que el CPU. Un servidor que operaba a 38 °C y ahora vive a 52 °C tiene un problema de flujo de aire, un ventilador degradado o un filtro tapado. Ninguna de las tres se arregla sola.
Carga alta con el CPU ocioso
Un load average de 12 en un servidor de 4 núcleos, con el CPU al 15%, no significa que el procesador esté saturado: significa que hay procesos esperando, casi siempre por disco o por red.
uptime
iostat -x 1 5 # %util y await por dispositivo
top # fíjate en la columna wa (I/O wait)Si %iowait es alto de forma sostenida, tu cuello de botella es el almacenamiento, no el procesador. Comprar más CPU en ese escenario es gastar dinero sin mover la aguja.
El servidor que nadie sabe explicar
La séptima señal no es técnica y es la más peligrosa de todas: nadie en la empresa sabe con precisión qué hace ese servidor, quién depende de él ni cómo se levanta si se apaga.
Cuando la respuesta a «¿y si esto se cae?» es un silencio incómodo, ya tienes un incidente pendiente de fecha. La falla técnica es solo el detonante; el daño real lo determina cuánto tarda la empresa en reaccionar.
Una ficha de una página por servidor: qué corre, quién lo usa, de qué depende, quién depende de él, dónde está el respaldo y cuál es el procedimiento de arranque. Una hora de trabajo hoy que ahorra un día completo mañana.
De buenas intenciones a rutina
Leer estas siete señales no sirve de nada si la revisión depende de que alguien se acuerde. La diferencia entre las empresas que se caen y las que no casi nunca es el presupuesto: es la existencia de una rutina.
| Frecuencia | Qué se revisa |
|---|---|
| Automático, todo el día | Disco, memoria, carga, temperatura y disponibilidad de servicios, con alerta al superar umbral |
| Semanal | SMART y estado de arreglos RAID, errores nuevos en logs, éxito de los respaldos |
| Mensual | Tendencias de crecimiento, parches pendientes, certificados por vencer, usuarios y accesos |
| Trimestral | Prueba real de restauración de respaldos y revisión del plan de recuperación |
Ninguno de estos puntos requiere una herramienta cara. Requieren método y que alguien sea responsable de mirarlos. Ese es, casi siempre, el único cambio que separa un viernes tranquilo de un fin de semana perdido.
Checklist de las siete señales
Imprimir o guardar como PDF- Ningún sistema de archivos pasa del 80% y la tendencia de crecimiento está medida df -h · df -i · du -xh / | sort -rh | head -20
- La memoria libre se recupera al bajar la carga y no hay uso sostenido de swap free -h · vmstat 1 10 · dmesg | grep -i "out of memory"
- Ningún disco reporta sectores reasignados ni pendientes, y ningún arreglo está degradado smartctl -H /dev/sda · smartctl -A /dev/sda · cat /proc/mdstat
- No hay errores nuevos ni repetitivos en los registros de los últimos siete días journalctl -p err -S "-7 days" | sort | uniq -c | sort -rn | head
- La temperatura está dentro de rango y todos los ventiladores responden sensors · ipmitool sdr type temperature · ipmitool sdr type fan
- La carga promedio corresponde al uso real de CPU y el tiempo de espera por disco es bajo uptime · iostat -x 1 5 · top
- Existe ficha documentada del servidor: propósito, dependencias, respaldo y arranque Documento de una página, fuera del propio servidor
Ejecuta la lista completa una vez al mes, por servidor. Guarda el resultado con fecha: la comparación entre meses es la que revela las tendencias.
El mantenimiento preventivo no evita que las cosas fallen. Evita que fallen por sorpresa, un viernes a las 4:40 de la tarde.
¿Cuántas de estas siete señales están encendidas ahora mismo en tus servidores?
Hacemos el diagnóstico por ti. Revisamos discos, memoria, logs, respaldos y riesgos críticos de tu infraestructura, y te entregamos un informe claro con lo que hay que atender primero, lo que puede esperar y lo que te está costando dinero sin que lo sepas.
- —Mantenimiento y monitoreo de servidores Linux y Windows
- —Respaldos, continuidad y recuperación ante desastres
- —Observabilidad para aplicaciones .NET
- —Fábrica de software y desarrollo a la medida