La mayoría de las configuraciones de alertas en producción no fueron diseñadas. Fueron copiadas. Los umbrales de un entorno de staging, el conjunto de reglas predeterminado de un proveedor o la estimación aproximada de un ingeniero anterior quedaron registrados en el control de versiones y llevan tiempo disparándose silenciosamente de forma incorrecta. El resultado es conocido: una lluvia constante de notificaciones que entrenó a tu equipo a ignorar las alertas, interrumpida por ese evento crítico que realmente importaba y quedó sepultado en el ruido.

Encuestas del sector sitúan las tasas de falsos positivos entre el 60 y el 80% en el equipo mediano. Investigaciones que rastrearon a ingenieros de guardia encontraron que el 41% ha considerado dejar su puesto por la carga de alertas, y el 62% reporta interrupciones semanales del sueño por notificaciones nocturnas. Esto no es un problema de herramientas que puedas resolver cambiando de proveedor. Es un problema de diseño, y comienza en cómo conectas la telemetría bruta con los umbrales.

Este artículo presenta un marco estructurado para hacer esa conexión correctamente: qué frameworks de métricas usar, cómo establecer umbrales con significado real y cómo articularlo todo para que una alerta le diga a un ingeniero qué hacer, no qué investigar.

Empieza con un framework de métricas, no con un aluvión de métricas

El primer error que cometen los equipos es alertar sobre todo lo que pueden recolectar. Las herramientas de observabilidad hacen que sea trivialmente sencillo enviar miles de series temporales a un backend; no te dicen cuáles importan. Tres frameworks han demostrado ser lo suficientemente sólidos como para anclar en ellos una estrategia de alertas basada en datos.

Las cuatro señales doradas, del libro Site Reliability Engineering de Google, constituyen el conjunto mínimo viable para cualquier sistema orientado al usuario: latencia, tráfico, errores y saturación. La propiedad clave de este conjunto es que está orientado a síntomas. Estas señales detectan que los usuarios se ven afectados antes de que sepas por qué. Como dice el libro SRE: si mides las cuatro señales doradas y alertas a una persona cuando una de ellas es problemática, tu servicio tendrá al menos una cobertura de monitoreo decente. Es un listón bajo expresado con claridad, y es el punto de partida correcto.

Vale la pena preservar un matiz: la latencia de las solicitudes fallidas debe rastrearse por separado de la de las exitosas. Un HTTP 500 provocado por una conexión de base de datos caída puede servirse en microsegundos; si lo promedias con la latencia de solicitudes exitosas, subestimarás la gravedad de la situación.

El método USE, desarrollado por Brendan Gregg, dirige la mirada hacia adentro, hacia los recursos. Para cada recurso, verifica la utilización (el porcentaje de tiempo que estuvo ocupado), la saturación (el trabajo en cola que aún no puede atender) y los errores. Funciona como una lista de verificación: CPUs, memoria, interfaces de red, almacenamiento, grupos de hilos, descriptores de archivo. Su limitación es que los servicios cloud gestionados ocultan muchos de estos recursos, por lo que USE resulta más útil para la capa de infraestructura que realmente controlas.

El método RED, introducido por Tom Wilkie en 2015, fue diseñado para microservicios: Rate (solicitudes por segundo), Errors (solicitudes fallidas) y Duration (distribución de tiempos de respuesta). Donde USE mira hacia adentro a un recurso, RED mira hacia afuera a lo que experimentan las solicitudes. No son frameworks en competencia; responden preguntas distintas. Aplica RED a tus servicios, USE a tu infraestructura, y las cuatro señales doradas como indicador de la experiencia del usuario.

Las señales doradas te dicen si la experiencia del usuario es buena. USE te dice si los servidores están sanos. La mayoría de los equipos los trata como alternativas; los que tienen alertas limpias usan ambos.

La distinción entre síntoma y causa que lo cambia todo

Una estrategia de alertas bien diseñada notifica sobre síntomas, no sobre causas. Un síntoma es algo que experimenta un usuario: tasa de errores elevada, latencia degradada, un flujo de pago roto. Una causa es el mecanismo subyacente: CPU alta, disco saturado, un pool de conexiones mal configurado. Las causas son lo que investigas después de saber que hay un síntoma.

Los equipos que alertan primero sobre causas generan la mayor parte de su ruido. Una CPU al 82% no es un incidente. Una CPU al 82% que provoca que la latencia p99 de tu API de pagos supere su SLO sí lo es. La diferencia es el impacto en el usuario, y eso es lo que debe anclar tu umbral.

Esto no es un argumento en contra de las alertas de infraestructura. Las métricas de saturación, las tasas de llenado de disco y la presión de memoria tienen su lugar en tu stack. Pero corresponden a una severidad menor, enrutadas a una cola en lugar de un pager, e investigadas en horario laboral a menos que estén produciendo síntomas visibles para el usuario.

Umbrales de alertas de infraestructura: de estáticos a dinámicos

Los umbrales estáticos son el pecado original del monitoreo. Un umbral fijo de CPU al 80% se disparará en cada pico de tráfico legítimo, en cada trabajo por lotes, en cada despliegue. Con el tiempo, tu equipo aprende a ignorarlo, y cuando el umbral se dispara porque algo realmente está roto, se ve idéntico a todos los falsos positivos que lo precedieron.

