Procesamiento de eventos y alarmas

DeviceChain convierte la telemetría bruta de los dispositivos en señales sobre las que puedes actuar. Un servicio dedicado, event-processing, observa los eventos a medida que fluyen por el pipeline. Su etapa de detección evalúa reglas en streaming en tiempo real. Su etapa de acciones ejecuta después las respuestas automatizadas que declara cada disparo: levantar una alarma (una condición con estado que tiene un ciclo de vida, una severidad y una vía para notificar a una persona) o emitir un comando de vuelta al dispositivo.

El servicio evalúa sobre el tiempo del evento y persiste su estado, de modo que un reinicio vuelve a derivar disparos idénticos: ninguno se pierde, ninguno se duplica.

Estado

Disponible hoy: la detección y las acciones son el motor de detección en vivo de la plataforma, con los ocho tipos de condición (umbrales estáticos o determinados por atributos) y las cuatro acciones con guardas por acción. Las reglas se autoran de tres maneras sobre un mismo esquema —generador de formularios, lienzo visual de automatización y, con el servicio de IA habilitado, una puerta "Describir" en lenguaje natural—, todas validadas por el mismo compilador antes de publicar, y el lienzo puede previsualizar un borrador contra historial reproducido. El ciclo de vida de alarma de cuatro estados con escalamiento de severidad en el mismo lugar, las suscripciones en vivo a alarmas y detecciones, y la notificación por correo electrónico/webhook con escalamiento ya están implementados.

Dónde viven las reglas

Defines las reglas de detección sobre un perfil de dispositivo, el contrato de capacidades versionado compartido por uno o más tipos de dispositivo. El perfil está versionado (borrador → publicar → revertir), así que cambias la lógica de detección de una flota igual que cambias sus definiciones de métricas y comandos: autoras un borrador, lo publicas de forma atómica y lo reviertes si hace falta. Todo dispositivo que resuelve a ese perfil adopta sus reglas automáticamente.

Una regla plantea una condición sobre la telemetría del perfil, declara su severidad y enumera las acciones a ejecutar cuando se dispara.

Delimitar una regla a un grupo

Por defecto, una regla se aplica a todos los dispositivos que resuelven a su perfil. En su lugar, puedes delimitar una regla a un grupo dinámico, para que se dispare solo para los dispositivos que son miembros en ese momento. Por ejemplo, puedes ejecutar una regla de calor más estricta únicamente en dispositivos en zonas áridas. La delimitación es opcional y se define por regla. Las reglas de ausencia y de correlación de área no se pueden delimitar, y publicar una delimitada se rechaza.

La membresía del grupo se registra en cada evento en el momento en que se resuelve. Por eso el motor ve exactamente qué reglas aplicaban en ese instante, incluso cuando reproduce historial para previsualizar o volver a derivar disparos. Cuando un dispositivo entra o sale del grupo, queda inscrito o excluido en su siguiente evento (en todas las réplicas de device-management; una réplica que no recibió el aviso del cambio se pone al día cuando caduca su copia en caché, en cinco minutos como máximo por defecto), sin editar ninguna regla ni reescanear nada.

Tipos de condición

La detección cubre condiciones de umbral, sostenida por duración, ocurrencia repetida, tasa de cambio, silencio/ausencia, conectividad, agregado en ventana y correlación de área/grupo.

Condición	Se dispara cuando	Parámetros
Umbral	una lectura cruza una comparación (p. ej. temperature > 80)	la comparación + un valor umbral
Duración	la condición se sostiene continuamente durante al menos un tiempo definido (p. ej. pressure low for 5 minutes)	un tiempo de sostenimiento
Repetición	la condición ocurre un número de veces dentro de una ventana (p. ej. 3 faults in 10 minutes)	un conteo de ocurrencias + una ventana
Tasa de cambio	una métrica cambia demasiado rápido entre lecturas consecutivas (p. ej. temperature rising > 5°/s)	la comparación + una marca opcional para normalizar el cambio a una tasa por segundo
Ausencia / silencio	un dispositivo deja de reportar: ningún evento en absoluto dentro de una ventana (una verificación de tipo "hombre muerto"); todo evento cuenta como latido, así que la regla no lleva condición	una ventana de silencio
Conectividad	un dispositivo reporta una desconexión autoritativa (levanta) y se reconecta (resuelve), para transportes que afirman presencia como Sparkplug-B y LwM2M. Se autora en el generador de formularios de la consola, en el lienzo de automatización o a través de la API.	ninguno: el borde de presencia es toda la señal
Agregado en ventana	un agregado sobre una ventana cruza una comparación (p. ej. average > 50 over 10 minutes)	la función (count/sum/avg/min/max), una ventana (tumbling, sliding, session o una ventana de conteo de N eventos), la comparación + valor
Correlación de área	suficientes dispositivos distintos en un área cumplen la condición en conjunto (p. ej. ≥ 3 devices in a zone report a fault within 5 minutes)	el tipo de área/ancla, un conteo de dispositivos distintos + ventana

