Agentes de monitoreo: de umbrales fijos a detección con contexto

Casi todos los centros de comando conocen la misma escena: decenas de alertas abiertas, la mitad repetidas, varias de ellas sin acción posible, y en medio de todo una señal importante que nadie vio a tiempo. El problema rara vez es la falta de datos. Es la forma en que se decide qué merece atención y la cantidad de trabajo manual que hace falta para entender cada alerta. Este artículo recorre el camino desde los umbrales fijos hasta una detección con contexto, y explica qué papel razonable puede cumplir un agente de IA en ese camino.

Los límites de los umbrales fijos

Un umbral fijo ("alerta si la CPU supera el 85 % durante 5 minutos") es simple, entendible y fácil de auditar. Por eso sigue siendo útil para límites duros, como un disco a punto de llenarse o un certificado que vence. Sus problemas aparecen cuando se usa para todo:

• Ignora el momento. El 85 % de CPU puede ser normal durante el cierre de mes y anómalo un domingo de madrugada.
• Mide causas, no síntomas. Una CPU alta no siempre afecta al usuario. Una latencia que se duplica sin que ningún recurso supere su umbral, sí.
• Envejece mal. Los umbrales se fijan un día y el sistema cambia después: más tráfico, nueva versión, otra infraestructura. Nadie vuelve a revisarlos.
• Genera ruido en cascada. Una sola falla de base de datos dispara alertas en cada servicio que depende de ella, todas por separado.

El libro de SRE de Google insiste en un principio que conviene aplicar antes de cualquier tecnología: alertar sobre síntomas que afectan al usuario y que requieren acción humana, y tratar el resto como información para diagnóstico. Un agente no corrige un diseño de alertas que no respeta ese principio; solo lo hace más rápido.

Líneas base y estacionalidad

El primer paso más allá del umbral fijo es comparar el comportamiento actual con el comportamiento esperado para ese momento. Eso exige una línea base: un modelo, aunque sea simple, de cómo se comporta normalmente cada métrica.

La mayoría de los servicios tiene estacionalidad visible: ciclos diarios (tráfico de día frente a noche), semanales (días hábiles frente a fines de semana) y, en banca, seguros o salud, ciclos de negocio como el cierre de mes, el pago de nómina o los periodos de renovación. Una buena línea base los incorpora.

No necesitas empezar con modelos complejos. Comparar con el mismo momento de la semana anterior ya resuelve muchos falsos positivos. Por ejemplo, esta regla de Prometheus alerta cuando el tráfico de un servicio cae por debajo de la mitad de lo observado una semana antes:

groups:
  - name: ejemplo-linea-base
    rules:
      - alert: TraficoBajoVsSemanaAnterior
        # Compara la tasa actual de solicitudes con la misma ventana hace 7 días
        expr: |
          sum(rate(http_requests_total{job="pagos-api"}[10m]))
            < 0.5 * sum(rate(http_requests_total{job="pagos-api"}[10m] offset 1w))
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "Tráfico menor al 50 % del mismo momento de la semana anterior"

Esta regla tiene límites evidentes: falla en feriados y si la semana anterior también tuvo un problema. Las plataformas de observabilidad comerciales (Dynatrace, Datadog y otras) ofrecen detección de anomalías con líneas base aprendidas automáticamente, y conviene usarlas. Lo importante es entender qué compara cada detección y documentarlo, para poder explicar una alerta cuando alguien la cuestione.

Correlacionar logs, métricas y trazas

Una anomalía aislada dice poco. La pregunta útil es qué otras señales cambiaron al mismo tiempo y en qué componentes relacionados. Para eso las tres señales se complementan:

• Métricas: muestran que algo cambió y cuánto.
• Trazas: muestran por dónde pasa la solicitud y en qué tramo se pierde el tiempo o aparece el error.
• Logs: explican qué ocurrió en un punto concreto, con el detalle que las otras señales no tienen.

Correlacionarlas requiere que compartan identificadores: el nombre del servicio, el entorno, la versión desplegada y, sobre todo, el identificador de traza en cada log. Una plataforma APM captura mucho de forma automática, pero encontrar rápido la causa raíz exige además que el software se escriba para ser observable: logs estructurados, identificadores de correlación, propagación de contexto de trazas, métricas de negocio y eventos significativos. Plataforma observable no es lo mismo que aplicación observable. OpenTelemetry define convenciones semánticas para esos atributos y es el estándar abierto de referencia para instrumentar.

