Configurazione dei criteri di ordinamento degli eventi per Analisi di flusso di Azure

Questo articolo descrive come configurare e utilizzare i criteri per gli eventi in ritardo e fuori ordine in Analisi di flusso di Azure. Questi criteri vengono applicati solo quando si usa la clausola TIMESTAMP BY nella query e vengono applicati solo per le origini di input cloud.

Ora dell'evento e ora di arrivo

Il processo di Analisi di flusso può elaborare gli eventi in base all'ora dell'evento o all’ora di arrivo. L'ora dell'evento o dell'applicazione è il timestamp presente nel payload dell'evento (quando l'evento è stato generato). Orario di arrivo è il timestamp che indica il momento in cui l'evento è stato ricevuto all'origine di input (Event Hubs/hub IoT/Archiviazione BLOB).

Per impostazione predefinita, Analisi di flusso elabora gli eventi in base all'ora di arrivo, ma è possibile scegliere di elaborare gli eventi in base all'ora dell'evento usando la clausola TIMESTAMP BY nella query. I criteri relativi agli arrivi in ritardo e fuori ordine si applicano solo se si elaborano gli eventi in base all'orario dell'evento. Prendere in considerazione i requisiti di latenza e correttezza per lo scenario quando si configurano queste impostazioni.

Qual è la politica sugli arrivi in ritardo?

A volte gli eventi arrivano in ritardo per vari motivi. Ad esempio, un evento che arriva in ritardo di 40 secondi avrà l'ora dell'evento = 00:10:00 e ora di arrivo = 00:10:40. Se si imposta il criterio di arrivo in ritardo su 15 secondi, qualsiasi evento che arriva più tardi di 15 secondi verrà eliminato (non elaborato da Analisi di flusso) o il tempo dell'evento verrà modificato. Nell'esempio precedente, poiché l'evento è arrivato in ritardo di 40 secondi (più del set di criteri), il tempo dell'evento verrà modificato al massimo del criterio di arrivo in ritardo 00:10:25 (ora di arrivo - valore dei criteri di arrivo in ritardo). Il criterio di arrivo in ritardo predefinito è di 5 secondi.

Che cos'è il criterio di esecuzione non sequenziale?

Gli eventi potrebbero arrivare anche in ordine non ordinato. Dopo che l'ora dell'evento viene modificata in base ai criteri di arrivo in ritardo, è anche possibile scegliere di eliminare o regolare automaticamente gli eventi non in ordine. Se si imposta questo criterio su 8 secondi, gli eventi che arrivano fuori ordine, ma all'interno della finestra di 8 secondi, vengono riordinati in base all'ora dell'evento. Gli eventi che arrivano in ritardo verranno eliminati oppure adeguati al valore massimo previsto dal criterio relativo all’ordine di arrivo. Il criterio predefinito per la gestione fuori ordine è di 0 secondi.

Regolare o scartare gli eventi in ritardo e fuori ordine

Se gli eventi arrivano in ritardo o non ordinati in base ai criteri configurati, è possibile eliminare tali eventi (non elaborati da Analisi di flusso) o modificare il tempo dell'evento.

L'esempio seguente illustra questi criteri in azione.

• Politica sugli arrivi in ritardo: 15 secondi
• Criterio fuori ordine: 5 secondi

L'arrivo tardivo e i criteri di elaborazione non in ordine possono ritardare l'output del processo?

Sì. Per impostazione predefinita, il criterio relativo agli eventi fuori ordine è impostato su zero (00 minuti e 00 secondi). Se si modifica l'impostazione predefinita, il primo output del processo viene ritardato da questo valore (o superiore).

Se una delle partizioni di input non riceve eventi, è necessario prevedere che l'output subisca un ritardo pari al valore del criterio di arrivo tardivo. Per capire il motivo, vedere i messaggi InputPartitionNotProgressing.

I messaggi LateInputEvents vengono visualizzati nel log attività

Questi messaggi vengono visualizzati per informare che gli eventi sono arrivati in ritardo e vengono eliminati o modificati in base alla configurazione. È possibile ignorare questi messaggi se i criteri di arrivo in ritardo sono stati configurati in modo appropriato.

Ecco un esempio di questo messaggio:

{"message Time":"2019-02-04 17:11:52Z","error":null,
"message":"First Occurred: 02/04/2019 17:11:48 | Resource Name: ASAjob | Message: Source 'ASAjob' had 24 data errors of kind 'LateInputEvent' between processing times '2019-02-04T17:10:49.7250696Z' and '2019-02-04T17:11:48.7563961Z'. Input event with application timestamp '2019-02-04T17:05:51.6050000' and arrival time '2019-02-04T17:10:44.3090000' was sent later than configured tolerance.","type":"DiagnosticMessage","correlation ID":"aaaa0000-bb11-2222-33cc-444444dddddd"}

Vedo InputPartitionNotProgressing nel mio log attività

La sorgente di input (Event Hub/hub IoT) probabilmente dispone di più partizioni. Analisi di flusso di Azure genera un output per il timestamp t1 solo dopo che tutte le partizioni combinate hanno raggiunto almeno il tempo t1. Ad esempio, si supponga che la query legga da una partizione di un hub eventi con due partizioni. Una delle partizioni, P1, ha eventi fino all'ora t1. L'altra partizione, P2, ha eventi fino all'ora t1 + x. L'output viene quindi generato fino all'ora t1. Tuttavia, se è presente una clausola esplicita Partition by PartitionId, entrambe le partizioni avanzano in modo indipendente.

Quando vengono combinate più partizioni dello stesso flusso di input, la tolleranza di arrivo in ritardo è la quantità massima di tempo in cui ogni partizione attende nuovi dati. Se è presente una partizione nell'hub eventi o se l'hub IoT non riceve input, la sequenza temporale per tale partizione non procede finché non raggiunge la soglia di tolleranza di arrivo in ritardo. Questo ritarda l'output in base alla soglia di tolleranza di arrivo in ritardo. In questi casi, è possibile che venga visualizzato il messaggio seguente:

{"message Time":"2/3/2019 8:54:16 PM UTC","message":"Input Partition [2] does not have additional data for more than [5] minute(s). Partition will not progress until either events arrive or late arrival threshold is met.","type":"InputPartitionNotProgressing","correlation ID":"0000000000-0000-0000-0000-00000000000000"}

Questo messaggio ti informa che almeno una partizione nei dati di input è vuota e causerà un ritardo nell'output pari alla soglia di arrivo tardivo. Per risolvere questo problema, è consigliabile:

• Assicurarsi che tutte le partizioni dell'hub eventi/hub IoT ricevano l'input.
• Usa la clausola Partition by PartitionID nella query.

Perché viene visualizzato un ritardo di 5 secondi anche quando il criterio di arrivo in ritardo è impostato su 0?

Ciò si verifica quando è presente una partizione di input che non ha mai ricevuto alcun input. È possibile verificare le metriche di input per partizione per convalidare questo comportamento.

Quando una partizione non dispone di dati per più della soglia di arrivo in ritardo configurata, Analisi di flusso sposta il timestamp dell'applicazione come illustrato nella sezione considerazioni sull'ordinamento degli eventi. Questo richiede l'ora di arrivo stimata. Se la partizione non ha mai dati, Analisi di flusso stima l'ora di arrivo come ora locale - 5 secondi. Per questo motivo, le partizioni che non hanno mai contenuto dati potrebbero mostrare un ritardo del watermark di 5 secondi.

Passaggi successivi

• Considerazioni sulla gestione del tempo
• Metriche del processo di Analisi di flusso di Azure
• Dimensioni delle metriche di Analisi di flusso di Azure