Umbrales de monitoreo: ni alertar por todo ni callar lo importante

Hay dos formas de arruinar un buen sistema de monitoreo, y son opuestas. Una es poner los umbrales tan sensibles que todo dispara una alerta: el equipo termina sepultado en falsas alarmas y aprende a ignorarlas. La otra es ponerlos tan laxos que nada suena nunca —hasta que el problema ya es una caída. El punto medio no se adivina: se construye.

El umbral es una decisión, no un default

Casi todas las herramientas traen umbrales por defecto, y casi ninguno sirve tal cual. "Alertar cuando la CPU supere 90%" suena razonable hasta que descubres que ese servidor vive al 92% sin problema, o que otro al 70% ya está en apuros. Un umbral copiado de una plantilla genérica ignora lo único que importa: qué es normal para ese sistema en concreto.

Cómo se construye un umbral que significa algo

• Línea base primero. Antes de alertar, observa: cuál es el comportamiento normal a lo largo de días y semanas. El umbral se cuelga de esa realidad, no de un número redondo.
• Estacionalidad. El tráfico de las 11 de la mañana no es el de las 3 de la madrugada, ni el de cierre de mes es el de un domingo. Un buen umbral entiende el ritmo del negocio.
• Niveles escalonados. Advertencia antes que crítico. La advertencia te da tiempo de actuar; el crítico avisa que ya duele. No todo es rojo.
• Dependencias. Si cae un switch raíz, no quieres cien alertas de los cien equipos detrás de él: quieres una, la del switch. Configurar dependencias —algo que PRTG maneja bien— convierte una avalancha en un diagnóstico.

Un umbral que se ganó con datos

Vale aterrizarlo en ese servidor que vive al 92%. Es una base de datos que, por diseño de su motor, mantiene la RAM casi llena como caché —comportamiento normal y hasta deseable—. Con el umbral de fábrica ("alertar sobre 90%") disparaba una crítica cada pocos minutos; el equipo la silenció por hartazgo, y con ella silenció cualquier problema real de esa máquina. La solución no fue subir el número a ciegas, sino observar dos semanas de línea base: la memoria oscilaba entre 88% y 94% en operación sana, y el verdadero síntoma solo aparecía cuando el swap empezaba a crecer de forma sostenida. El umbral útil terminó no siendo sobre RAM en absoluto, sino sobre uso de swap. Menos alertas, y las que quedan significan algo. Ese es todo el oficio.

El mismo principio vale para toda red

Definir qué es "normal" antes de vigilar es el mismo trabajo que hace un buen inventario en entornos industriales; de hecho, ya vimos que monitorear una red OT no es como monitorear TI justamente porque el "normal" es otro. El método, sin embargo, se repite: aprender el patrón, y solo entonces poner la frontera.

Un ajuste vivo

Ningún conjunto de umbrales es definitivo. La infraestructura cambia, las cargas crecen, aparecen falsos positivos nuevos. Un monitoreo serio revisa sus umbrales con los datos que él mismo genera —qué alertó de más, qué se escapó— y ajusta. Ese afinado continuo, que evita tanto el ruido como los puntos ciegos, es parte de lo que sostenemos en nuestro servicio de monitoreo continuo y respuesta. La meta no es alertar menos ni alertar más: es que cada alerta valga la pena.