Orígenes de eventos de Azure Time Series Insights Gen2

El entorno de Azure Time Series Insights 2 puede tener hasta dos orígenes de eventos de streaming. Se admiten dos tipos de recursos de Azure como entradas:

• Azure IoT Hub
• Azure Event Hubs

Los eventos se deben enviar como JSON con codificación UTF8.

Crear o editar orígenes de eventos

El origen del evento es el vínculo entre el centro y el entorno de Azure Time Series Insights Gen2, y se crea un recurso de tipo independiente Time Series Insights event source en el grupo de recursos. Los recursos de IoT Hub o del Centro de eventos pueden residir en la misma suscripción de Azure que el entorno de Azure Time Series Insights Gen2 o una suscripción diferente. Sin embargo, es un procedimiento recomendado hospedar el entorno de Azure Time Series Insights y la instancia de IoT Hub o el Centro de eventos en la misma región de Azure.

Puede usar Azure Portal, la CLI de Azure, las plantillas de Azure Resource Manager y la API de REST para crear, editar o quitar los orígenes de eventos del entorno.

Opciones de inicio

Al crear un origen de eventos, puede especificar qué datos preexistentes se deben recopilar. Esta configuración es opcional. Las siguientes opciones están disponibles:

• EarliestAvailable

• Hora de Creación de la Fuente del Evento

• CustomEnqueuedTime

Procedimientos recomendados para la ingesta de streaming

• Cree siempre un grupo de consumidores exclusivo para que el entorno de Azure Time Series Insights Gen2 pueda obtener datos de su origen de eventos. La reutilización de grupos de consumidores puede provocar desconexiones aleatorias y provocar la pérdida de datos.

• Configure el entorno de Azure Time Series Insights Gen2 e IoT Hub o Event Hubs en la misma región de Azure. Aunque es posible configurar un origen de eventos en una región independiente, este escenario no es compatible y no podemos garantizar una alta disponibilidad.

• No exceda el límite de velocidad de rendimiento para su entorno o por límite de partición.

• Configure una alerta de retraso para recibir una notificación si el entorno está experimentando problemas al procesar datos. Consulte Cargas de trabajo de producción a continuación para ver las condiciones de alerta sugeridas.

• Utiliza la ingesta de streaming solo para datos recientes y casi en tiempo real; no está admitido el procesamiento de datos históricos por streaming.

• Comprenda cómo se aplicarán las secuencias de escape a las propiedades y los datos de JSON se acoplarán y almacenarán.

• Siga el principio de privilegio mínimo al proporcionar cadenas de conexión para la fuente del evento. Para los centros de eventos, configure una directiva de acceso compartido solo con la notificación de envío y, para IoT Hub, use solo el permiso de conexión de servicio.

Cargas de trabajo de producción

Además de los procedimientos recomendados anteriores, se aconseja implementar lo siguiente con las cargas de trabajo críticas para la empresa.

• Aumente el tiempo de retención de datos de IoT Hub o del Centro de eventos hasta 7 días.

• Cree alertas de entorno en Azure Portal. Las alertas basadas en métricas de la plataforma permiten validar el comportamiento de la canalización de un extremo a otro. Las instrucciones para crear y administrar alertas se encuentran aquí. Condiciones de alerta sugeridas:

  • El retraso en la recepción de mensajes ingresados es mayor que 5 minutos
  • IngressReceivedBytes es 0

• Mantenga la carga de ingestión equilibrada entre las particiones de IoT Hub o Event Hub.

Ingesta de datos históricos

Actualmente no se admite el uso de la canalización de streaming para importar datos históricos en Azure Time Series Insights Gen2. Si necesita importar datos pasados a su entorno, siga estas instrucciones:

• No transmita datos en directo e históricos en paralelo. La ingesta de datos desordenados provocará un rendimiento degradado de las consultas.
• Para obtener el mejor rendimiento, ingiera los datos históricos de manera ordenada en el tiempo.
• Manténgase dentro de los límites de rendimiento de ingesta que se indican a continuación.
• Deshabilite Warm Store si los datos son más antiguos que el período de retención de Warm Store.

Marca de tiempo de origen del evento

Al configurar un origen de eventos, se le pedirá que proporcione una propiedad de ID de marca de tiempo. La propiedad de marca de tiempo se usa para seguir eventos a lo largo del tiempo; este es el tiempo que se usará como la marca de tiempo $ts en las API de consulta y para la serie de gráficos en el Explorador de Azure Time Series Insights. Si no se proporciona una propiedad en el momento de la creación, o si la propiedad de marca de tiempo falta en un evento, entonces se utilizará como predeterminado el momento en que el evento fue encolado en IoT Hub o Event Hubs. Los valores de propiedad de marca de tiempo se almacenan en UTC.

Por lo general, los usuarios optarán por personalizar el atributo de marca de tiempo y usar el momento en que el sensor o la etiqueta generaron la lectura, en lugar de usar el tiempo de encolado predeterminado del hub. Esto es particularmente necesario cuando los dispositivos experimentan una pérdida intermitente de conectividad y un lote de mensajes retrasados se reenvía a Azure Time Series Insights Gen2.

Si la marca de tiempo personalizada está dentro de un objeto JSON anidado o una matriz, deberá proporcionar el nombre de propiedad correcto siguiendo nuestras convenciones de nomenclatura de aplanamiento y escape. Por ejemplo, la marca de tiempo de origen del evento para la carga de JSON que se muestra aquí debe introducirse como "values.time".

Desplazamiento de zona horaria

Las marcas de tiempo deben enviarse en formato ISO 8601 y se almacenarán en UTC. Si se proporciona un desplazamiento de zona horaria, se aplica el desplazamiento y, luego, la hora se almacena y se devuelve en formato UTC. Si el desplazamiento tiene un formato incorrecto, se ignorará. En situaciones en las que la solución puede no tener el contexto del desplazamiento original, puede enviar los datos del desplazamiento en una propiedad de evento adicional separada para asegurarse de que se conserva y de que su aplicación puede hacer referencia a ella en una respuesta de consulta.

El desplazamiento de zona horaria debe tener el formato de uno de los siguientes:

±HHMMZ
±HH:MM
±HH:MMZ

Pasos siguientes

• Lea las Reglas de aplanamiento y escapado de JSON para comprender cómo se almacenarán los eventos.

• Comprender las limitaciones de rendimiento del entorno