Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo descrive come configurare e usare criteri per eventi in ritardo e non ordinati 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). L’ora di arrivo è il timestamp quando l'evento è stato ricevuto nell'origine di input (Hub eventi/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 IN BASE A nella query. I criteri di arrivo in ritardo e out-of-order sono applicabili solo se si elaborano gli eventi in base all'ora dell'evento. Prendere in considerazione i requisiti di latenza e correttezza per lo scenario durante la configurazione di queste impostazioni.
Che cosa sono i criteri di arrivo in ritardo?
A volte gli eventi arrivano in ritardo a causa di 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 dopo 15 secondi verrà eliminato (non elaborato da Analisi di flusso) o l'ora dell'evento verrà modificata. 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 cosa sono i criteri di arrivo non in ordine?
L'evento potrebbe arrivare anche fuori ordine. 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 un secondo momento verranno eliminati o modificati in base al valore massimo dei criteri non in ordine. I criteri predefiniti non ordinati sono 0 secondi.
Regolare o eliminare gli eventi
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.
Vediamo un esempio di questi criteri in azione.
Criteri di arrivo in ritardo: 15 secondi
Criterio non ordinato: 5 secondi
| Evento N. | Ora dell'evento | Ora di arrivo | System.Timestamp | Spiegazione |
|---|---|---|---|---|
| 1 | 00:10:00 | 00:10:40 | 00:10:25 | L'evento è arrivato in ritardo e al di fuori del livello di tolleranza. Pertanto, l'ora dell'evento viene modificata in base alla tolleranza massima di arrivo in ritardo. |
| 2 | 00:10:30 | 00:10:41 | 00:10:30 | L'evento è arrivato in ritardo ma entro il livello di tolleranza. Quindi l'ora dell'evento non viene modificata. |
| 3 | 00:10:42 | 00:10:42 | 00:10:42 | L'evento è arrivato in tempo. Nessuna regolazione necessaria. |
| 4 | 00:10:38 | 00:10:43 | 00:10:38 | L'evento è arrivato fuori ordine, ma entro 5 secondi. Quindi, l'ora dell'evento non viene modificata. Ai fini dell'analisi, questo evento verrà considerato come numero di evento precedente 3 (considerando il totale di 5 eventi. L'ordine effettivo è: 1, 2, 5, 4, 3). |
| 5 | 00:10:35 | 00:10:45 | 00:10:37 | L'evento è arrivato fuori ordine e fuori tolleranza di 5 secondi. Pertanto, l'ora dell'evento viene modificata al massimo della tolleranza non in ordine. |
Queste impostazioni possono ritardare l'output del processo?
Sì. Per impostazione predefinita, i criteri non ordinati sono impostati 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 degli input non riceve eventi, è consigliabile che l'output venga ritardato dal valore dei criteri di arrivo in ritardo. Per informazioni sul motivo, leggere la sezione Errore InputPartition di seguito.
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.
L'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"}
Viene visualizzato InputPartitionNotProgressing nel log attività
L'origine di input (hub eventi/hub IoT) ha probabilmente più partizioni. Analisi di flusso di Azure genera output per timestamp t1 solo dopo che tutte le partizioni combinate sono almeno al momento t1. Ad esempio, si supponga che la query legga da una partizione dell'hub eventi che ha 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 indica che almeno una partizione nell'input è vuota e ritarderà l'output in base alla soglia di arrivo in ritardo. Per ovviare a questo problema, è consigliabile:
- Assicurarsi che tutte le partizioni dell'hub eventi/hub IoT ricevano l'input.
- Usare 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 fa avanzare 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. A causa di questo, le partizioni che non hanno mai avuto dati potrebbero mostrare un ritardo limite di 5 secondi.