Un buen umbral de alerta de servidor salta cuando alguien tiene que actuar y se queda en silencio el resto del tiempo. En la práctica, eso significa alertar por valores sostenidos y no por picos aislados, medir la carga por núcleo de CPU y no como cifra bruta, vigilar la memoria disponible y la swap en lugar de la «RAM usada», alertar pronto sobre el espacio en disco y sobre lo rápido que crece, y considerar que cualquier reinicio no planificado merece conocerse. Divide las alertas en un nivel de aviso para el horario laboral y un nivel crítico que pueda despertar a alguien, y revisa las cifras después de cada incidente.
Esta guía repasa cada métrica, explica cómo es un umbral con sentido y termina con una tabla de valores de partida. Son puntos de partida, no reglas: cada servidor tiene su propia normalidad, y el umbral correcto es el que se ajusta a ella.
Para qué sirve un umbral
Cada alerta cuesta atención. Una alerta que salta y no requiere ninguna acción enseña a la gente a ignorar la siguiente, y la siguiente puede ser real. Antes de fijar un umbral, responde a tres preguntas:
¿Qué se romperá si este valor sigue así, y en cuánto tiempo?
¿Qué haría realmente la persona que recibe la alerta?
¿Puede esperar hasta mañana?
Si no se rompe nada y nadie actuaría, es una gráfica, no una alerta. Si puede esperar hasta mañana, es un aviso. Solo lo que no puede esperar debería llegar a un móvil de noche.
Niveles de aviso y crítico
Dos niveles por métrica funcionan bien para la mayoría de los equipos:
Aviso: algo evoluciona en la dirección equivocada. Envíalo por email o a un canal del chat del equipo y gestiónalo en horario laboral.
Crítico: una caída está cerca o ya ha empezado. Envíalo como notificación push a quien esté de guardia, de día o de noche.
Si tu herramienta de monitorización tiene un solo umbral por métrica, puedes conseguir el mismo efecto con el enrutamiento: fija el umbral donde hace falta actuar y elige el canal para cada servidor. Una alerta de disco en un servidor de staging puede ir por email; la misma alerta en la base de datos de producción puede ir al chat del equipo de guardia. En Uptimecheck, las notificaciones se eligen por monitor, lo que hace que esa separación sea sencilla. Con los turnos de guardia, las alertas push llegan a quien está de guardia en ese momento, y la escalada puede retener un canal entre 5 y 60 minutos y avisar solo si el problema continúa y nadie lo ha reconocido.
La duración importa más que los picos
La fuente de ruido más habitual es alertar por una sola lectura. Una CPU al 100 % durante diez segundos en un despliegue, una copia de seguridad o una reconstrucción de caché es normal. Una CPU al 100 % durante veinte minutos no lo es. Siempre que tu herramienta lo permita, añade una duración: «por encima del 90 % durante 10 minutos» en lugar de «por encima del 90 %».
Cuando no lo permita, usa métricas que ya se suavizan con el tiempo. La carga media de 15 minutos es un buen ejemplo: una ráfaga corta apenas la mueve, mientras que una sobrecarga sostenida la sube y la mantiene arriba.
CPU
Una CPU alta por sí sola rara vez es un problema. Un servidor ocupado es un servidor que está haciendo su trabajo. La CPU se convierte en un problema cuando se mantiene saturada el tiempo suficiente para que las peticiones hagan cola y los tiempos de respuesta suban. Alerta por un uso sostenido y míralo junto con los tiempos de respuesta de tus comprobaciones de disponibilidad. Si la CPU está al 95 % y los tiempos de respuesta no cambian, el servidor está ocupado, no fallando.
Carga media por núcleo
En Linux, la carga media es, a grandes rasgos, el número de procesos que se están ejecutando o esperan CPU, y en Linux también los que esperan E/S de disco, promediado en 1, 5 y 15 minutos. Una carga bruta de 4 no significa nada por sí sola: en un servidor de 16 núcleos es ligera, en uno de 2 núcleos es el doble de lo que la máquina puede asumir. Divide por el número de núcleos antes de comparar; te lo dice nproc.
El valor de 1 minuto reacciona rápido y tiene mucho ruido. Úsalo para diagnosticar, no para alertar.
El valor de 15 minutos es el que conviene usar para alertar. Por encima de 1 por núcleo, el trabajo hace cola; muy por encima y durante mucho tiempo, los usuarios lo notan.
Una carga alta con poca CPU suele indicar procesos que esperan al disco o al almacenamiento en red. Mira la E/S, no el código.
RAM y swap
La «RAM usada» es una métrica engañosa en Linux. El kernel usa la memoria libre para la caché de archivos y la devuelve cuando las aplicaciones la necesitan, así que un servidor sano suele mostrar la memoria casi llena. Mira en su lugar la memoria disponible, la columna «available» de free -m, que cuenta la caché que se puede recuperar.
La swap dice más. Un servidor que normalmente no usa swap y empieza a hacerlo está bajo presión de memoria, y el rendimiento cae en picado en cuanto la memoria activa pasa al disco. Dos señales útiles:
Uso de swap que aparece o crece en un servidor que normalmente no tiene.
Memoria disponible que baja de forma constante durante días, lo que a menudo apunta a una fuga en un proceso de larga duración.
Los servidores de bases de datos son un caso especial: están configurados para usar la mayor parte de la memoria a propósito. Fija sus umbrales a partir de lo que ves en una semana normal.
Espacio en disco y crecimiento
Un disco lleno es una de las causas más comunes de caídas evitables. Las bases de datos dejan de escribir, los logs dejan de rotar, las sesiones no se pueden guardar y las copias de seguridad fallan. El disco es también la métrica más fácil de acertar, porque rara vez cambia deprisa, lo que deja tiempo para actuar si alertas pronto.
Usa un umbral en porcentaje para el aviso y el crítico, pero ajústalo al tamaño. En un volumen de 2 TB, un 10 % libre siguen siendo 200 GB; en uno de 20 GB son 2 GB, que un solo log descontrolado puede comerse en una tarde.
Vigila el crecimiento además del nivel. Un disco al 70 % que ha crecido 10 puntos esta semana es más urgente que uno que lleva un año al 85 %.
Ten claro qué lo llena: logs, copias de seguridad guardadas en local, archivos subidos, imágenes de Docker, archivos de base de datos. Cada uno tiene una solución distinta.
Red
Es difícil fijar un umbral fijo para el tráfico de red, porque lo normal varía con la hora del día y la temporada. Hay dos patrones que merecen una alerta. Un tráfico muy por encima de lo habitual, cerca de la capacidad del enlace, puede indicar un pico de tráfico, un scraper o un ataque. Un tráfico que cae casi a cero en un servidor que normalmente está ocupado puede significar que lo han sacado del balanceador de carga o que ha perdido la red, aunque la máquina en sí parezca estar bien. Aprende el rango normal con unas cuantas semanas de historial antes de fijar cifras.
Reinicios
Siempre vale la pena saber de un reinicio no planificado. Puede ser una actualización del kernel, un mantenimiento del proveedor de hosting, un fallo o un evento de falta de memoria. Aunque todo vuelva a funcionar, los servicios que no están configurados para arrancar al inicio, las tareas programadas que tocaban durante el reinicio y los volúmenes montados pueden quedar en mal estado. Alerta por cada reinicio fuera de una ventana de mantenimiento, con nivel de aviso si el servidor se recuperó solo.
Valores de partida
Los valores siguientes son puntos de partida de ejemplo para un servidor web o de aplicaciones típico. Úsalos durante las primeras semanas y luego ajústalos a lo que observes.
MétricaAviso (ejemplo)Crítico (ejemplo)CPUPor encima del 85 % durante 15 minutosPor encima del 95 % durante 15 minutos, con tiempos de respuesta al alzaCarga media (15 min)Por encima de 1 por núcleoPor encima de 2 por núcleoMemoria disponiblePor debajo del 15 %Por debajo del 5 %SwapCualquier uso en un servidor que normalmente no tieneMás del 50 % de la swap en usoDiscoPor encima del 80 %, o lleno en una semana al ritmo actualPor encima del 90 %, o lleno en un díaRedMuy fuera del rango normal para la hora del díaCerca de la capacidad del enlace, o casi a cero en un servidor ocupadoReinicioCualquier reinicio fuera de una ventana de mantenimientoLos servicios no han vuelto tras un reinicio
La monitorización de servidores de Uptimecheck informa de CPU, memoria, disco y red cada minuto en Linux, macOS y Windows. Fijas umbrales de CPU, memoria y disco por servidor, con una duración como 5 o 15 minutos, y también recibes alertas por reinicios y cuando un servidor deja de dar señales, así que una máquina que ha dejado de informar nunca se confunde con una que está tranquila. Para entender por qué importan estas cifras, consulta cómo mantener tu web en marcha con la monitorización del estado del servidor.
Vigila también los síntomas
Las métricas del servidor describen causas. Tus usuarios viven los síntomas: páginas lentas, errores y tareas que fallan. Monitoriza ambas cosas. Una comprobación de disponibilidad con validación de la respuesta te avisa cuando la web falla, y un heartbeat te avisa cuando la copia de seguridad no ha terminado. Cuando una alerta de síntoma y una de recursos saltan a la vez, la causa suele ser evidente. Cuando solo salta la de recursos, a menudo tienes tiempo de arreglarlo antes de que nadie lo note.
Esto también te permite subir los umbrales del servidor con confianza. Si la web se comprueba cada minuto, una alerta de CPU no tiene por qué ser lo que detecte una caída. Puede ajustarse como aviso temprano en lugar de como último recurso. La misma lógica se aplica a las comprobaciones de webs; consulta cómo reducir las falsas alertas en la monitorización de disponibilidad.
Revisa los umbrales después de los incidentes
Los umbrales nunca están terminados. Después de cada incidente, y una vez al mes en los servidores que generan ruido, pregúntate:
¿Saltó una alerta antes de que los usuarios lo notaran? Si no, ¿qué métrica se movió primero y podría haberlo detectado un umbral más bajo?
¿Qué alertas saltaron sin que nadie hiciera nada? Súbelas, añádeles una duración o pásalas a un canal de horario diurno.
¿Llegó la alerta a alguien que pudiera actuar? Si no, cambia el enrutamiento.
¿Ha cambiado la normalidad del servidor tras una actualización, una migración o más tráfico?
Anota las respuestas en el informe del incidente, para que cada cambio tenga un motivo. La plantilla de postmortem de incidentes tiene una sección precisamente para esto.
Resumen
Alerta por lo que necesita a una persona, con la urgencia que realmente tiene. Usa valores sostenidos, la carga por núcleo, la memoria disponible y la swap, el nivel y el crecimiento del disco, y cada reinicio no planificado. Empieza con valores de ejemplo, aprende la normalidad de cada servidor y ajusta después de cada incidente.
Uptimecheck reúne la monitorización de servidores, las comprobaciones de disponibilidad, los heartbeats y las páginas de estado en una sola cuenta. Empieza una prueba gratuita de 14 días, sin tarjeta de crédito.