Fonti di eventi di Azure Time Series Insights Gen2
Nota
Il servizio Time Series Insights verrà ritirato il 7 luglio 2024. Valutare la possibilità di eseguire la migrazione di ambienti esistenti a soluzioni alternative il prima possibile. Per ulteriori informazioni sulla deprecazione e la migrazione, consultare la documentazione .
L'ambiente Azure Time Series Insights Gen2 può avere fino a due origini eventi di streaming. Due tipi di risorse di Azure sono supportati come input:
Gli eventi devono essere inviati come JSON con codifica UTF-8.
Creare o modificare origini eventi
L'origine evento è il collegamento tra l'hub e l'ambiente Azure Time Series Insights Gen2 e viene creata una risorsa separata di tipo Time Series Insights event source nel gruppo di risorse. Le risorse dell'hub IoT o dell'hub eventi possono trovarsi nella stessa sottoscrizione di Azure dell'ambiente Azure Time Series Insights Gen2 o in una sottoscrizione diversa. Tuttavia, è consigliabile ospitare l'ambiente Azure Time Series Insights e l'hub IoT o l'hub eventi all'interno della stessa area di Azure.
Puoi utilizzare il portale di Azure , l'interfaccia a riga di comando di Azure , i modelli di Azure Resource Manager e l'API REST per creare, modificare o rimuovere le origini eventi dell'ambiente.
Avvertimento
Non limitare l'accesso a Internet pubblico a un hub o a un'origine evento usata da Time Series Insights o la connessione necessaria verrà interrotta.
Opzioni di avvio
Quando si crea un'origine evento, è possibile specificare quali dati preesistenti devono essere raccolti. Questa impostazione è facoltativa. Sono disponibili le opzioni seguenti:
| Nome | Descrizione | Esempio di modello di Azure Resource Manager |
|---|---|---|
| Prima disponibilità | Inserire tutti i dati preesistenti archiviati all'interno dell'IoT o dell'Event Hub | "ingressStartAt": {"type": "EarliestAvailable"} |
| EventSourceCreationTime | Iniziare a inserire i dati che arrivano dopo la creazione dell'origine dell'evento. Tutti i dati preesistenti trasmessi prima della creazione della sorgente dell'evento verranno ignorati. Questa è l'impostazione predefinita nel portale di Azure | "ingressStartAt": {"type": "EventSourceCreationTime"} |
| CustomEnqueuedTime | L'ambiente acquisirà i dati dall'orario di accodamento personalizzato (UTC) in avanti. Tutti gli eventi accodati nel tuo hub IoT o eventi a partire dall'orario di accodamento personalizzato verranno acquisiti e archiviati. Tutti gli eventi arrivati prima dell'ora di inserimento personalizzata verranno ignorati. Si noti che "ora accodata" fa riferimento all'ora (in formato UTC) in cui l'evento è arrivato nell'hub eventi o IoT. Ciò differisce da una proprietà timestamp personalizzata che si trova nel corpo dell'evento. | "ingressStartAt": {"type": "CustomEnqueuedTime", "time": "2021-03-01T17:00:00.20Z"} |
Importante
- Se si seleziona Prima disponibilità e si dispone di molti dati preesistenti, si potrebbe verificare una latenza iniziale elevata quando l'ambiente Azure Time Series Insights Gen2 elabora tutti i dati.
- Questa latenza elevata dovrebbe infine ridursi man mano che i dati vengono indicizzati. Inviare un ticket di supporto tramite il portale di Azure se si verifica una latenza elevata in corso.
- Prima disponibilità
- EventSourceCreationTime
- CustomEnqueuedTime
Pratiche consigliate per l'inserimento in streaming
Creare sempre un gruppo di consumatori univoco per l'ambiente Azure Time Series Insights Gen2 per consumare i dati dall'origine evento. Il riutilizzo dei gruppi di consumer può causare disconnessioni casuali e può comportare la perdita di dati.
Configurare l'ambiente Azure Time Series Insights Gen2 e l'hub IoT e/o hub eventi nella stessa area di Azure. Sebbene sia possibile configurare un'origine evento in un'area separata, questo scenario non è supportato e non è possibile garantire la disponibilità elevata.
Non superare il limite di velocità di throughput dell'ambiente o il limite per partizione.
Configurare un avviso di ritardo per ricevere una notifica se l'ambiente riscontra problemi durante l'elaborazione dei dati. Vedere Carichi di lavoro di produzione di seguito per le condizioni di allerta suggerite.
Utilizzare l'inserimento in streaming solo per dati quasi in tempo reale e recenti; lo streaming di dati cronologici non è supportato.
Comprendere in che modo le proprietà verranno precedute da escape e JSON dati appiattiti e archiviati.
Seguire il principio dei privilegi minimi quando si forniscono stringhe di connessione all'origine evento. Per Hub eventi, configurare un criterio di accesso condiviso con l'attestazione di invio
solo e per l'hub IoT usare solo l'autorizzazione servizio di connessione .
Attenzione
Se si elimina l'hub IoT o l'hub eventi e si ricrea una nuova risorsa con lo stesso nome, è necessario creare una nuova origine evento e collegare il nuovo hub IoT o l'hub eventi. I dati non verranno inseriti finché non si completa questo passaggio.
Carichi di lavoro di produzione
Oltre alle procedure consigliate descritte in precedenza, è consigliabile implementare quanto segue per i carichi di lavoro business critical.
Aumentare il tempo di conservazione dei dati dell'hub IoT o dell'hub eventi al massimo di sette giorni.
Creare avvisi di ambiente nel portale di Azure. Gli avvisi basati sulle metriche della piattaforma consentono di convalidare il comportamento della pipeline end-to-end. Le istruzioni su come creare e gestire gli avvisi sono qui. Condizioni di avviso suggerite:
- IngressReceivedMessagesTimeLag è maggiore di 5 minuti
- IngressReceivedBytes è 0
Mantieni il carico di input bilanciato tra le partizioni dell'hub IoT o dell'hub eventi.
Inserimento dati cronologici
L'uso della pipeline di streaming per importare dati cronologici non è attualmente supportato in Azure Time Series Insights Gen2. Se è necessario importare dati passati nell'ambiente, seguire le linee guida seguenti:
- Non trasmettere dati live e cronologici in parallelo. L'inserimento di dati non in ordine comporterà una riduzione delle prestazioni delle query.
- Inserire i dati cronologici in modo ordinato nel tempo per ottenere prestazioni ottimali.
- Attenersi ai seguenti limiti di velocità di inserimento.
- Disabilitare l'archivio temporaneo se i dati sono superiori al periodo di conservazione dell'archivio temporaneo.
Timestamp dell'origine dell'evento
Quando si configura un'origine evento, verrà chiesto di specificare una proprietà ID timestamp. La proprietà timestamp viene usata per tenere traccia degli eventi nel tempo, ovvero il tempo che verrà usato come timestamp $ts nelle API di query e per tracciare le serie in Azure Time Series Insights Explorer. Se non viene specificata alcuna proprietà al momento della creazione o se la proprietà timestamp non è presente in un evento, verrà utilizzato il tempo di accodamento dell'hub IoT o dell'Event Hubs dell'evento come impostazione predefinita. I valori delle proprietà Timestamp vengono archiviati in formato UTC.
In generale, gli utenti opteranno per personalizzare la proprietà timestamp e useranno l'ora in cui il sensore o il tag ha generato la lettura anziché usare l'ora di accodamento dell'hub predefinita. Ciò è particolarmente necessario quando i dispositivi hanno una perdita di connettività intermittente e un batch di messaggi ritardati viene inoltrato ad Azure Time Series Insights Gen2.
Se il tuo timestamp personalizzato si trova all'interno di un oggetto JSON annidato o di un array, dovrai fornire il nome corretto della proprietà seguendo le convenzioni di denominazione di appiattimento ed escape e. Ad esempio, il timestamp dell'origine evento per il payload JSON illustrato qui deve essere inserito come "values.time".
Offset del fuso orario
I timestamp devono essere inviati in formato ISO 8601 e verranno archiviati in formato UTC. Se viene specificata una differenza di fuso orario, l'offset verrà applicato e quindi l'ora archiviata e restituita in formato UTC. Se l'offset è formattato in modo non corretto, verrà ignorato. Nelle situazioni in cui la tua soluzione potrebbe non avere il contesto dell'offset originale, puoi inviare i dati di offset in una proprietà aggiuntiva separata dell'evento per assicurarti che venga mantenuta e che l'applicazione possa fare riferimento ad essa in una risposta a una query.
L'offset del fuso orario deve essere formattato come uno dei seguenti:
±HHMMZ
±HH:MM
±HH:MMZ
Passaggi successivi
Leggere il JSON Flattening and Escaping Rules per comprendere come verranno archiviati gli eventi.
Comprendere le limitazioni della capacità di elaborazione dell'ambiente