Puoi visualizzare i grafici nella scheda Metriche job della pagina Dataflow nella console Google Cloud. Ogni metrica è organizzata nelle seguenti dashboard:
Metriche della panoramica
Metriche relative ai flussi di dati (solo pipeline in modalità flusso)
- Aggiornamento dei dati (con e senza Streaming Engine)
- Latenza del sistema (con e senza Streaming Engine)
- Backlog
- Elaborazione (solo Streaming Engine)
- Parallismo (solo Streaming Engine)
- Persistenza (solo Streaming Engine)
- Dati duplicati (solo Streaming Engine)
- Timer (solo Streaming Engine)
Metriche risorsa
Metriche di input
Metriche di output
Per ulteriori informazioni sugli scenari in cui puoi utilizzare queste metriche per il debug, consulta la sezione Strumenti per il debug in "Risolvere i problemi relativi a job lenti o bloccati".
Supporto e limitazioni
Quando utilizzi le metriche di Dataflow, tieni presente i seguenti dettagli.
A volte i dati dei job non sono disponibili a intermittenza. Quando mancano i dati, nei grafici di monitoraggio dei job vengono visualizzati degli spazi vuoti.
Alcuni di questi grafici sono specifici per le pipeline di streaming.
Per scrivere i dati delle metriche, un account di servizio gestito dall'utente debe avere l'autorizzazione dell'API IAM
monitoring.timeSeries.create. Questa autorizzazione è inclusa nel ruolo Dataflow Worker.Il servizio Dataflow registra il tempo CPU riservato al termine dei job. Per i job illimitati (in streaming), il tempo CPU riservato viene riportato solo dopo l'annullamento o il fallimento dei job. Pertanto, le metriche dei job non includono il tempo CPU riservato per i job di streaming.
Accedere alle metriche del job
- Accedi alla console Google Cloud.
- Selezionare il tuo progetto Google Cloud.
- Apri il menu di navigazione e seleziona Dataflow.
- Nell'elenco dei job, fai clic sul nome del job. Viene visualizzata la pagina Dettagli job.
- Fai clic sulla scheda Metriche job.
Per accedere a ulteriori informazioni nei grafici delle metriche dei job, fai clic su Esplora dati.
Usa Cloud Monitoring
Dataflow è completamente integrato con Cloud Monitoring. Utilizza Cloud Monitoring per le seguenti attività:
- Crea avvisi quando il tuo job supera una soglia definita dall'utente.
- Utilizza Metrics Explorer per creare query e modificare l'intervallo di tempo delle metriche.
Per istruzioni su come creare avvisi e utilizzare Metrics Explorer, consulta Utilizzare Cloud Monitoring per le pipeline Dataflow.
Creare avvisi di Cloud Monitoring
Cloud Monitoring ti consente di creare avvisi quando il job Dataflow supera una soglia definita dall'utente. Per creare un avviso Cloud Monitoring da un grafico delle metriche, fai clic su Crea criterio di avviso.
Se non riesci a visualizzare i grafici di monitoraggio o a creare avvisi, potresti aver bisogno di altre autorizzazioni di monitoraggio.
Visualizza in Esplora metriche
Puoi visualizzare i grafici delle metriche di Dataflow in esploratore delle metriche, dove puoi creare query e modificare l'intervallo di tempo delle metriche.
Per visualizzare i grafici di Dataflow in Metrics Explorer, nella visualizzazione Metriche job, apri Altre opzioni di grafico e fai clic su Visualizza in Metrics Explorer.
Quando modifichi l'intervallo di tempo delle metriche, puoi selezionare una durata predefinita o un intervallo di tempo personalizzato per analizzare il job.
Per impostazione predefinita, per i job in streaming e i job batch in esecuzione, vengono mostrate le metriche delle sei ore precedenti per quel job. Per i job di streaming interrotti o completati, la visualizzazione predefinita mostra l'intero runtime della durata del job.
Metriche I/O di Dataflow
Puoi visualizzare le seguenti metriche di I/O di Dataflow in Esplora metriche:
job/pubsub/write_count: richieste di pubblicazione Pub/Sub da PubsubIO.Write nei job Dataflow.job/pubsub/read_count: richieste pull di Pub/Sub da PubsubIO.Read nei job Dataflow.job/bigquery/write_count: BigQuery pubblica le richieste da BigQueryIO.Write nei job Dataflow. Le metrichejob/bigquery/write_countsono disponibili nelle pipeline Python che utilizzano la trasformazione WriteToBigQuery conmethod='STREAMING_INSERTS'abilitato su Apache Beam 2.28.0 o versioni successive. Questa metrica è disponibile sia per le pipeline in batch che per quelle in streaming.- Se la pipeline utilizza un'origine o una destinazione BigQuery, per risolvere i problemi relativi alla quota, utilizza le metriche dell'API BigQuery Storage.
Per l'elenco completo delle metriche di Dataflow, consulta la documentazione delle metriche di Google Cloud.
Metriche relative a fasi e worker
Le sezioni seguenti forniscono dettagli sulle metriche relative alle fasi e ai worker disponibili nell'interfaccia di monitoraggio.
Scalabilità automatica
Il servizio Dataflow sceglie automaticamente il numero di istanze worker necessarie per eseguire il job con scalabilità automatica. Il numero di istanze worker può cambiare nel tempo in base ai requisiti del job.
Per visualizzare la cronologia delle modifiche alla scalabilità automatica, fai clic su Più cronologia. Viene visualizzata una tabella con informazioni sulla cronologia dei worker del tuo job.
Velocità effettiva
La velocità effettiva è il volume di dati elaborati in un determinato momento. Questa metrica per passaggio viene visualizzata come numero di elementi al secondo. Per visualizzare questa metrica in byte al secondo, consulta il grafico Velocità effettiva (byte/sec) più avanti nella pagina.
Conteggio log errori del worker
Il Conteggio log errori del worker mostra il tasso di errori osservato in tutti i worker in un determinato momento.
Aggiornamento dei dati (con e senza Streaming Engine)
La metrica Aggiornamento dei dati mostra la differenza in secondi tra il timestamp nell'elemento dati e il momento in cui l'evento viene elaborato nella pipeline. L'elemento di dati riceve un timestamp quando si verifica un evento nell'elemento, ad esempio un evento di clic su un sito web o l'importazione da Pub/Sub. Il watermark di output è l'ora in cui i dati vengono elaborati.
In qualsiasi momento, il job Dataflow elabora più elementi. I punti dati nel grafico dell'aggiornamento dei dati mostrano l'elemento con il ritardo maggiore rispetto all'ora dell'evento. Pertanto, la stessa riga del grafico mostra i dati per più elementi. Ogni punto dati nella riga mostra i dati relativi all'elemento più lento in quella fase della pipeline.
Se alcuni dati di input non sono ancora stati elaborati, la marcatura temporale in uscita potrebbe essere ritardata, il che influisce sull'aggiornamento dei dati. Una differenza significativa tra la data e l'ora della filigrana e la data e l'ora dell'evento potrebbe indicare un'operazione lenta o bloccata.
Per i job di streaming aggiornati di recente, le informazioni sullo stato e sulla filigrana dei job potrebbero non essere disponibili. L'operazione di aggiornamento apporta diverse modifiche che richiedono alcuni minuti per essere propagate all'interfaccia di monitoraggio di Dataflow. Prova ad aggiornare l'interfaccia di monitoraggio 5 minuti dopo aver aggiornato il job.
Per ulteriori informazioni, consulta Watermark e dati in ritardo nella documentazione di Apache Beam.
La dashboard include i seguenti due grafici:
- Aggiornamento dei dati per fase
- Aggiornamento dei dati
Nell'immagine precedente, l'area evidenziata mostra una differenza sostanziale tra la data e l'ora dell'evento e la data e l'ora della filigrana in uscita, a indicare un'operazione lenta.
Le metriche relative all'aggiornamento dei dati elevato (ad esempio, le metriche che indicano che i dati sono meno aggiornati) potrebbero essere causate da:
- Colli di bottiglia delle prestazioni: se la pipeline presenta fasi con latenza del sistema elevata o log che indicano trasformazioni bloccate, la pipeline potrebbe avere problemi di prestazioni che potrebbero aumentare l'aggiornamento dei dati. Per ulteriori indagini, consulta Risolvere i problemi relativi a job lenti o bloccati.
- Bottleneck delle origini dati: se le origini dati presentano un backlog in crescita, i timestamp degli eventi degli elementi potrebbero discostarsi dalla marcatura temporale in attesa di essere elaborati. Le code di grandi dimensioni sono spesso causate da colli di bottiglia delle prestazioni o da problemi relativi alle origini dati, che è meglio rilevare monitorando le origini utilizzate dalla pipeline.
- Le origini non ordinate come Pub/Sub possono produrre filigrane bloccate anche durante l'output a una frequenza elevata. Questa situazione si verifica perché gli elementi non vengono visualizzati in ordine di timestamp e la filigrana si basa sul timestamp non elaborato minimo.
- Ripetizioni frequenti: se vedi errori che indicano che gli elementi non vengono elaborati e vengono riprovati, i timestamp precedenti degli elementi riprovati potrebbero aumentare l'aggiornamento dei dati. L'elenco degli errori comuni di Dataflow può aiutarti a risolvere i problemi.
Latenza di sistema (con e senza Streaming Engine)
La latenza del sistema è il numero massimo di secondi in cui un elemento di dati è stato elaborato o è in attesa di elaborazione. Questa metrica indica per quanto tempo un elemento rimane in attesa all'interno di qualsiasi origine della pipeline. La durata massima viene regolata dopo l'elaborazione. I seguenti casi sono considerazioni aggiuntive:
- Per più origini e destinazioni, la latenza del sistema è il tempo massimo che un elemento attende all'interno di un'origine prima di essere scritto in tutte le destinazioni.
- A volte, un'origine non fornisce un valore per il periodo di tempo per cui un elemento attende all'interno dell'origine. Inoltre, l'elemento potrebbe non avere metadati per definire la relativa ora dell'evento. In questo scenario, la latenza del sistema viene calcolata dal momento in cui la pipeline riceve per la prima volta l'elemento.
La dashboard include i seguenti due grafici:
- Latenza di sistema per fase
- Latenza di sistema
Backlog
La dashboard Backlog fornisce informazioni sugli elementi in attesa di elaborazione. La dashboard include i seguenti due grafici:
- Secondi di backlog (solo Streaming Engine)
- Byte di backlog (con e senza Streaming Engine)
Il grafico Secondi di backlog mostra una stima del tempo in secondi necessario per consumare il backlog attuale se non arrivano nuovi dati e la velocità effettiva non cambia. Il tempo di coda stimato viene calcolato sia in base alla velocità in bit sia in base ai byte in coda dell'origine di input che devono ancora essere elaborati. Questa metrica viene utilizzata dalla funzionalità di scalabilità automatica per lo streaming per determinare quando eseguire lo scale up o lo scale down.
Il grafico Byte in coda mostra la quantità di input non elaborati noti per una fase in byte. Questa metrica confronta i byte rimanenti da consumare da ogni fase con le fasi a monte. Affinché questa metrica venga registrata con precisione, ogni origine importata dalla pipeline deve essere configurata correttamente. Le origini integrate come Pub/Sub e BigQuery sono già supportate, ma le origini personalizzate richiedono un'implementazione aggiuntiva. Per maggiori dettagli, consulta la sezione sulla scalabilità automatica per le origini illimitate personalizzate.
Elaborazione (solo Streaming Engine)
Quando esegui una pipeline Apache Beam sul servizio Dataflow, le attività della pipeline vengono eseguite sulle VM worker. La dashboard Elaborazione fornisce informazioni sul tempo di elaborazione delle attività sulle VM worker. La dashboard include i seguenti due grafici:
- Mappa termica delle latenze di elaborazione utente
- Latenze di elaborazione utente per fase
La mappa termica delle latenze di elaborazione utente mostra le latenze massime delle operazioni per le distribuzioni del 50°, 95° e 99° percentile. Utilizza la mappa di calore per verificare se le operazioni a coda lunga stanno causando una latenza complessiva elevata del sistema o stanno influenzando negativamente l'aggiornamento complessivo dei dati.
Per risolvere un problema a monte prima che si trasformi in un problema a valle, imposta un criterio di avviso per le latenze elevate nel 50° percentile.
Il grafico Latenze di elaborazione utente per fase mostra il 99° percentile di tutte le attività in fase di elaborazione da parte dei worker, suddivise per fase. Se il codice utente causa un ingorgo, questo grafico mostra la fase in cui si verifica. Per eseguire il debug della pipeline, puoi seguire questi passaggi:
Utilizza il grafico per trovare una fase con una latenza insolitamente elevata.
Nella pagina dei dettagli del job, nella scheda Dettagli esecuzione, seleziona Flusso di lavoro delle fasi per Visualizzazione grafico. Nel grafico Flusso di lavoro delle fasi, individua la fase con una latenza insolitamente elevata.
Per trovare le operazioni utente associate, fai clic sul nodo della fase nel grafico.
Per ulteriori dettagli, vai a Cloud Profiler e utilizza Cloud Profiler per eseguire il debug della analisi dello stack nell'intervallo di tempo corretto. Cerca le operazioni utente che hai identificato nel passaggio precedente.
Parallelismo (solo Streaming Engine)
Il grafico Elaborazione parallela mostra il numero approssimativo di chiavi in uso per l'elaborazione dei dati per ogni fase. Dataflow si espande in base al parallelismo di una pipeline.
Quando Dataflow esegue una pipeline, l'elaborazione viene distribuita su più macchine virtuali (VM) Compute Engine, note anche come worker. Il servizio Dataflow esegue automaticamente il parallelismo e la distribuzione della logica di elaborazione della pipeline ai worker. L'elaborazione per una determinata chiave è serializzata, pertanto il numero totale di chiavi per una fase rappresenta il parallelismo massimo disponibile in quella fase.
Le metriche sul parallelismo possono essere utili per trovare hot key o colli di bottiglia per pipeline lente o bloccate.
Persistenza (solo Streaming Engine)
La dashboard Persistenza fornisce informazioni sulla frequenza con cui la memorizzazione permanente viene scritta e letta da una determinata fase della pipeline in byte al secondo. I byte letti e scritti includono le operazioni e lo stato dello stato dell'utente per le operazioni di shuffling permanenti, la rimozione di duplicati, gli input laterali e il monitoraggio della filigrana. I codificatori della pipeline e la memorizzazione nella cache influiscono sui byte letti e scritti. I byte di spazio di archiviazione potrebbero essere diversi dai byte elaborati a causa dell'utilizzo dello spazio di archiviazione interno e della memorizzazione nella cache.
La dashboard include i seguenti due grafici:
- Scrittura nello spazio di archiviazione
- Lettura dello spazio di archiviazione
Duplicati (solo Streaming Engine)
Il grafico Duplicati mostra il numero di messaggi in fase di elaborazione da parte di una determinata fase che sono stati filtrati come duplicati.
Dataflow supporta molte origini e destinazioni che garantiscono l'invio at least once. Lo svantaggio della pubblicazione di at least once è che può comportare duplicati.
Dataflow garantisce la pubblicazione exactly once, il che significa che i duplicati vengono filtrati automaticamente.
Le fasi successive vengono risparmiate dalla rielaborazione degli stessi elementi, il che garantisce che lo stato e gli output non siano interessati.
La pipeline può essere ottimizzata per le risorse e il rendimento riducendo il numero di duplicati prodotti in ogni fase.
Timer (solo Streaming Engine)
La dashboard Timer fornisce informazioni sul numero di timer in attesa e sul numero di timer già elaborati in una determinata fase della pipeline. Poiché le finestre si basano su timer, questa metrica ti consente di monitorare l'avanzamento delle finestre.
La dashboard include i seguenti due grafici:
- Timer in attesa per fase
- Elaborazione dei timer per fase
Questi grafici mostrano la frequenza con cui le finestre sono in attesa o in fase di elaborazione in un determinato momento. Il grafico Timer in attesa per fase indica il numero di finestre in ritardo a causa di colli di bottiglia. Il grafico Elaborazione dei timer per fase indica quante finestre stanno raccogliendo elementi.
Questi grafici mostrano tutti i timer dei job, quindi se i timer vengono utilizzati altrove nel codice, vengono visualizzati anche in questi grafici.
Utilizzo CPU
L'utilizzo della CPU è la quantità di CPU utilizzata divisa per la quantità di CPU disponibile per l'elaborazione. Questa metrica per utente viene visualizzata come percentuale. La dashboard include i seguenti quattro grafici:
- Utilizzo CPU (tutti i worker)
- Utilizzo della CPU (statistiche)
- Utilizzo CPU (primi 4)
- Utilizzo CPU (ultimi 4)
Utilizzo memoria
L'utilizzo della memoria è la quantità stimata di memoria utilizzata dai worker in byte al secondo. La dashboard include i seguenti due grafici:
- Utilizzo massimo della memoria da parte del worker (byte/sec stimati)
- Utilizzo della memoria (byte/sec stimati)
Il grafico Utilizzo massimo della memoria del worker fornisce informazioni sui worker che utilizzano la maggior parte della memoria nel job Dataflow in ogni momento. Se, in momenti diversi durante un job, il worker che utilizza la quantità massima di memoria cambia, la stessa riga del grafico mostra i dati di più worker. Ogni punto dati nella riga mostra i dati relativi al worker che utilizza la quantità massima di memoria in quel momento. Il grafico confronta la memoria stimata utilizzata dal worker con il limite di memoria in byte.
Puoi utilizzare questo grafico per risolvere i problemi di esaurimento della memoria. Gli arresti anomali di out-of-memory dei worker non vengono mostrati in questo grafico.
Il grafico Utilizzo della memoria mostra una stima della memoria utilizzata da tutti i worker nel job Dataflow rispetto al limite di memoria in byte.
Metriche di input e output
Se il job Dataflow in streaming legge o scrive record utilizzando Pub/Sub, vengono visualizzate le metriche di input e di output.
Tutte le metriche di input dello stesso tipo vengono combinate, così come tutte le metriche di output. Ad esempio, tutte le metriche Pub/Sub sono raggruppate in una sezione. Ogni tipo di metrica è organizzato in una sezione separata. Per modificare le metriche visualizzate, seleziona la sezione a sinistra che rappresenta al meglio le metriche che stai cercando. Le immagini seguenti mostrano tutte le sezioni disponibili.
I due grafici seguenti vengono visualizzati sia nelle sezioni Metriche di input sia in Metriche di output.
Richieste al secondo
Le richieste al secondo indicano la frequenza delle richieste API per leggere o scrivere dati dall'origine o nel destino nel tempo. Se questo tasso scende a zero o diminuisce notevolmente per un periodo di tempo prolungato rispetto al comportamento previsto, l'esecuzione di determinate operazioni della pipeline potrebbe essere bloccata. Inoltre, potrebbe non esserci alcun dato da leggere. In questo caso, esamina i passaggi del job con una filigrana di sistema elevata. Inoltre, esamina i log dei worker per rilevare errori o indicazioni relative a un'elaborazione lenta.
Errori di risposta al secondo per tipo di errore
La metrica Errori di risposta al secondo per tipo di errore indica la frequenza delle richieste API non riuscite per leggere o scrivere dati dall'origine o nel destino nel tempo. Se questi errori si verificano di frequente, queste richieste API potrebbero rallentare l'elaborazione. Queste richieste API non riuscite devono essere esaminate. Per risolvere questi problemi, consulta i codici di errore di input e output generali. Esamina anche la documentazione dei codici di errore specifici utilizzati dall'origine o dalla destinazione, ad esempio i codici di errore Pub/Sub.
