Risolvere i problemi degli output di Analisi di flusso di Azure

Questo articolo descrive i problemi comuni relativi alle connessioni di output Analisi di flusso di Azure e come risolverli. I problemi trattati includono processi che non producono output, ritardo nella generazione del primo output, output in ritardo, violazioni di chiave in database SQL di Azure e comportamento dei tentativi di ripetizione in SQL. Molti passaggi per la risoluzione dei problemi richiedono l'abilitazione dei log delle risorse e di altri log di diagnostica per il processo di Analisi di flusso. Se i log delle risorse non sono abilitati, vedere Risolvere i problemi di Analisi di flusso di Azure usando i log delle risorse.

Il processo non produce risultati

  1. Verificare la connettività agli output con il pulsante Verifica connessione per ogni output.

  2. Vedere Monitorare il processo di Analisi di flusso con il portale di Azure nella scheda Monitoraggio. Poiché i valori sono aggregati, le metriche sono posticipate di alcuni minuti.

    • Se il valore di Eventi di input è maggiore di zero, il processo può leggere i dati di input. Se il valore di Eventi di input è minore di zero, l'input del processo presenta un problema. Per altre informazioni, vedere Risolvere i problemi delle connessioni di input. Se il processo include dati di riferimento in input, applica la suddivisione per nome logico quando si considera la metrica Eventi di input. Se non sono presenti eventi di input solo dai dati di riferimento, è probabile che questa origine di input non sia stata configurata correttamente per recuperare il set di dati di riferimento corretto.
    • Se il valore di Errori di conversione dati è maggiore di zero e in aumento, vedere Errori dei dati di Analisi di flusso di Azure per informazioni dettagliate sugli errori di conversione dei dati.
    • Se il valore di Errori di runtime è maggiore di zero, il processo riceve i dati ma genera errori durante l'elaborazione della query. Per trovare gli errori, andare ai log di controllo e applicare il filtro in base allo stato Non riuscito.
    • Se il valore di Eventi di input è maggiore di zero e il valore di Eventi di output è uguale a zero, una delle condizioni seguenti è vera:
      • L'elaborazione della query non ha prodotto eventi di output.
      • Il formato degli eventi o dei campi potrebbe non essere corretto e di conseguenza l'elaborazione della query non ha prodotto output.
      • Il processo non è riuscito a inviare i dati alla destinazione di output a causa di problemi di connettività o autenticazione.

    I messaggi del registro delle operazioni forniscono ulteriori dettagli, compreso ciò che sta accadendo, tranne nei casi in cui la logica della query filtra tutti gli eventi. Se l'elaborazione di più eventi genera errori, gli errori vengono aggregati ogni 10 minuti.

Il primo output è ritardato

Quando viene avviato un processo di Analisi di flusso, vengono letti gli eventi di input. In alcune circostanze potrebbe tuttavia verificarsi un ritardo nell'output.

Valori di tempo di grandi dimensioni negli elementi di query temporali possono contribuire al ritardo dell'output. Per produrre l'output corretto su intervalli di tempo di grandi dimensioni, il processo di streaming esegue la lettura dei dati dal momento più recente possibile per riempire l'intervallo di tempo. I dati possono risalire fino a sette giorni prima. Non viene generato alcun output finché non vengono letti gli eventi di input in sospeso. Questo problema può manifestarsi quando il sistema aggiorna i processi di streaming. Quando viene eseguito un aggiornamento, il processo viene riavviato. Questi aggiornamenti in genere vengono eseguiti una volta ogni due mesi.

Usare discrezione durante la progettazione della query di Stream Analytics. Se si usa un intervallo di tempo di grandi dimensioni per gli elementi temporali nella sintassi delle query del processo, ciò può causare un ritardo nel primo output quando il processo viene avviato o riavviato. Un intervallo superiore a qualche ora, fino a sette giorni, viene considerato un intervallo di tempo di grandi dimensioni.

