Compartilhar via


Origens de evento do Azure Time Series Insights Gen2

Observação

O serviço Time Series Insights será desativado em 7 de julho de 2024. Considere migrar ambientes existentes para soluções alternativas o mais rápido possível. Para obter mais informações sobre a substituição e a migração, visite nossa documentação.

O ambiente do Azure Time Series Insights Gen2 pode ter até duas origens de eventos de streaming. Há suporte para dois tipos de recursos do Azure como entradas:

Os eventos devem ser enviados como JSON codificado em UTF-8.

Criar ou editar origens de evento

A origem do evento é o link entre o hub e o ambiente do Azure Time Series Insights Gen2, e um recurso separado do tipo Time Series Insights event source é criado no grupo de recursos. O Hub IoT ou os recursos do Hub de Eventos podem residir na mesma assinatura do Azure que o ambiente do Azure Time Series Insights Gen2 ou em uma assinatura diferente. No entanto, é uma prática recomendada alojar o ambiente do Azure Time Series Insights e o Hub IoT ou Hub de Eventos na mesma região do Azure.

Você pode usar o portal do Azure, a CLI do Azure, modelos do Azure Resource Manager e a API REST para criar, editar ou remover as origens de evento do ambiente.

Aviso

Não restrinja o acesso público à internet a um hub ou origem de evento usado pelo Time Series Insights, caso contrário, a conexão necessária será interrompida.

Opções de inicialização

Ao criar uma origem de evento, você pode especificar quais dados preexistentes devem ser coletados. Esta configuração é opcional. As opções a seguir estão disponíveis:

Nome Descrição Exemplo de modelo do Azure Resource Manager
EarliestAvailable Ingerir todos os dados preexistentes armazenados no IoT ou Hub de Eventos "ingressStartAt": {"type": "EarliestAvailable"}
EventSourceCreationTime Começar a ingerir os dados que chegam depois da criação da origem do evento. Os dados preexistentes transmitidos antes da criação da origem do evento serão ignorados. Essa é a configuração padrão no portal do Azure "ingressStartAt": {"type": "EventSourceCreationTime"}
CustomEnqueuedTime O ambiente ingerirá dados a partir do horário de enfileiramento personalizado (UTC). Todos os eventos que foram enfileirados no IoT ou Hub de Eventos no horário do enfileiramento personalizado ou depois dele serão ingeridos e armazenados. Todos os eventos que chegaram antes do horário de enfileiramento personalizado serão ignorados. Observe que "tempo de enfileiramento" é o horário (em UTC) quando o evento chegou ao IoT ou Hub de Eventos. Isso é diferente de uma propriedade de carimbo de data/hora personalizada que esteja dentro do corpo do evento. "ingressStartAt": {"type": "CustomEnqueuedTime", "time": "2021-03-01T17:00:00.20Z"}

Importante

  • Caso você selecione EarliestAvailable e haja muitos dados preexistentes, talvez haja alta latência inicial, pois o ambiente do Azure Time Series Insights Gen2 processa todos os dados.
  • Essa alta latência acaba diminuindo conforme os dados são indexados. Envie um tíquete de suporte pelo portal do Azure se você tiver uma alta latência contínua.
  • EarliestAvailable

Diagrama de EarliestAvailable

  • EventSourceCreationTime

Diagrama de EventSourceCreationTime

  • CustomEnqueuedTime

Diagrama de CustomEnqueuedTime

Melhores práticas de ingestão de streaming

  • Sempre crie um grupo de consumidores exclusivo para o ambiente do Azure Time Series Insights Gen2 para consumir dados da origem do evento. A reutilização de grupos de consumidores pode causar desconexões aleatórias e resultar em perda de dados.

  • Configure o ambiente do Azure Time Series Insights Gen2 e o Hub IoT e/ou Hubs de Eventos na mesma região do Azure. Embora seja possível configurar uma origem de evento em uma região separada, esse cenário não tem suporte e não podemos garantir a alta disponibilidade.

  • Não ultrapasse o limite de taxa de transferência do seu ambiente ou por limite de partição.

  • Configure um alerta de latência para receber uma notificação caso o seu ambiente enfrente problemas de processamento de dados. Veja as condições de alerta sugeridas em Cargas de trabalho de produção abaixo.

  • Use a ingestão de streaming somente para dados quase em tempo real e recentes, não há suporte para streaming de dados históricos.

  • Entenda como as propriedades são escapadas e como dados JSON são nivelados e armazenados.

  • Siga o princípio de privilégios mínimos ao fornecer cadeias de conexão de origem de evento. Para os Hubs de Eventos, configure uma política de acesso compartilhado somente com a declaração enviar e, para o Hub IoT, use somente a permissão de conexão de serviço.