La comparación de cada condición puede ser una hoja estructurada metric · operator · value o una expresión CEL avanzada sobre el evento. Ambas se verifican de tipos de forma estática y se limitan en costo cuando se publica el perfil, de modo que una regla mal formada o desbocada se rechaza antes de poder ejecutarse.

Las ventanas tienen un techo

Todo lapso de tiempo que declara una regla está limitado a 24 horas de forma predeterminada. Una regla que pida más se rechaza al publicar el perfil, y el error nombra el campo y el límite. Consulta Límites de tiempo en las reglas.

Límites de tiempo en las reglas

El techo predeterminado de 24 horas se aplica a todo lapso de tiempo que declara una regla: una ventana, un tiempo de sostenimiento, un tiempo de espera de silencio y un hueco de sesión.

El techo existe porque una regla con ventana guarda un registro por lectura durante toda la ventana, por dispositivo, en un motor compartido por todos los inquilinos. Una ventana de varios días sobre una flota que reporta cada pocos segundos es una gran cantidad de memoria retenida indefinidamente. Ese costo lo paga todo el mundo en la instancia, no solo el inquilino que autoró la regla.

Los tiempos de espera de silencio y los huecos de sesión también están limitados, aunque no retengan lecturas. Esas reglas rearman un temporizador cada vez que un dispositivo reporta, y los temporizadores sustituidos no se liberan hasta que vence su plazo. Por eso un tiempo de espera largo con reportes frecuentes se acumula de la misma manera.

Si necesitas un lapso mayor, un operador puede subir el límite de la instancia (maxRuleDurationSeconds) tras dimensionar la memoria. Antes de pedirlo, considera si la pregunta trata en realidad de retención más que de detección. Una pregunta del tipo «comparar contra el mes pasado» suele responderse mejor consultando el historial almacenado que reteniendo un mes de lecturas en memoria.

Abrir una regla almacenada en el formulario o en el lienzo

Tanto el generador de formularios como el lienzo de automatización autoran reglas de Conectividad. Como el borde de presencia es toda la señal, ninguno ofrece condición ni parámetros para ese tipo: en el lienzo es un nodo de Conectividad que recibe el flujo de la fuente y alimenta acciones, como cualquier otra condición.

Ninguna de las dos superficies reescribe en silencio una regla que no puede mostrar por completo. Si el formulario abre una regla almacenada que no puede contener por completo —un campo que no modela o un tipo que no conoce—, advierte que parte de la definición no se muestra y enumera los campos que no conservaría. Guardar una regla así pide primero una confirmación: el diálogo nombra los mismos campos, Guardar de todos modos reemplaza la original únicamente con lo que ves y Cancelar no guarda nada. Una regla que el formulario puede contener por completo se guarda sin el diálogo. Ese aviso es distinto del de «no se pudo leer» que aparece para una definición que no es JSON válido. Una regla de Conectividad se abre sin ninguno de los dos.

El lienzo es más estricto. Al abrir una regla almacenada, pregunta al compilador si guardar la regla tal como está dispuesta conservaría todo lo que dice la definición almacenada. Cuando la respuesta no es afirmativa, el lienzo indica el motivo y desactiva el guardado para esa regla:

• Si la regla tiene un tipo para el que el lienzo no tiene nodo, o un campo o un tipo de acción que el lienzo no modela, edítala a través de la API. El formulario también puede abrirla, pero advertirá que guardar allí descarta lo que no puede mostrar.
• Si la regla tal como la dispone el lienzo no compila, el lienzo no puede confirmar que guardar la mantendría intacta. Edítala en el formulario.
• Si el lienzo no puede contactar con el compilador para hacer la comprobación, elige Comprobar de nuevo. El guardado sigue desactivado hasta que la comprobación se complete.