Una possibile soluzione per questo tipo di ritardo di output consiste nell'uso di tecniche di parallelizzazione delle query come il partizionamento dei dati. In alternativa, è possibile aggiungere altre unità di streaming per aumentare il throughput finché il processo non si rimette in pari. Per altre informazioni, vedere Considerazioni per la creazione dei processi di Analisi di flusso.

I fattori seguenti influiscono sulla tempestività del primo output:

  • L'uso di aggregazioni su finestra, ad esempio una clausola GROUP BY con finestre temporali fisse, a salto e scorrevoli:

    • Per le aggregazioni con finestre tumbling o hopping, i risultati vengono prodotti al termine della finestra temporale.
    • Per una finestra temporale scorrevole, i risultati vengono generati quando un evento entra o esce dalla finestra temporale scorrevole.
    • Se si prevede di usare una finestra di grandi dimensioni, ad esempio più di un'ora, è consigliabile scegliere una finestra di salto o scorrevole. Questi tipi di finestra consentono di visualizzare l'output con maggiore frequenza.

  • Uso di join temporali, ad esempio JOIN con DATEDIFF:

    • Le corrispondenze vengono generate non appena arrivano entrambi i lati degli eventi corrispondenti.
    • I dati che non presentano una corrispondenza, ad esempio LEFT OUTER JOIN, vengono generati alla fine della finestra DATEDIFF per ogni evento sul lato sinistro.

  • Uso di funzioni di analisi temporale, ad esempio ISFIRST, LAST e LAG con LIMIT DURATION:

    • Per le funzioni analitiche, l'output viene generato per ogni evento. Non c'è ritardo.

L'output è in ritardo con una latenza crescente

Durante il normale funzionamento di un processo, l'output potrebbe avere periodi di latenza sempre più lunghi. Se l'output è in ritardo, è possibile individuare le cause principali esaminando i fattori indicati di seguito:

  • Se viene applicata una limitazione al sink downstream
  • Se l'origine upstream è limitata
  • Se la logica di elaborazione della query comporta un uso elevato delle risorse di calcolo

Per visualizzare i dettagli dell'output, nel portale di Azure selezionare il processo di streaming e scegliere Diagramma del processo. Per ogni input, è disponibile una metrica del backlog degli eventi per ogni partizione. Se la metrica continua ad aumentare, è un indicatore del fatto che le risorse del sistema sono vincolate. L'aumento potrebbe essere dovuto alla limitazione della velocità del sink di uscita o a un elevato utilizzo della CPU. Per altre informazioni, vedere Debug guidato dai dati mediante il diagramma di processo.

Avviso di violazione della chiave nell'output di database SQL di Azure

Quando si configura un database SQL di Azure come output di un processo di Analisi di flusso, vengono eseguiti inserimenti bulk dei record nella tabella di destinazione. Analisi di flusso di Azure garantisce in genere almeno un recapito nel sink di output. È comunque possibile garantire una consegna esattamente una volta verso un output SQL quando in una tabella SQL è definito un vincolo univoco.

Quando si configurano vincoli di chiave univoca nella tabella SQL, Analisi di flusso di Azure rimuove i record duplicati. Suddivide i dati in batch e inserisce in modo ricorsivo i batch finché non viene trovato un singolo record duplicato. Il processo di suddivisione e inserimento ignora i duplicati uno alla volta. Per un processo di streaming con molte righe duplicate, il processo è inefficiente e richiede molto tempo. Se vengono visualizzati più messaggi di avviso di violazione della chiave nel log attività dell'ora precedente, è probabile che l'output SQL stia rallentando l'intero processo.

Per risolvere questo problema, configurare l'indice che causa la violazione della chiave, abilitando l'opzione IGNORE_DUP_KEY. Questa opzione consente a SQL di ignorare i valori duplicati durante gli inserimenti bulk. Il database SQL di Azure genera semplicemente un messaggio di avviso invece di un errore. Di conseguenza, Analisi di flusso di Azure non genera più errori di violazione della chiave primaria.

