Origini 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 altre informazioni sulla deprecazione e la migrazione, visitare 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. La hub IoT o le risorse 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.
È possibile usare le portale di Azure, l'interfaccia della 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.
Avviso
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. Questo impostazione è facoltativa. Sono disponibili le seguenti opzioni:
| Nome | Descrizione | Esempio di modello di Azure Resource Manager |
|---|---|---|
| Prima disponibilità | consente di inserire tutti i dati preesistenti archiviati in IoT o hub eventi | "ingressStartAt": {"type": "EarliestAvailable"} |
| EventSourceCreationTime | consente di iniziare a inserire i dati in arrivo dopo la creazione dell'origine evento. Tutti i dati preesistenti sottoposti a streaming prima della creazione dell'origine evento verranno ignorati. Questa è l'impostazione predefinita nel portale di Azure | "ingressStartAt": {"type": "EventSourceCreationTime"} |
| CustomEnqueuedTime | l'ambiente inserirà i dati a partire dall'ora di accodamento personalizzata (UTC). Tutti gli eventi accodati in IoT o in Hub eventi in corrispondenza o dopo l'ora di accodamento personalizzata verranno inseriti e archiviati. Tutti gli eventi ricevuti prima dell'ora di accodamento 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. Questo comportamento è diverso da una proprietà timestamp personalizzata che si trova all'interno del corpo dell'evento. | "ingressStartAt": {"type": "CustomEnqueuedTime", "time": "2021-03-01T17:00:00.20Z"} |
Importante
- Se si seleziona Meno disponibilità e si dispone di molti dati preesistenti, è possibile che si verifichi 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 con il portale di Azure se si verifica una latenza elevata.
- Prima disponibilità
- EventSourceCreationTime
- CustomEnqueuedTime
Procedure consigliate per l'inserimento in streaming
Creare sempre un gruppo di consumer univoco per l'ambiente Azure Time Series Insights Gen2 per usare i dati dell'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 i 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à effettiva dell'ambiente o per limite di partizione.
Configurare un avviso di ritardo per ricevere una notifica se l'ambiente riscontra problemi durante l'elaborazione dei dati. Per le condizioni di avviso suggerite, vedere Carichi di lavoro di produzione seguenti.
Usare l'inserimento streaming solo per i dati near real-time e recenti. I dati cronologici di streaming non sono supportati.
Informazioni sul modo in cui le proprietà verranno precedute da escape e i dati JSON verranno appiattiti e archiviati.
Seguire il principio dei privilegi minimi quando si forniscono stringa di connessione di origine eventi. Per Hub eventi, configurare un criterio di accesso condiviso solo con l'attestazione di invio e per hub IoT usare solo l'autorizzazione di connessione del servizio.
Attenzione
Se si elimina il hub IoT o l'hub eventi e si ricrea una nuova risorsa con lo stesso nome, è necessario creare una nuova origine evento e allegare 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 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 per la creazione e la gestione degli avvisi sono disponibili qui. Condizioni di avviso suggerite:
- IngressReceivedMessagesTimeLag è maggiore di 5 minuti
- IngressReceivedBytes è 0
Mantenere il carico di inserimento bilanciato tra le hub IoT o le partizioni di Hub eventi.
Inserimento dei dati cronologici
L'uso della pipeline di streaming per importare dati cronologici non è attualmente supportato in Azure Time Series Insights Gen2. Se è necessario importare i dati passati nell'ambiente in uso, seguire le linee guida indicate sotto:
- Non trasmettere dati in tempo reale e cronologici in parallelo. L'inserimento di dati non in ordine comporterà un calo delle prestazioni delle query.
- Inserire i dati cronologici rispettando la sequenza temporale per ottenere prestazioni ottimali.
- Rispettare i limiti di velocità effettiva di inserimento indicati sotto.
- Disabilitare l'archivio ad accesso frequente se i dati sono precedenti al periodo di conservazione dell'archivio ad accesso frequente.
Timestamp origine 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 Esplora Azure Time Series Insights. Se non viene specificata alcuna proprietà in fase di creazione o se la proprietà timestamp non è presente in un evento, l'hub IoT dell'evento o l'ora accodata di Hub eventi verrà usata come 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 timestamp personalizzato si trova all'interno di un oggetto JSON annidato o di una matrice, è necessario specificare il nome della proprietà corretto seguendo le convenzioni di denominazione flat ed escape. Ad esempio, il timestamp dell'origine evento per il payload JSON illustrato di seguito deve essere immesso 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 soluzione potrebbe non avere contesto dell'offset originale, è possibile inviare i dati di offset in una proprietà evento separata aggiuntiva per assicurarsi che venga mantenuta e che l'applicazione possa fare riferimento in una risposta di query.
L'offset del fuso orario deve essere formattato come uno dei seguenti:
±HHMMZ
±HH:MM
±HH:MMZ
Passaggi successivi
Leggere le regole di flating ed escape JSON per comprendere come verranno archiviati gli eventi.
Comprendere le limitazioni della velocità effettiva dell'ambiente