Hay dos casos propios de las reglas construidas en el lienzo:

• Si la definición de la regla se modificó a través de la API después de guardarla por última vez en el lienzo, la disposición guardada ya no coincide con la regla. El lienzo vuelve a disponer la regla a partir de su definición actual y te lo indica, para que guardar no deshaga el cambio. Si no puede disponer la regla actual por completo, el guardado se desactiva.
• Si el lienzo guardado ya no compila tal como está, se abre como estaba, con una nota. Corrígelo en el lienzo; al guardar, la regla almacenada se reemplaza por lo que hay en el lienzo. Un lienzo que no compila no puede compararse con la regla, así que si la regla también se modificó a través de la API desde que se guardó por última vez en el lienzo, guardar aquí deshace ese cambio. La nota lo indica.

Umbrales estáticos y dinámicos

Un umbral puede ser un valor fijo en la regla, o dinámico: el nombre de un atributo de dispositivo que la regla lee en el momento de la evaluación. Un umbral dinámico permite que una sola regla se adapte por dispositivo. El perfil define la regla una vez, y cada dispositivo lleva su propio límite como un atributo con alcance SERVER o SHARED (los valores establecidos por el servidor tienen prioridad). Cambia el atributo y el umbral efectivo cambia, sin editar la regla.

Umbrales dinámicos en una expresión CEL

En una expresión CEL, las mediciones del evento son el mapa m y los atributos del dispositivo son el mapa attr, ambos de una clave a un número. Una clave está en attr solo mientras el dispositivo tiene un valor numérico para ella con alcance SERVER o SHARED. Falta cuando el atributo nunca se estableció, cuando se estableció con algo que no es un número, cuando se estableció con alcance CLIENT, y durante un breve tiempo después de establecerlo, hasta que el cambio llega al motor de detección.

Compruebe la presencia antes de leer un valor. Un umbral dinámico creado en el formulario se compila como "tempLimit" in attr && "temp" in m && m["temp"] > attr["tempLimit"], que no se dispara para un dispositivo sin el atributo. El formulario no tiene valor de respaldo. Para recurrir a un límite fijo, escriba el respaldo como su propia comparación:

"temp" in m && ("tempLimit" in attr ? m["temp"] > attr["tempLimit"] : m["temp"] > 80.0)

Como esta expresión no puede ser verdadera para un evento sin temp, la regla solo mira los eventos que llevan temp. Un evento sin ella se omite: no resuelve una alarma de umbral y no interrumpe el tiempo de sostenimiento de una regla de duración.

Una condición de umbral o de duración que sería verdadera en todos los eventos de todos los dispositivos sin los atributos que lee, sea cual sea el contenido del evento, se rechaza al publicar el perfil. Por ejemplo, !("tempLimit" in attr) || m["temp"] > attr["tempLimit"] levantaría una alarma para cada uno de esos dispositivos, informara lo que informara, mientras le faltara el atributo. Una condición que sigue dependiendo de la lectura, como !("tempLimit" in attr) && m["temp"] > 80.0, se acepta. Tenga en cuenta que también se aplica a los dispositivos cuyo atributo tiene un tipo o un alcance incorrectos, no solo a los que nunca lo establecieron.

La forma aceptada lleva una advertencia. Cuando la condición de una regla une con && una comprobación de que un atributo no está definido y otras comprobaciones, como en !("tempLimit" in attr) && m["temp"] > 80.0, el formulario, el lienzo y la puerta «Describir» muestran una advertencia que nombra el atributo e indica que la regla se aplica a todos los dispositivos que no lo tienen. La advertencia es solo un aviso: la regla se guarda y se evalúa exactamente como está escrita. Existe porque «no definido» es más amplio que «no configurado», así que la regla también abarca los dispositivos cuyo atributo tiene un tipo o un alcance incorrectos. La advertencia es más fuerte cuando la comprobación es una alternativa y no un requisito, como en "temp" in m && (!("tempLimit" in attr) || m["temp"] > attr["tempLimit"]): esa condición es verdadera para todo dispositivo sin el atributo, informe lo que informe, así que no se les aplica ningún umbral. Usa la forma condicional anterior para darles un límite de reserva.

