Saltar al contenido principal

Conectores de Salida

La detección es solo la mitad de la automatización — la otra mitad es actuar sobre el mundo exterior. Cuando se dispara una regla de detección, sus acciones REACT pueden alcanzar más allá de la plataforma: llamar a un webhook, o publicar un mensaje en un broker o una cola en la nube. Estos conectores de salida son la forma en que DeviceChain distribuye los eventos procesados hacia los sistemas que ya operas — una herramienta de incidentes, un pipeline de datos, el bus de mensajes de otra aplicación.

La entrega de salida la gestiona un servicio dedicado, outbound-connectors, mantenido deliberadamente separado del motor de detección: un endpoint externo lento o con mal comportamiento puede acumular retrasos en su propia entrega sin llegar nunca a ralentizar la evaluación de reglas.

Estado

Disponible hoy: la acción de webhook httpCall, y una acción publish que entrega a MQTT, Apache Kafka, AWS SNS y AWS SQS a través de un conector versionado con alcance de inquilino, con credenciales almacenadas en el almacén de secretos cifrado. Están planeados objetivos publish adicionales (Google Cloud Pub/Sub, RabbitMQ, Azure, NATS, Redis, Slack, Splunk) y un nodo visual de publish en el lienzo de automatización, bajo el mismo modelo — este repositorio es la fuente de verdad de lo que actualmente se construye.

Las dos acciones de salida​

Ambas son acciones REACT — las agregas a una regla junto a levantar alarma y enviar comando, y cada una puede estar protegida (guarded) por una condición sobre el disparo.

httpCall — llamar a un webhook​

Una solicitud HTTP directa a un endpoint que especificas. El cuerpo de la solicitud se moldea con una expresión CEL sobre el disparo, de modo que envías exactamente los campos que el receptor espera. Todo lo que la acción necesita — URL, método, encabezados, plantilla del cuerpo — vive en la propia acción, así que un webhook puntual no necesita ninguna configuración aparte. La autenticación opcional (un token bearer, un encabezado de clave de API) se almacena en el almacén de secretos y se adjunta en el momento del envío.

La entrega de webhooks está reforzada: se niega a seguir redirecciones, elimina los encabezados reservados y de plataforma, y — cuando hay un secreto adjunto — no repite el cuerpo de la respuesta en los registros (logs), de modo que un destino mal configurado no puede usarse para sondear direcciones internas ni filtrar la credencial.

publish — enviar a un conector​

Para brokers de mensajes y colas en la nube, el destino es un conector reutilizable (ver abajo) en lugar de configuración en línea. Eliges un conector registrado y moldeas el payload del mensaje en CEL; el conector lleva consigo el destino y su credencial sellada. Un conector — configurado y provisto de credenciales una sola vez — se reutiliza en tantas reglas como quieras, y la credencial nunca aparece en una regla.

Una única acción publish genérica cubre todos los tipos de broker/cola: el tipo del conector selecciona el transporte. Los tipos admitidos hoy son mqtt, kafka, aws_sns y aws_sqs.

Los conectores son recursos versionados​

Un conector es un recurso con alcance de inquilino con el mismo ciclo de vida que un perfil de dispositivo o un panel: editas un borrador, publicas una versión inmutable y revocas (roll back) a una anterior si un cambio se comporta mal. Un conector contiene:

  • un tipo (mqtt, kafka, aws_sns, aws_sqs),
  • la configuración de destino para ese tipo (direcciones de broker, topic/cola/ARN, y opciones como QoS o TLS), y
  • una credencial opcional, referenciada por manejador — el valor se escribe en el almacén de secretos y nunca se devuelve en texto claro, exactamente igual que el secreto de un canal de notificación.

Debido a que los conectores tienen alcance de inquilino, un inquilino nunca ve ni envía a través de los conectores de otro.

Cómo funciona la entrega​

Cuando se dispara una acción publish (o httpCall) protegida, REACT no realiza la llamada saliente por sí mismo. Entrega una solicitud de despacho (dispatch request) — la acción resuelta más una clave de idempotencia — al servicio outbound-connectors a través del bus de mensajes interno, y retoma la detección. La solicitud de despacho es duradera: si el servicio de conectores se reinicia, la solicitud sobrevive y se entrega al recuperarse.

Dos propiedades mantienen esto seguro:

  • Disparar y olvidar (fire-and-forget), con forma exacta. Una acción de salida no bloquea la regla esperando una respuesta. Los payloads se moldean únicamente con CEL — no hay scripting arbitrario en la ruta de entrega — de modo que lo que una regla puede enviar está acotado y es revisable.
  • Idempotente por construcción. Cada despacho lleva una clave de idempotencia direccionada por contenido derivada del disparo, de modo que si una detección se reprocesa (replayed) o una entrega se reintenta, el receptor puede reconocer y descartar el duplicado — una reentrega nunca significa un doble envío.

Gobernanza​

Toda acción de salida está sujeta a gobernanza por inquilino, porque una llamada externa es más costosa — y más fácil de convertir en una inundación autoinfligida — que una llamada dentro del proceso. El volumen de salida se limita en tasa por inquilino en ambos extremos del salto: REACT descarta (sheds) las emisiones que exceden el presupuesto antes de despacharlas, y el servicio de conectores admite tráfico de destino dentro de un presupuesto acotado. Un inquilino sin límite configurado recae en un valor predeterminado de plataforma que nunca es ilimitado. El volumen descartado se expone como una métrica operativa para que un operador pueda detectar una regla que ha comenzado a sobreemitir.

Aislamiento y dependencias​

El servicio outbound-connectors se ejecuta en su propio proceso, separado de event-processing. Ese límite es deliberado:

  • Un SDK de nube o un cliente de broker que se cuelga, falla o filtra memoria afecta solo a la entrega de conectores — nunca a la detección.
  • Las bibliotecas cliente de broker/nube que respaldan publish están enlazadas únicamente a este servicio, de modo que el motor de detección replay-correct se mantiene liviano y su superficie de dependencias pequeña.
  • El servicio resuelve las credenciales del conector por sí mismo; el motor de detección nunca las posee.

Relacionado​