origini eventi di Azure Time Series Insights Gen2
Nota
Il servizio Time Series Insights (TSI) non sarà più supportato dopo marzo 2025. Valutare la possibilità di eseguire la migrazione di ambienti TSI esistenti a soluzioni alternative il prima possibile. Per altre informazioni sulla deprecazione e la migrazione, vedere la documentazione.
L'ambiente di 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 hub IoT o 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 i modelli di portale di Azure, l'interfaccia della riga di comando di Azure, 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. 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'hub eventi o IoT | "ingressStartAt": {"type": "EarliestAvailable"} |
| EventSourceCreationTime | Iniziare a inserire i dati che arrivano dopo la creazione dell'origine evento. Tutti i dati preesistenti trasmessi prima della creazione dell'origine evento verranno ignorati. Questa è l'impostazione predefinita nel portale di Azure | "ingressStartAt": {"type": "EventSourceCreationTime"} |
| CustomEnqueuedTime | L'ambiente insedierà i dati dall'ora di accodamento (UTC) personalizzata. Tutti gli eventi accodati nell'hub eventi o IoT in corrispondenza o dopo l'accodamento personalizzato verranno inseriti e archiviati. Tutti gli eventi arrivati prima del tempo accodato personalizzato verranno ignorati. Si noti che "ora accodata" si riferisce all'ora (in formato UTC) in cui l'evento è arrivato nell'hub eventi o IoT. Ciò è diverso da una proprietà timestamp personalizzata 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 di Azure Time Series Insights Gen2 per utilizzare i dati dall'origine evento. Il riutilizzo dei gruppi di consumer può causare disconnessioni casuali e può causare la perdita di dati.
Configurare l'ambiente di 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.
Comprendere in che modo le proprietà verranno precedute da escape e i dati JSON vengono bidimensionati e archiviati.
Seguire il principio dei privilegi minimi quando si specificano stringhe di connessione all'origine evento. 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 la nuova hub IoT o 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 di hub IoT o 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 partizioni di hub IoT o 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 dell'origine evento
Quando si configura un'origine evento, viene 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 nel Azure Time Series Insights Explorer. Se non viene specificata alcuna proprietà in fase di creazione o se la proprietà timestamp non è presente in un evento, l'hub IoT ora di accodamento dell'evento verrà usata come valore predefinito. 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 accodata dell'hub predefinito. Ciò è particolarmente necessario quando i dispositivi hanno una perdita di connettività intermittente e un batch di messaggi ritardati viene inoltrato a 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 escaping. Ad esempio, il timestamp dell'origine evento per il payload JSON mostrato qui 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 a una risposta di query.
La differenza di fuso orario deve essere formattata come una delle seguenti:
±HHMMZ
±HH:MM
±HH:MMZ
Passaggi successivi
Leggere le regole json Flattening e Escaping per comprendere come verranno archiviati gli eventi.
Comprendere le limitazioni della velocità effettiva dell'ambiente