En una regla de repetición, de tasa de cambio, de agregado en ventana o de correlación de área, la condición es un filtro sobre qué eventos cuentan, así que allí se acepta un filtro como !("maint" in attr) («dispositivos que no están en mantenimiento»), con la misma advertencia. El atributo solo contiene números, así que el filtro también es verdadero para un dispositivo cuyo indicador maint se definió como booleano o como cadena, o con ámbito de cliente.

Acciones automatizadas

Cuando una regla se dispara, se ejecutan sus acciones. Las acciones integradas son:

• Levantar alarma: abre (o escala) una alarma con estado para el dispositivo, descrita más abajo. Es el tipo con el que empieza una acción nueva, tanto en el generador de formularios como en el lienzo, y no necesita más objetivo que una severidad. Una regla sin acciones no levanta ninguna alarma; solo emite una detección a la que puedes suscribirte.
• Enviar comando: encola un comando de vuelta al dispositivo a través del pipeline persistente de comandos. El despacho es idempotente, de modo que un reprocesamiento o reintento nunca envía dos veces.
• Llamar a un webhook (httpCall): hace POST de un payload con forma CEL a un endpoint HTTP externo, con entrega endurecida (se rechazan las redirecciones, se eliminan los encabezados reservados) y autenticación opcional vía el almacén de secretos.
• Publicar a un conector (publish): entrega un payload con forma CEL a un conector saliente que lo distribuye a un broker de mensajes o una cola en la nube (MQTT, Kafka, AWS SNS/SQS).

Las dos acciones salientes, httpCall y publish, se describen en Conectores salientes. Las entrega un servicio separado, así que un sistema externo lento nunca ralentiza la detección.

Una regla puede llevar varias acciones, hasta un pequeño límite fijo. Una regla de correlación de área no lleva ninguna: su disparo pertenece a un área, no a un dispositivo, y toda acción apunta a un dispositivo. Cada acción puede estar protegida por una guarda, una condición sobre el disparo. Por ejemplo, una regla puede levantar una alarma en cada disparo pero enviar un comando solo cuando la lectura esté en una banda particular.

Un disparo es activado por flanco: un flanco ascendente cuando la condición empieza a sostenerse y un flanco descendente cuando deja de hacerlo. Por eso una alarma levantada en el flanco ascendente se limpia automáticamente en el flanco descendente. Tú autoras el levantamiento, y la limpieza queda implícita.

Autoría y previsualización de reglas

Autoras las reglas en la consola de tres maneras. Las tres usan el mismo esquema, y el mismo compilador del lado del servidor las valida todas antes de publicar:

• Un generador de formularios: un formulario tipado por tipo de condición, la vía más rápida para una sola regla. A medida que editas, muestra en línea la retroalimentación de tipos y costo del compilador, antes de publicar. Su selector ofrece las cuatro acciones: levantar alarma, enviar comando, llamar a un webhook y publicar en un conector. Un webhook lleva una URL, una plantilla de cuerpo opcional, cabeceras, un identificador de secreto y un tiempo de espera; una acción de publicar lleva un conector elegido entre los que puedes usar, una plantilla de carga y un tiempo de espera. El formulario comprueba mientras escribes los errores evidentes (una URL ausente o que no sea http, una línea de cabecera sin clave, un conector ausente, un tiempo de espera por encima del límite) y la retroalimentación del compilador cubre el resto, incluidas las plantillas de cuerpo y de carga. Un conector que ya no existe se muestra como «no encontrado» en lugar de descartarse. Las guardas se autoran en el lienzo; el formulario las muestra y las conserva al guardar. Una regla creada en el formulario se abre en el lienzo con las mismas acciones, y a la inversa.
• Un lienzo visual de automatización: un grafo de nodos (fuente → condición → ramas opcionales → acciones) para flujos más ricos. El lienzo compila a la misma regla que produciría un formulario; es una superficie de autoría, no un segundo motor. Añade nodos de rama (enrutar un disparo a distintas acciones mediante una guarda) y nodos de cómputo (nombrar un valor derivado reutilizable y referenciarlo en una condición o guarda). Ofrece un nodo para cada tipo de condición.
• Una puerta "Describir" en lenguaje natural: donde el servicio de IA está habilitado, describes la regla con palabras y recibes una candidata redactada para revisarla y publicarla. Se ofrece al crear una regla nueva, y produce una regla en el mismo esquema que producen las otras dos. Consulta Autoría asistida por IA.