Aquí es donde un agente empieza a aportar. Ante una anomalía, puede consultar las señales relacionadas a través de la topología del servicio, revisar qué dependencias muestran cambios en la misma ventana y separar el síntoma original de sus efectos en cascada. Es el mismo trabajo que hace un analista experimentado, pero sin tener que abrir diez paneles.

Agregar contexto de cambios y de negocio

Dos tipos de contexto cambian por completo la lectura de una anomalía.

Contexto de cambios

Una parte importante de los incidentes sigue a un cambio: un despliegue, una modificación de configuración, una actualización de infraestructura. Si los eventos de despliegue y los cambios aprobados llegan a la plataforma de observabilidad (o el agente puede consultarlos en la herramienta de gestión de cambios), la primera pregunta "qué cambió" se responde sola. Cuidado con el sesgo inverso: que algo haya cambiado justo antes no prueba que sea la causa.

Contexto de negocio

Un servicio de pagos con latencia alta a las tres de la mañana no tiene el mismo impacto que a las doce del mediodía del día de pago de nómina. El agente puede incorporar información como el calendario de negocio, los horarios de servicio de la CMDB, las ventanas de mantenimiento y las métricas de negocio (transacciones aprobadas, solicitudes completadas) para estimar el impacto, no solo la desviación técnica.

Las ventanas de mantenimiento merecen mención aparte: una anomalía durante un mantenimiento planificado es esperable y no debería competir por la atención del centro de comando.

Cómo resume el agente una anomalía para el centro de comando

El producto del agente no es una nueva alerta, sino un resumen que permite decidir rápido. Un formato útil y consistente incluye:

1. Qué se observa: la señal anómala, el servicio, desde cuándo y cuánto se desvía respecto de su línea base.
2. Impacto estimado: usuarios, transacciones o procesos de negocio afectados, con la fuente de ese dato.
3. Señales relacionadas: otras anomalías correlacionadas, indicando cuál parece el origen y cuáles los efectos.
4. Contexto: cambios recientes, ventanas de mantenimiento, eventos de negocio en curso.
5. Hipótesis: una o más causas posibles, cada una con su evidencia y su nivel de confianza.
6. Siguiente paso sugerido: el runbook aplicable o la consulta que conviene hacer a continuación.
7. Qué no sabe: datos faltantes o señales que no pudo consultar.

El último punto es tan importante como los anteriores. Un resumen que reconoce sus vacíos es más útil que uno que los rellena con suposiciones. Cada afirmación del resumen debería poder rastrearse hasta la consulta que la respalda, y el proceso completo debe quedar registrado. En el artículo sobre triaje de incidentes con agentes detallamos cómo diseñar ese registro.

En una primera etapa, el agente debería operar con permisos de solo lectura y entregar sus resúmenes al operador, que decide. Ampliar ese alcance es una decisión aparte, que conviene tomar caso por caso según el riesgo y la reversibilidad de cada acción.

Mantener a raya los falsos positivos

Detección con contexto no significa más alertas. Si el centro de comando recibe más ruido que antes, el proyecto fracasó aunque la tecnología funcione. Algunas prácticas que ayudan:

• Agrupar antes de notificar. Anomalías correlacionadas en la misma ventana y la misma topología deben llegar como un solo evento.
• Exigir persistencia. Una desviación de pocos segundos rara vez requiere acción humana; define un tiempo mínimo según la criticidad del servicio.
• Separar notificación de registro. No toda anomalía debe despertar a alguien. Muchas pueden quedar registradas para revisión diaria.
• Medir la calidad de las alertas. Por cada alerta, registra si llevó a una acción. Las reglas que casi nunca la producen se revisan o se eliminan.
• Retroalimentar al agente. Cuando el operador descarta un resumen, el motivo ("mantenimiento", "comportamiento esperado", "duplicado") es información valiosa para ajustar reglas y contexto.
• Revisar periódicamente. Líneas base, reglas y calendarios de negocio cambian. Programa revisiones, por ejemplo trimestrales.

El objetivo final es que cada notificación que llega al centro de comando sea comprensible, accionable y justificada. Un agente bien diseñado ayuda a acercarse a ese objetivo. El criterio sobre qué hacer con cada alerta sigue siendo del equipo.