Share via


origens de eventos do Azure Time Series Insights Gen2

Nota

O serviço Time Series Insights (TSI) deixará de ser suportado após março de 2025. Considere migrar ambientes TSI existentes para soluções alternativas o mais rapidamente possível. Para obter mais informações sobre a descontinuação e migração, visite a nossa documentação.

O seu ambiente Azure Time Series Insights Gen2 pode ter até duas origens de eventos de transmissão em fluxo. Dois tipos de recursos do Azure são suportados como entradas:

Os eventos têm de ser enviados como JSON codificado utF-8.

Criar ou editar origens de eventos

A origem do evento é a ligação entre o hub e o ambiente do Azure Time Series Insights Gen2 e é criado um recurso do tipo Time Series Insights event source separado no seu grupo de recursos. Os Hub IoT ou recursos do Hub de Eventos podem residir na mesma subscrição do Azure que o ambiente do Azure Time Series Insights Gen2 ou numa subscrição diferente. No entanto, é uma melhor prática alojar o seu ambiente de Azure Time Series Insights e o Hub IoT ou o Hub de Eventos na mesma região do Azure.

Pode utilizar a portal do Azure, a CLI do Azure, os modelos de Resource Manager do Azure e a API REST para criar, editar ou remover as origens de eventos do seu ambiente.

Aviso

Não restrinja o acesso à Internet Pública a um hub ou origem de eventos utilizado pelo Time Series Insights ou a ligação necessária será interrompida.

Opções de início

Ao criar uma origem de evento, pode especificar que dados pré-existentes devem ser recolhidos. Esta definição é opcional. Estão disponíveis as seguintes opções:

Nome Descrição Exemplo de modelo do Azure Resource Manager
Disponível Mais Cedo Ingerir todos os dados pré-existentes armazenados no IoT ou no Hub de Eventos "ingressStartAt": {"type": "EarliestAvailable"}
EventSourceCreationTime Comece a ingerir dados recebidos após a criação da origem do evento. Todos os dados pré-existentes transmitidos antes da criação da origem do evento serão ignorados. Esta é a predefinição no portal do Azure "ingressStartAt": {"type": "EventSourceCreationTime"}
CustomEnqueuedTime O seu ambiente irá ingerir dados a partir da hora de colocação em fila (UTC) personalizada. Todos os eventos que foram colocados em fila no seu IoT ou Hub de Eventos em ou depois do seu tempo de colocação em fila personalizado serão ingeridos e armazenados. Todos os eventos que chegaram antes do seu tempo de fila personalizado serão ignorados. Tenha em atenção que "tempo em fila" refere-se à hora (em UTC) em que o evento chegou ao seu IoT ou Hub de Eventos. Isto difere de uma propriedade de carimbo de data/ hora personalizada que está no corpo do seu evento. "ingressStartAt": {"type": "CustomEnqueuedTime", "time": "2021-03-01T17:00:00.20Z"}

Importante

  • Se selecionar a opção Disponível Mais Cedo e tiver muitos dados pré-existentes, poderá deparar-se com uma latência inicial elevada à medida que o ambiente do Azure Time Series Insights Gen2 processa todos os seus dados.
  • Esta latência elevada deve eventualmente diminuir à medida que os dados são indexados. Submeta um pedido de suporte através do portal do Azure se ocorrer latência elevada contínua.
  • Disponível Mais Cedo

Diagrama Disponível Mais Antigo

  • EventSourceCreationTime

Diagrama EventSourceCreationTime

  • CustomEnqueuedTime

Diagrama CustomEnqueuedTime