Lo más destacado del lienzo es la previsualización contra historial. Ejecutas una regla en borrador sobre el historial de eventos reproducido del perfil y ves los flancos de levantamiento/resolución que habría producido en una ventana elegida, sin publicar nada. Al seleccionar un disparo se superpone sobre el lienzo una traza por nodo que muestra el camino que tomó el evento: qué condición coincidió, qué rama tomó y qué acción se disparó. Edita y vuelve a previsualizar hasta que la regla haga lo que esperas, y luego publícala.

El formulario tiene el mismo panel de previsualización contra historial, sobre la regla tal como el formulario la guardaría. Está disponible cuando la comprobación del compilador pasa, y muestra los flancos de levantamiento y de resolución. No dibuja una traza por nodo, porque el formulario no tiene lienzo donde dibujarla.

Empezar desde un preajuste

Al crear una regla en el formulario, una fila Empezar desde un preajuste ofrece las tres alertas que los operadores piden primero. Elegir una rellena el formulario de debajo. No se guarda nada hasta que crees la regla, y todos los campos siguen siendo editables.

Preajuste	Tipo de regla	Valores rellenados
Dispositivo en silencio	Ausencia	Ventana de silencio 15m, severidad major, clave de alarma device-silent.
Por encima del umbral durante un tiempo	Duración	La condición debe sostenerse 10m, operador >, severidad major, clave de alarma threshold-held. La métrica y el límite los eliges tú, así que el límite empieza vacío.
Batería baja	Duración	Nivel < 20 sostenido 10m, severidad warning, clave de alarma low-battery. La métrica se preselecciona entre las del perfil cuando un nombre parece de batería (battery, batt, soc). Compruébala antes de crear la regla. Si ningún nombre coincide, el campo queda vacío.

Conviene tener en cuenta:

• Dispositivo en silencio abarca todos los dispositivos del perfil. Una regla de ausencia se rige por la lista de dispositivos del perfil, así que no puede limitarse a un grupo. Para una alarma de desconexión basada en la señal de presencia de un broker y no en el silencio de datos, usa el tipo conectividad.
• Batería baja puede oscilar en el límite. La regla espera a que el nivel se mantenga bajo antes de levantarse, pero se resuelve en cuanto el nivel vuelve a superar el límite. Un nivel que oscile en el límite puede levantarla y resolverla repetidamente.
• La previsualización es aproximada. Reproduce hasta 24 horas de historial desde un arranque en frío, así que una ventana de silencio cercana a un día se previsualiza mal.

Debajo de la previsualización, el formulario comprueba si alguien se enteraría de la alarma. Las políticas de notificación enrutan por severidad, no por regla, así que la comprobación responde algo más acotado que "¿notificará esta regla a alguien?": ¿hay alguna política habilitada que envíe las alarmas de la severidad de esta regla por un canal que exista y esté habilitado? Si no, Crear una política añade una en el momento. Eliges un canal de entrega (y, para correo, los destinatarios), y la nueva política envía todas las alarmas de esa severidad del tenant, de cualquier regla. Antes necesitas un canal de entrega; consulta canales de notificación.

El ciclo de vida de la alarma

Una alarma levantada es un objeto con estado, no un mensaje único. Su estado combina dos ejes en un modelo de cuatro estados:

• Estado: ACTIVE mientras la condición se sostiene, CLEARED una vez que se resuelve.
• Reconocida (Acknowledged): si un operador ha tomado posesión de la alarma, con un registro de quién y cuándo.

Una alarma pasa por ACTIVE/no reconocida → ACTIVE/reconocida → CLEARED. Una condición intermitente reactiva la misma alarma en lugar de generar duplicados.

Una alarma nombra el dispositivo que la levantó. Consultas las alarmas a nivel de todo el inquilino con filtros (estado, severidad, reconocimiento, dispositivo de origen) en lugar de leerlas desde una entidad superior.

Severidad y escalamiento

