Monitorare e ridurre la limitazione della latenza in Azure Time Series Insights Gen1
Nota
Il servizio Time Series Insights (TSI) non sarà più supportato dopo marzo 2025. Prendere in considerazione la migrazione degli ambienti TSI esistenti alle soluzioni alternative non appena possibile. Per altre informazioni sulla deprecazione e la migrazione, visitare la documentazione.
Attenzione
È un articolo di Gen1.
Quando la quantità di dati in ingresso è superiore alla configurazione dell'ambiente, in Azure Time Series Insights si può verificare una latenza o una limitazione.
È possibile evitare la latenza o la limitazione configurando l'ambiente in modo appropriato per la quantità di dati che si vuole analizzare.
È molto probabile riscontrare latenza o limitazione nei casi seguenti:
- Aggiungere un'origine evento che contiene dati obsoleti che potrebbero superare la frequenza di ingresso assegnata (Azure Time Series Insights dovrà recuperare).
- Aggiunta di più origini eventi a un ambiente con conseguente picco a causa degli eventi aggiuntivi, che potrebbero superare la capacità dell'ambiente.
- Eseguire il push di grandi quantità di eventi cronologici in un'origine evento, causando un ritardo (Azure Time Series Insights sarà necessario recuperare).
- Aggiunta di dati di riferimento alla telemetria, che determina un aumento delle dimensioni degli eventi. La dimensione massima consentita dei pacchetti è 32 KB; i pacchetti di dati maggiori di 32 KB vengono troncati.
Video
Informazioni sul comportamento di ingresso dei dati Azure Time Series Insights e su come pianificarlo.
Monitorare la latenza e la limitazione con avvisi
Gli avvisi consentono di diagnosticare e mitigare i problemi di latenza che si verificano nell'ambiente.
Nella portale di Azure selezionare l'ambiente Azure Time Series Insights. Selezionare Quindi Avvisi.
Selezionare + Nuova regola di avviso. Verrà quindi visualizzato il pannello Crea regola . Selezionare Aggiungi in CONDIZIONE.
Configurare quindi le condizioni esatte per la logica del segnale.
Da qui è possibile configurare gli avvisi usando alcune delle condizioni seguenti:
Metrica Descrizione Ingress Received Bytes (Byte ricevuti in ingresso) Numero di byte non elaborati letti dalle origini eventi. Include in genere il nome e il valore delle proprietà. Ingress Received Invalid Messages (Messaggi non validi ricevuti in ingresso) Numero dei messaggi non validi letti da tutte le origini eventi di Hub eventi di Azure o Hub IoT di Azure. Ingress Received Messages (Messaggi ricevuti in ingresso) Numero dei messaggi letti da tutte le origini eventi di hub eventi o hub IoT. Ingress Stored Bytes (Byte archiviati in ingresso) Dimensioni totali degli eventi archiviati e disponibili per le query. Le dimensioni sono calcolate solo sul valore delle proprietà. Ingress Stored Events (Eventi archiviati in ingresso) Numero di eventi bidimensionali archiviati e disponibili per le query. Ingress Received Message Time Lag (Tempo di ritardo messaggi ricevuti in ingresso) Differenza in secondi tra l'ora in cui il messaggio viene accodato nell'origine eventi e l'ora di elaborazione in ingresso. Ingress Received Message Count Lag (Ritardo numero di messaggi ricevuti in ingresso) Differenza tra il numero di sequenza dell'ultimo messaggio accodato nella partizione di origine eventi e il numero di sequenza del messaggio elaborato in ingresso. Selezionare Fine.
Dopo aver configurato la logica di segnale desiderata, esaminare visivamente la regola di avviso scelta.
Limitazione e gestione degli accessi
Se si è limitati, verrà registrato un valore per il ritardo dei messaggi ricevuti in ingresso che informa il numero di secondi dietro l'ambiente Azure Time Series Insights dall'ora effettiva in cui il messaggio raggiunge l'origine evento (escluso il tempo di indicizzazione dell'appx. 30-60 secondi).
Anche per Ingress Received Message Count Lag (Differenza numero messaggi ricevuti in ingresso) deve essere disponibile un valore, che consente di determinare di quanti messaggi si è in ritardo. Il modo più semplice per mettersi in pari consiste nell'aumentare la capacità dell'ambiente fino a dimensioni che consentono di recuperare la differenza.
Ad esempio, se l'ambiente S1 dimostra il ritardo di 5.000.000 messaggi, è possibile aumentare le dimensioni dell'ambiente a sei unità per circa un giorno. È possibile aumentare ulteriormente per recuperare più velocemente. Il periodo di recupero è una situazione comune durante il provisioning iniziale di un ambiente, in particolare quando lo si connette a un'origine eventi che già include eventi oppure quando si esegue un caricamento in blocco di molti dati cronologici.
Un'altra tecnica consiste nell'impostare un avviso >Eventi archiviati in ingresso = una soglia leggermente inferiore alla capacità totale dell'ambiente per un periodo di 2 ore. Questo avviso consentirà di comprendere se si raggiunge costantemente la capacità e la probabilità di latenza è quindi elevata.
Ad esempio, se si dispone di tre unità S1 con provisioning (o 2100 eventi al minuto di capacità in ingresso), è possibile impostare un avviso Eventi archiviati in ingresso per = 1900 eventi per >2 ore. Se si supera costantemente questa soglia attivando così l'avviso, è probabile che il provisioning sia insufficiente.
Se si sospetta la limitazione, è possibile confrontare i messaggi in ingresso ricevuti con i messaggi in uscita dell'origine eventi. Se l'ingresso nell'hub eventi è maggiore dei messaggi ricevuti in ingresso, è probabile che la Azure Time Series Insights venga limitata.
Miglioramento delle prestazioni
Per ridurre la limitazione o i casi di latenza, la correzione migliore consiste nell'aumentare la capacità dell'ambiente.
È possibile evitare la latenza o la limitazione configurando l'ambiente in modo appropriato per la quantità di dati che si vuole analizzare. Per altre informazioni su come aggiungere capacità all'ambiente, vedere Ridimensionare l'ambiente.