Saltar al contenido principal

Alertas y notificaciones

SPOT separa investigación y configuración:

  • Alerts en la navegación global es un centro de control de sólo lectura para viewers y admins.
  • Configuración → Alerts contiene conectores, reglas y cobertura ML, y requiere rol admin para modificar.

El centro de control usa las mismas superficies, tablas, selección y búsqueda que el resto de las vistas operativas. El buscador permite limpiar o aplicar el texto con Enter y mantiene el layout responsive. La página comienza directamente por Alert Control Center, sin una etiqueta técnica previa. Muestra dos vistas:

Alert Control Center en tema oscuro
Centro de control con superficies operativas SPOT en tema oscuro.
Alert Control Center en tema claro
La misma jerarquía visual y selección en tema claro.
  • Active abre por defecto y reúne todas las incidencias pending y firing, aunque no exista ninguna regla de notificación.
  • History conserva estados anteriores, recuperaciones, timeline y entregas.

SPOT detecta la incidencia a partir de los thresholds efectivos de cada source, métrica, parámetros, serie y host. Las reglas no crean la incidencia: sólo deciden qué incidencias se notifican y por qué conector. El detalle muestra el nombre del target, métrica, serie/host, valor observado, thresholds estáticos, score y estado ML, motivo legible y rutas de notificación relacionadas. Open in Metrics Explorer conserva la métrica para continuar la investigación.

La dirección forma parte del contrato de la métrica: normalmente los valores altos son peores, pero en métricas de capacidad libre o hit ratio los valores bajos son peores. Por ejemplo, mssql-file-free-percent evalúa warning 15 % y critical 5 % como límites inferiores; 98 % libre es saludable.

Conectores

En SaaS aparece SPOT Email, gestionado por la plataforma: puedes usarlo en reglas, pero no editarlo ni borrarlo. Los destinatarios se indican en cada regla que utiliza correo. On-prem permite varios conectores de correo:

  • SMTP genérico con STARTTLS.
  • Microsoft 365 relay por MX y puerto 25, identificado mediante IP pública o certificado cliente.
  • Microsoft 365 OAuth2 con smtp.office365.com:587, tenant Entra, client ID y client secret.

No uses usuario y contraseña para Microsoft 365. Pulsa Test para comprobar TLS, autenticación y entrega real.

Los webhooks admiten POST o PUT, timeout, headers no sensibles, cuerpo JSON basado en variables permitidas, basic, bearer o cabecera secreta, CA privada y mTLS. La URL no admite credenciales, parámetros query ni fragmentos: usa el objeto de secretos de sólo escritura para autenticación. SaaS exige HTTPS público y bloquea destinos privados, loopback, link-local y metadata. On-prem permite endpoints internos; HTTP o TLS inseguro requiere activación explícita.

Los secretos son de sólo escritura: la API no vuelve a mostrarlos después de guardar. SPOT sólo conserva un secreto ya guardado mientras no cambien el tipo de conector, su destino de red ni la identidad de autenticación. Si modificas la URL o el modo de autenticación de un webhook, o el preset, servidor, puerto, TLS o identidad OAuth/SMTP de un conector de correo, vuelve a introducir el conjunto completo de credenciales. Una máscara o un campo vacío no autoriza a reenviar el secreto anterior hacia el nuevo destino.

Crear y activar una regla de notificación

  1. Elige todas las métricas alertables, un dominio Operations o métricas concretas.
  2. Limita, si procede, las fuentes/targets y hosts. Sin selección se evalúan todos.
  3. Elige Static, ML o Static + ML.
  4. Para ambas condiciones usa Any (OR), valor predeterminado, o All (AND).
  5. Selecciona uno o varios conectores y guarda el borrador.
  6. Revisa la previsualización: SPOT enumera las incidencias activas que coinciden y el número de correos o webhooks que generaría por serie y host.
  7. Activa con Future only para notificar únicamente transiciones posteriores, o con Notify current para enviar también las coincidencias que ya están en firing.

La regla usa los thresholds efectivos de cada métrica y fuente. Los valores no se copian dentro de la regla, por lo que un cambio posterior en Thresholds se aplica a la siguiente evaluación.

Si varias reglas activas coinciden con la misma incidencia, cada una conserva su propia ruta de notificación. La previsualización hace visible ese solapamiento antes de activar. Cuando hay más de 20 coincidencias actuales, SPOT exige una confirmación explícita.

Ciclo de una alerta

  • pending: la condición acaba de aparecer y ya es visible en Active.
  • firing: en ML requiere 2 observaciones anómalas distintas durante al menos 5 minutos; un score 100 con impacto extremo puede abrir con una.
  • unknown: faltan datos; se suspenden recordatorios.
  • resolved: se han observado 2 evaluaciones sanas.

La identidad de la incidencia combina fuente, métrica, parámetros, serie y host, sin depender de una regla. Por defecto, una regla activa recuerda una alerta abierta cada hora y envía recuperación. Cada entrega se deduplica por regla, incidencia, ciclo, transición y serie/host; los reintentos no generan un segundo evento.

El motor sólo avanza persistencia cuando llega una observación nueva. Releer el mismo bucket no abre antes ni duplica la incidencia. La dirección también importa: una mejora que se separa del patrón esperado no dispara ML.

Las entregas usan una cola idempotente con reintentos. Los webhooks reciben Idempotency-Key y X-SPOT-Delivery-ID estables, y el correo usa un Message-ID estable, para que el receptor pueda deduplicar un reintento tras un fallo de confirmación. Revisa las entregas dentro del detalle de una alerta para ver estado, número de intento y error saneado. Un conector referenciado por una regla activa no se puede borrar.

Qué incluye el correo

El correo usa una plantilla HTML de SPOT, logo incrustado y una alternativa de texto. El asunto y la cabecera identifican severidad, métrica, nombre del target y serie o host; el identificador técnico del target no sustituye a su nombre. Las recuperaciones se distinguen con asunto y badge verde RESOLVED, aunque la incidencia anterior fuera crítica.

Cuando hay histórico disponible, el mensaje incrusta mediante CID una gráfica de las 12 horas anteriores con valores reales, thresholds efectivos, evidencia ML y el punto que abrió la notificación. Esto también se aplica a las incidencias incluidas mediante Notify current. Una serie plana se centra con margen y se identifica como Constant, mostrando valor, rango, número de muestras y thresholds para evitar que parezca una gráfica vacía. Si el histórico no se puede recuperar, la entrega continúa y el correo indica que la gráfica no está disponible.

nota

Las reglas ML evalúan el score observado. El forecast todavía no abre alertas predictivas.