Cada alarma lleva una severidad: CRITICAL, MAJOR, MINOR, WARNING o INDETERMINATE. Una sola condición puede declarar reglas en varios niveles de severidad (por ejemplo temp > 80 → MAJOR, temp > 100 → CRITICAL). Cuando esas reglas levantan bajo la misma clave de alarma, el motor escala en el mismo lugar una única alarma activa hasta el nivel más alto que se cumple en ese momento, y la desescala a medida que las condiciones ceden, en lugar de abrir una alarma separada por nivel. Una acción de levantar alarma sin clave de alarma usa como clave la propia regla (sus tokens de perfil y de regla), así que las reglas que se dejan con ese valor por defecto abren alarmas separadas.

Llegar a una persona

Una alarma levantada puede notificar a las personas a través del sistema de notificaciones. Una política por inquilino enruta las alarmas a canales de correo electrónico (SMTP) y webhook con enrutamiento por severidad: cada regla de la política asigna una severidad (o cualquiera) a un canal y a una lista de destinatarios.

El escalamiento es por política, no por severidad. La política fija un único intervalo y un único tope. Una alarma que no se reconoce ni se limpia se vuelve a notificar por los mismos canales según ese calendario hasta alcanzar el tope. Una alarma lleva un solo reloj y un solo nivel de escalamiento por muchas políticas que la abarquen, así que el intervalo más corto entre ellas marca el ritmo de todas. No puedes darle a una severidad una cadencia propia.

Las políticas admiten además limitación de tasa: un intervalo mínimo entre notificaciones de la misma alarma, para que una alarma que señaliza repetidamente no inunde un canal.

Cuando dos políticas enrutan al mismo canal y a una lista de destinatarios idéntica, la entrega duplicada se colapsa y la notificación se envía una sola vez. Los mismos destinatarios en otro orden, o con otras mayúsculas y minúsculas, se tratan como distintos, y se envían ambas.

Las credenciales de canal (la contraseña SMTP, un token portador de webhook) se guardan en el almacén de secretos cifrado de la plataforma. Se sellan en reposo con cifrado envolvente, son de solo escritura a través de la API y nunca se devuelven en texto claro.

Esta vía de máquina a humano se mantiene distinta de los conectores salientes de máquina a máquina que distribuyen eventos a otros sistemas.

Ver alarmas y la salud de las reglas

Las alarmas aparecen en vivo en dos lugares sin cableado adicional:

• La vista Alarmas de la consola: una lista en vivo, a nivel de todo el inquilino, filtrable y reconocible en el mismo lugar, con un botón Exportar CSV que guarda todas las alarmas que cumplen el filtro actual (hasta 10 000 filas) y no solo la página visible.
• Widgets de panel: un widget de tabla de alarmas en vivo y un widget de conteo de alarmas (consulta Paneles), con acciones de reconocer/limpiar que el servidor autoriza contra los propios derechos del operador.

El botón Exportar CSV no es exclusivo de las alarmas. También lo tienen la lista Dispositivos de la consola (todos los dispositivos), la página Auditoría del inquilino y Administración → Auditoría, y también la página de detalle de un lote de comandos. Cada exportación está limitada a 10 000 filas. Como el nombre de un dispositivo, la clave de una alarma o el actor de una auditoría pueden haber sido definidos por alguien distinto de quien abre el archivo, toda celda de texto que empieza por =, +, -, @, un tabulador o un retorno de carro se escribe con un ' inicial, de modo que la hoja de cálculo la muestra como texto en lugar de ejecutarla como una fórmula. Una celda que es solo un número simple, como -12.5, se deja tal cual.

Ambos se alimentan de suscripciones en vivo, de modo que los cambios de estado aparecen a medida que ocurren.

El propio editor de un perfil también muestra la salud de las reglas (estado por regla, hora del último disparo y conteo de disparos) junto a un feed en vivo de detecciones a medida que ocurren. Puedes confirmar que una regla recién publicada se comporta bien antes de que llegue a levantar una alarma.

Cómo se opera el servicio

El servicio que evalúa las reglas mantiene estado vivo en memoria y detecta desde una única instancia activa; las réplicas adicionales quedan en espera. Eso le da algunas propiedades operativas que conviene conocer antes de depender de él en producción: qué cuesta un reinicio, con qué rapidez puede dispararse una regla de silencio, por qué una alarma podría no limpiarse y cómo encontrar una regla que está fallando al evaluarse. Cómo operar el motor de detección las cubre.