Melhores práticas de ingestão de transmissão em fluxo

  • Crie sempre um grupo de consumidores exclusivo para o seu ambiente Azure Time Series Insights Gen2 consumir dados da sua origem de eventos. Reutilizar grupos de consumidores pode causar interrupções aleatórias e pode resultar na perda de dados.

  • Configure o seu ambiente Azure Time Series Insights Gen2 e os seus Hub IoT e/ou Hubs de Eventos na mesma região do Azure. Embora seja possível configurar uma origem de eventos numa região separada, este cenário não é suportado e não podemos garantir a elevada disponibilidade.

  • Não ultrapasse o limite de taxa de débito do ambiente nem o limite de partições.

  • Configure um alerta de atraso para ser notificado se o seu ambiente estiver a ter problemas no processamento de dados. Veja Cargas de trabalho de produção abaixo para obter as condições de alerta sugeridas.

  • Utilize a ingestão de transmissão em fluxo apenas para dados recentes e quase em tempo real, a transmissão em fluxo de dados históricos não é suportada.

  • Compreender como as propriedades serão escapadas e os dados JSON achatados e armazenados.

  • Siga o princípio do menor privilégio ao fornecer cadeias de ligação de origem de eventos. Para os Hubs de Eventos, configure uma política de acesso partilhado apenas com a afirmação de envio e, para Hub IoT, utilize apenas a permissão de ligação do serviço.

Atenção

Se eliminar o Hub IoT ou o Hub de Eventos e recriar um novo recurso com o mesmo nome, terá de criar uma nova origem de eventos e anexar a nova Hub IoT ou o Hub de Eventos. Os dados não serão ingeridos até concluir este passo.

Cargas de trabalho de produção

Além das melhores práticas acima, recomendamos que implemente o seguinte para cargas de trabalho críticas para a empresa.

  • Aumente o Hub IoT ou o tempo de retenção de dados do 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-lhe validar o comportamento do pipeline ponto a ponto. As instruções para criar e gerir alertas estão aqui. Condições de alerta sugeridas:

    • IngressReceivedMessagesTimeLag é superior a 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

A utilização do pipeline de transmissão em fluxo para importar dados históricos não é atualmente suportada no Azure Time Series Insights Gen2. Se precisar de importar dados passados para o seu ambiente, siga as diretrizes abaixo:

  • Não transmita dados em direto e históricos em paralelo. Ingerir dados fora de ordem resultará num desempenho de consulta degradado.
  • Ingerir dados históricos de forma ordenada pelo tempo para obter o melhor desempenho.
  • Mantenha-se dentro dos limites de taxa de débito de ingestão abaixo.
  • Desative o Arquivo Quente se os dados forem mais antigos do que o período de retenção do Arquivo Quente.

Carimbo de data/hora da origem do evento

Ao configurar uma origem de evento, ser-lhe-á pedido para fornecer uma propriedade de ID de carimbo de data/hora. A propriedade de carimbo de data/hora é utilizada para controlar eventos ao longo do tempo, esta é a hora que será utilizada como carimbo de data$ts/hora nas APIs de Consulta e para desenhar séries no Explorador de Azure Time Series Insights. Se não for fornecida nenhuma propriedade no momento da criação ou se a propriedade de carimbo de data/hora estiver em falta num evento, a Hub IoT do evento ou a hora em fila dos Hubs de Eventos serão utilizadas como predefinição. Os valores das propriedades do carimbo de data/hora são armazenados em UTC.

Em geral, os utilizadores optarão por personalizar a propriedade de carimbo de data/hora e utilizar a hora em que o sensor ou a etiqueta geraram a leitura em vez de utilizar o tempo em fila predefinido do hub. Isto é particularmente necessário quando os dispositivos têm perda de conectividade intermitente e um lote de mensagens atrasadas são reencaminhadas para Azure Time Series Insights Gen2.

Se o carimbo de data/hora personalizado estiver dentro de um objeto JSON aninhado ou de uma matriz, terá de fornecer o nome de propriedade correto seguindo as nossas convenções de nomenclatura de aplanamento e escape. Por exemplo, o carimbo de data/hora da origem do evento para o payload JSON apresentado aqui deve ser introduzido como "values.time".

Desvios de fuso horário

Os carimbos de data/hora têm de ser enviados no formato ISO 8601 e serão armazenados em UTC. Se for fornecido um desvio do fuso horário, o desvio será aplicado e, em seguida, a hora armazenada e devolvida no formato UTC. Se o desvio estiver formatado incorretamente, será ignorado. Em situações em que a sua solução pode não ter contexto do desvio original, pode enviar os dados de deslocamento numa propriedade de evento separada adicional para garantir que é preservada e que a sua aplicação pode fazer referência numa resposta de consulta.

O deslocamento do fuso horário deve ser formatado como um dos seguintes:

±HHMMZ
±HH:MM
±HH:MMZ

Passos seguintes