Pasar a un diseño de alertas accionables implica reemplazar o complementar los valores estáticos con tres enfoques superiores:

  • Umbrales basados en percentiles: alerta cuando la latencia p95 o p99 supera un valor, no cuando lo hace la media. Las medias ocultan la latencia de cola, que es lo que experimentan tus usuarios más afectados.
  • Alertas por tasa de cambio: una métrica que pasa del 40% al 75% en dos minutos es más preocupante que una que lleva seis horas en el 75%. Las derivadas detectan condiciones desbocadas antes de que superen los límites absolutos.
  • Umbrales relativos a la línea base: alerta cuando una métrica se desvía de su propia línea base histórica en una cantidad estadísticamente significativa. Esto gestiona el ciclo de tráfico semanal que hace inútil un umbral fijo los lunes por la mañana comparado con los sábados por la noche.

Nada de esto requiere IA. Requiere disciplina en cómo defines la regla de alerta y un backend de métricas que pueda evaluarla eficientemente.

Alertas basadas en SLO y tasa de consumo: el patrón más infrautilizado

La evolución más limpia de los umbrales de alertas de infraestructura es el alertado por tasa de consumo del presupuesto de errores, que proviene del Google SRE Workbook. El concepto es sencillo: tu SLO define cuánto fallo es aceptable en una ventana. Un SLO de disponibilidad del 99,9% te da 43 minutos de inactividad mensual. El presupuesto de errores es 1 menos el SLO.

La tasa de consumo mide con qué rapidez estás gastando ese presupuesto en relación con la tasa que lo agotaría exactamente al final de la ventana. Una tasa de consumo de 1 significa que estás en camino de usar el presupuesto completo al final del mes. Una tasa de 10 significa que lo agotarás en una décima parte del tiempo. Alertar sobre una tasa de consumo elevada en lugar de recuentos brutos de errores te da dos propiedades que los umbrales estáticos no pueden ofrecer: es proporcional al impacto real en el usuario y tiene un sentido de urgencia incorporado que escala según la rapidez con que se deteriora la situación.

Este enfoque también ofrece a los equipos una forma fundamentada de reducir la fatiga por alertas, vinculando las notificaciones al impacto de negocio en lugar de a valores de métricas. Si el presupuesto no se está consumiendo, no hay alerta. Si se consume rápido, la alerta está justificada y el ingeniero que la recibe tiene un mandato claro.

Construcción del pipeline de métricas a alertas

Un pipeline funcional tiene cuatro etapas: recolección, normalización, evaluación y enrutamiento. La recolección es la capa de instrumentación: exporters, agentes y métricas a nivel de SDK. La normalización es donde aplicas etiquetado consistente, descartas el ruido de alta cardinalidad y aplicas políticas de retención. La evaluación es donde viven tus reglas de alerta. El enrutamiento es donde se definen la severidad, la propiedad y las rutas de escalado.

La mayoría de los equipos tienen la recolección y una versión parcial de la evaluación. Les falta la normalización (por eso el mismo servicio aparece bajo seis valores de etiqueta distintos) y el enrutamiento (por eso todas las alertas van al mismo canal con la misma prioridad).

El enrutamiento merece más atención de la que recibe. Un diseño de alertas accionables mapea cada alerta a un nivel de severidad: un síntoma visible para el usuario que consume el presupuesto de errores a alta velocidad va al pager de guardia; una advertencia de saturación en una cola no crítica va a un ticket; un pico correlacionado con un despliegue se resuelve automáticamente tras la ventana de rollout. La lógica de enrutamiento no es compleja, pero tiene que estar escrita y aplicada, o colapsa de nuevo en que todas las alertas van a todos lados.

Aplicamos este patrón en nuestra propia infraestructura multi-datacenter, incluido AMS1 en Ámsterdam, donde el denso peering con AMS-IX hace que la telemetría de red sea especialmente rica y ruidosa. Separar las señales de saturación de infraestructura de las alertas de síntomas a nivel de servicio fue lo que hizo sostenible nuestra rotación de guardia en ese sitio.

Operacionalización de la estrategia

Una estrategia de alertas basada en datos no es una configuración puntual. Requiere un ciclo de revisión regular: qué alertas se dispararon en los últimos 30 días, cuáles se atendieron, cuáles se descartaron y cuáles se dispararon sin un impacto correspondiente en el usuario. Esa revisión es donde ajustas los umbrales, promueves algunas alertas de nivel de causa a síntoma y retiras las que nunca produjeron una acción significativa.

El Catchpoint SRE Report 2025 encontró que el SRE mediano dedica ahora el 30% de su tiempo a operaciones reactivas, frente al 25% del año anterior. Esa trayectoria no se revierte añadiendo más herramientas. Se revierte cuando las alertas que llegan a una bandeja de entrada son las que requieren una respuesta humana, y el resto se gestiona mediante automatización o directamente no se genera.

Empieza con las cuatro señales doradas. Añade USE para la infraestructura que controlas. Incorpora alertas por tasa de consumo para cualquier servicio con un SLO definido. Construye los niveles de enrutamiento antes de ajustar los umbrales. Y luego revisa los resultados mensualmente hasta que la proporción de alertas accionables frente a ruido sea una con la que te sentirías cómodo despertándote a las 3 de la madrugada.