Tipos de evento

Un tipo de evento se define de acuerdo con un contexto de negocio de su operación. Ejemplos: transacción financiera (transaction), autenticación de usuario (user_authentication) o hitos logísticos de entrega (logistics_delivery_event).

El tipo de evento define el contrato de datos de un evento: cómo debe estructurarse el evento, qué datos son relevantes para el análisis y cómo esos datos pueden monitorearse a lo largo del tiempo.

Diferencia entre tipo de evento y evento

  • tipo de evento: es el modelo de datos y las reglas de validación.
  • evento: es la ocurrencia real enviada a la API, siguiendo el modelo del tipo de evento.

Todo evento siempre pertenece a un tipo de evento previamente configurado.

En la API POST /events, el atributo type del evento informa el ID del tipo de evento registrado. Si el tipo informado no existe o está inactivo, la plataforma rechaza el envío.

Contrato por contexto de negocio

Con tipo de evento, la integración deja de depender de un contrato rígido por dominio de negocio y pasa a seguir un modelo más flexible:

  • el tipo de evento se define de acuerdo con el contexto de negocio;
  • los eventos estandarizados se envían al endpoint POST /events;
  • el modelo evoluciona con menor acoplamiento entre producto e integración.

Componentes principales

Un tipo de evento normalmente contempla:

  • campos: estructura del evento (por ejemplo: identificadores, valores, estado y atributos de contexto);
  • métricas: agregaciones e indicadores derivados de los eventos recibidos;
  • monitoreos: criterios y vistas para el seguimiento operacional, riesgo y rendimiento;
  • análisis: evaluadores de riesgo que puntúan el comportamiento reciente de cada evento;
  • reglas: lógica evaluada sobre cada evento recibido, en el momento en que llega.

Esta combinación modela flujos de negocio diferentes sin un endpoint específico para cada nuevo caso de uso.

Campos

Los campos definen el contrato de datos del tipo de evento. Consulte Campos para más detalles sobre configuración, tipos de dato y reglas de validación.

Análisis

Los análisis acumulan el historial reciente de los eventos en ventanas deslizantes y devuelven una puntuación de riesgo para cada nuevo evento, consultada por las reglas. Consulte Análisis para la configuración de las celdas, de las medidas y de las señales.

Último evento recibido

El tipo de evento registra el momento en que recibió el último evento, mostrado en el panel. Es la lectura más directa para confirmar que una integración está enviando datos y para identificar un tipo de evento que dejó de recibir.

Regla predeterminada

El tipo de evento puede indicar una regla predeterminada, aplicada a todos los eventos de ese tipo cuando la solicitud no informa explícitamente qué regla ejecutar. Es la forma recomendada de operar cuando existe una única lógica para el tipo de evento: la integración envía solo los datos, y la regla pasa a ser configuración del panel.

Informar rule.name en la solicitud sobrepone la regla predeterminada.

Relación con la API /events

Después de que un tipo de evento se define, cada ocurrencia se envía a POST /events siguiendo el contrato correspondiente.

Este patrón favorece:

  • estandarización de la ingestión de datos;
  • evolución continua del modelado;
  • reutilización de métricas y monitoreos entre escenarios.

Tipo de evento de fallas

Cada cuenta tiene un tipo de evento reservado, _failure, que registra lo que salió mal en la integración de la cuenta. Las fallas incluyen las solicitudes rechazadas por la API de eventos, las reglas que fallaron al procesar un evento y los monitoreos no ejecutados. La cuenta sigue las fallas como sigue los demás eventos, en lugar de percibir las fallas solo por la ausencia de datos.

Consulte las fallas en Explorar o mediante el agente, como los eventos de cualquier tipo. En la lista de tipos de evento, _failure presenta la marca Sistema. En el menú de tipos de evento de Explorar, _failure está en Más.

La plataforma gestiona el tipo de evento _failure:

  • sus campos no pueden editarse;
  • ninguna regla puede asociarse al tipo de evento;
  • la API no acepta eventos enviados a _failure;
  • el tipo de evento no cuenta en el límite de tipos de evento de la cuenta;
  • sus eventos se conservan durante 7 días.

Los IDs de tipo de evento que empiezan con _ están reservados para los tipos del sistema.

Tipo de evento de alertas

Cada cuenta tiene un tipo de evento reservado, _alert, con un evento en cada apertura y en cada cierre de una alerta de los monitoreos. El historial de alertas puede consultarse en Explorar, medirse con métricas y seguirse con monitoreos, como los demás eventos.

Los eventos de _alert se conservan durante el mismo período que los demás eventos, según Datos originales. Una alerta deja de mostrarse con la retención de la métrica, pero los eventos de apertura y de cierre permanecen. Las alertas anteriores a la creación del tipo de evento no forman parte del historial.

Campo Etiqueta en el panel Contenido
event Evento Abierto, Normalizado, Expirado o Desactivado, según el ciclo de vida
monitor Monitoreo monitoreo que abrió la alerta
metric Métrica métrica del monitoreo
aggregation Agregación agregación monitoreada
event_type Tipo de evento tipo de evento de la métrica
interval Intervalo intervalo del monitoreo, de 1 minuto a 7 días
direction Dirección Alza o Baja; ausente en una alerta originada solo por condiciones
segment Segmento segmento de la alerta; ausente en un monitoreo sin segmentación
segment_hash Hash del segmento identificador del segmento, para agrupar las alertas de un mismo segmento
value Valor valor observado; solo en la apertura
threshold Umbral superado umbral superado; solo en la apertura
duration_seconds Duración (segundos) duración de la alerta; solo en el cierre

La apertura y el cierre de una misma alerta tienen el mismo ID de evento. Los campos de monitoreo, métrica, agregación y tipo de evento presentan el nombre actual del recurso, incluso de un recurso eliminado. Las valoraciones de las alertas no forman parte del tipo de evento.

La plataforma gestiona el tipo de evento _alert como el de fallas, con la marca Sistema y el menú Más en Explorar:

  • sus campos no pueden editarse;
  • ninguna regla puede asociarse al tipo de evento;
  • la API no acepta eventos enviados a _alert;
  • el tipo de evento no cuenta en el límite de tipos de evento de la cuenta;
  • un monitoreo sobre el propio _alert no genera eventos de alerta.

Buenas prácticas

  • Use nombres claros y estables para los tipos de evento.
  • Evite tipos demasiado genéricos, sin semántica de negocio.
  • Trate los cambios de contrato con versionado planificado.
  • Documente la obligatoriedad y el formato de cada campo para el equipo de integración.

Tabla de contenidos