Cuidado

Se você excluir o Hub IoT ou o Hub de Eventos e recriar um recurso com o mesmo nome, será necessário criar uma origem do evento e anexar o novo Hub IoT ou Hub de Eventos. Os dados não serão ingeridos até que você conclua essa etapa.

Cargas de trabalho de produção

Além das práticas recomendadas acima, recomendamos que você implemente o seguinte para cargas de trabalho comercialmente críticas.

  • Aumente o tempo de retenção de dados do Hub IoT ou Hub de Eventos para o máximo de sete dias.

  • Crie alertas de ambiente no portal do Azure. Os alertas baseados em métricas de plataforma permitem validar o comportamento do pipeline de ponta a ponta. As instruções para criar e gerenciar alertas estão aqui. Condições de alerta sugeridas:

    • IngressReceivedMessagesTimeLag é maior que 5 minutos
    • IngressReceivedBytes é 0
  • Mantenha a carga de ingestão equilibrada entre as partições do Hub IoT ou do Hub de Eventos.

Ingestão de dados históricos

No momento, o uso do pipeline de streaming para importar dados históricos não tem suporte no Azure Time Series Insights Gen2. Se você precisar importar dados passados para o seu ambiente, siga as diretrizes abaixo:

  • Não transmita dados dinâmicos e históricos em paralelo. A ingestão de dados fora de ordem resultará em um desempenho de consulta degradado.
  • Ingira dados históricos ordenados por tempo para obter um melhor desempenho.
  • Fique dentro dos limites da taxa de transferência de ingestão abaixo.
  • Desabilite o Armazenamento Warm se os dados forem mais antigos do que o período de retenção do Armazenamento Warm.

Carimbo de data/hora de origens de evento

Ao configurar uma origem de evento, você deve informar uma propriedade de ID de carimbo de data/hora. A propriedade do carimbo de data/hora é usada para acompanhar eventos ao longo do tempo. Essa é a hora que será usada como carimbo de data/hora $ts nas APIs de consulta e na série de plotagem no Gerenciador do Azure Time Series Insights. Se a propriedade do carimbo de data/hora não for informada no momento da criação ou estiver faltando em um evento, a hora de enfileiramento do Hub IoT ou dos Hubs de Evento será usada como padrão. Os valores da propriedade de carimbo de data/hora são armazenados em UTC.

Em geral, os usuários optam por personalizar a propriedade de carimbo de data/hora e usar a hora em que o sensor ou a marca gerou a leitura, em vez de usar o padrão da hora de enfileiramento do hub. Isso é particularmente necessário quando os dispositivos têm perda de conectividade intermitente e um lote de mensagens atrasadas é encaminhado para o Azure Time Series Insights Gen2.

Se o carimbo de data/hora personalizado estiver dentro de um objeto JSON aninhado ou de uma matriz, você precisará informar o nome correto da propriedade seguindo as convenções de nomenclatura de nivelamento e de escape. Por exemplo, o carimbo de data/hora de origem de evento do conteúdo JSON mostrado aqui deve ser inserido como "values.time".

Deslocamentos de fuso horário

Os carimbos de data/hora devem ser enviados no formato ISO 8601 e são armazenados em UTC. Se um deslocamento de fuso horário for fornecido, ele será aplicado, e o horário será armazenado e retornado no formato UTC. Se a formatação do deslocamento estiver incorreta, ele será ignorado. Em situações em que a solução não tem o contexto do deslocamento original, você pode enviar os dados de deslocamento em outra propriedade de evento separada a fim de preservar o deslocamento e garantir que o aplicativo possa fazer referência a ele ao responder consultas.

O deslocamento de fuso horário deve ter uma destas formatações:

±HHMMZ
±HH:MM
±HH:MMZ

Próximas etapas