Quando si configura IGNORE_DUP_KEY per diversi tipi di indici, tenere presente le osservazioni seguenti:

  • Non è possibile impostare IGNORE_DUP_KEY in una chiave primaria o in un vincolo univoco che usa ALTER INDEX. È necessario eliminare e ricreare l'indice.
  • È possibile impostare IGNORE_DUP_KEY usando ALTER INDEX per un indice univoco. Questa istanza è diversa rispetto a un vincolo PRIMARY KEY/UNIQUE e viene creata usando una definizione CREATE INDEX o INDEX.
  • L'opzione IGNORE_DUP_KEY non è valida per gli indici columnstore perché in essi non è possibile applicare l'univocità.

database SQL di Azure logica di ripetizione dell'output

Quando un processo di Analisi di flusso con output SQL riceve il primo batch di eventi, si verificano i passaggi seguenti:

  1. Il processo tenta di collegarsi a SQL.
  2. Il processo recupera lo schema della tabella di destinazione.
  3. Il processo convalida i nomi e i tipi di colonna rispetto allo schema della tabella di destinazione.
  4. Il processo prepara una tabella di dati in memoria a partire dai record di output del batch.
  5. Il processo scrive la tabella dati in SQL usando l'API BulkCopy.

Durante questi passaggi, l'output SQL può riscontrare i tipi di errori seguenti:

  • Errori temporanei per i quali vengono eseguiti nuovi tentativi usando una strategia di backoff esponenziale. L'intervallo minimo di retry dipende dal codice di errore singolo, ma gli intervalli sono in genere inferiori a 60 secondi. Il limite massimo può essere di cinque minuti.

    In caso di errori di accesso e problemi del firewall vengono effettuati retry almeno 5 minuti dopo il tentativo precedente e fino a quando non si ha esito positivo.

  • Gli errori nei dati, ad esempio gli errori di cast e le violazioni dei vincoli dello schema, vengono gestiti tramite il criterio di gestione degli errori di output. Questi errori vengono gestiti riprovando lotti suddivisi in modo binario finché il singolo record che causa l'errore non viene gestito saltandolo o riprovandolo. La violazione del vincolo di unicità della chiave primaria è sempre gestita.

  • Gli errori non temporanei possono verificarsi quando si verificano problemi del servizio SQL o difetti interni del codice. Ad esempio, quando si verificano errori come (Codice 1132), quando un pool elastico raggiunge il limite di archiviazione, i nuovi tentativi non risolvono l'errore. In questi scenari, il processo di Analisi di flusso sperimenta una riduzione delle prestazioni.

  • I timeout BulkCopy possono verificarsi durante BulkCopy nel passaggio 5. BulkCopy può occasionalmente subire timeout dell'operazione. Il timeout minimo predefinito configurato è di cinque minuti e viene raddoppiato quando viene raggiunto consecutivamente. Quando il timeout supera i 15 minuti, il suggerimento relativo alla dimensione massima del batch per BulkCopy viene dimezzato fino ad arrivare a 100 eventi per batch.

    Importante

    Per i processi ASA non inseriti in rete, non basarsi sull'indirizzo IP di origine delle connessioni provenienti da ASA in alcun modo. Possono essere indirizzi IP pubblici o privati a seconda delle operazioni dell'infrastruttura del servizio che si verificano di tanto in tanto.

I nomi delle colonne sono minuscoli in Analisi di flusso di Azure (1.0)

Quando si usa il livello di compatibilità originale (1.0), Analisi di flusso di Azure modifica i nomi di colonna in lettere minuscole. Questo comportamento è stato corretto nei livelli di compatibilità successivi. Per mantenere la distinzione tra maiuscole e minuscole, passare al livello di compatibilità 1.1 o versione successiva. Per altre informazioni, vedere Livello di compatibilità per i processi di Analisi di flusso.

Come ottenere assistenza

Per maggiore supporto, provare la Pagina delle domande di Domande e risposte Microsoft per Analisi di flusso di Azure.

Passaggi successivi

  • Last updated on