El fracaso más común de un sistema de monitoreo no es que falle: es que avise tanto que nadie lo mire. Esta guía trata sobre el diseño de la señal.
La fatiga de alertas es peor que no monitorear
Un canal que recibe cincuenta avisos diarios, de los cuales cuarenta y ocho son irrelevantes, entrena al equipo a ignorarlo. Cuando llega el aviso que sí importaba, se pierde entre los demás.
Peor aún, produce una falsa sensación de cobertura ante la dirección: hay monitoreo, hay alertas, y sin embargo el incidente lo reportó un usuario.
Tres niveles con destinos distintos
Monitorear el síntoma, no solo la causa
Vigilar CPU y memoria es necesario pero insuficiente: un servidor con métricas normales puede estar sirviendo errores. La señal que mejor refleja la experiencia real es la disponibilidad y el tiempo de respuesta medidos desde fuera, sobre los recorridos que importan.
Un chequeo que carga la página de inicio y otro que ejecuta un inicio de sesión completo detectan clases de problemas distintas. El segundo es el que descubre que el servicio está caído para los usuarios aunque el servidor responda.
Cada alerta necesita una acción asociada
Si al recibir un aviso la reacción es «vale, ya veremos», esa alerta no debería existir en ese nivel. Toda alerta crítica debería tener documentado qué verificar primero y a quién escalar.
Escribir esa nota junto a la alerta, en el momento de crearla, es lo que evita que el conocimiento dependa de quién esté de guardia.