Puoi visualizzare i grafici nella scheda Metriche del job di Dataflow nella console Google Cloud. Ogni metrica è organizzata nelle seguenti dashboard:
Metriche della panoramica
Metriche in modalità flusso (solo pipeline di flusso)
- Aggiornamento dei dati (con e senza Streaming Engine)
- Latenza di sistema (con e senza Streaming Engine)
- Arredamento
- Elaborazione (solo Streaming Engine)
- Parallelismo (solo Streaming Engine)
- Persistenza (solo motore di streaming)
- Duplicati (solo motore di streaming)
- Timer (solo motore di streaming)
Metriche risorsa
Metriche di input
Metriche di output
Per ulteriori informazioni sugli scenari in cui puoi utilizzare queste metriche per il debug, consulta Strumenti per il debug in "Risolvere i problemi di job lenti o bloccati".
Supporto e limitazioni
Quando utilizzi le metriche Dataflow, tieni presente i seguenti dettagli.
A volte i dati dei job non sono disponibili a intermittenza. Quando mancano dati, Nei grafici del monitoraggio dei job vengono visualizzate delle lacune.
Alcuni di questi grafici sono specifici per le pipeline in modalità flusso.
Per scrivere dati delle metriche, è necessario account di servizio gestito dall'utente deve disporre dell'autorizzazione API IAM
monitoring.timeSeries.create. Questo è inclusa nella Ruolo Worker Dataflow.Il servizio Dataflow segnala il tempo di CPU riservato dopo i job completato. Per i job illimitati (flussi di dati), il tempo di CPU riservato è e viene riportato solo dopo che i job sono stati annullati o non sono riusciti. Pertanto, il job non includono il tempo di CPU riservato per i job di flussi.
Accedi 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. Si apre la pagina Dettagli job.
- Fai clic sulla scheda Metriche del job.
Per accedere a informazioni aggiuntive nei grafici delle metriche del job, fai clic su Esplorare i dati.
Usa Cloud Monitoring
Dataflow è completamente integrato con Cloud Monitoring. Utilizza le funzionalità di Cloud Monitoring per le attività seguenti:
- Crea avvisi quando il job supera una soglia definita dall'utente.
- Utilizza Esplora metriche per creare query e modificare il periodo di tempo delle metriche.
Per istruzioni sulla creazione di avvisi e sull'utilizzo di Metrics Explorer, consulta Utilizzare Cloud Monitoring per le pipeline Dataflow.
Creazione di avvisi di Cloud Monitoring
Cloud Monitoring consente di creare avvisi quando il job Dataflow supera una soglia definita dall'utente. Per creare un avviso di 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 Dataflow in Esplora metriche, in cui puoi creare query e regolare il periodo di tempo delle metriche.
Per visualizzare i grafici Dataflow in Metrics Explorer, nella visualizzazione Metriche del job, apri Altre opzioni del grafico e fai clic su Visualizza in Esplora metriche.
Quando regoli l'intervallo di tempo delle metriche, puoi selezionare un valore predefinito o seleziona un intervallo di tempo personalizzato per analizzare il job.
Per impostazione predefinita, per i job di flussi di dati e per i job batch in corso, il display mostra le precedenti sei ore di metriche per quel job. Per interrotti o completati per i job di flussi di dati, la visualizzazione predefinita mostra l'intero runtime per la durata del job.
Metriche Dataflow I/O
Puoi visualizzare le seguenti metriche di I/O di Dataflow in Esplora metriche:
job/pubsub/write_count: richieste di pubblicazione di Pub/Sub da PubsubIO.Write nei job Dataflow.job/pubsub/read_count: richieste di pull Pub/Sub da PubsubIO.Read nei job Dataflow.job/bigquery/write_count: BigQuery pubblica richieste da BigQueryIO.Write nei job Dataflow. Le metrichejob/bigquery/write_countsono disponibili nelle pipeline Python che utilizzano la trasformazione ScriviToBigQuery conmethod='STREAMING_INSERTS'abilitato su Apache Beam 2.28.0 o versioni successive.- Se la tua pipeline utilizza un'origine o un sink BigQuery, per risolvere i problemi relativi alle quote, utilizza Metriche dell'API BigQuery Storage.
Per l'elenco completo delle metriche di Dataflow, consulta documentazione sulle metriche di Google Cloud.
Metriche di fase e worker
Le seguenti sezioni forniscono dettagli sulla fase e sulle metriche worker disponibili nell'interfaccia di monitoraggio.
Scalabilità automatica
Il servizio Dataflow sceglie automaticamente il numero delle istanze worker necessarie per l'esecuzione un job di scalabilità automatica. La di istanze worker può cambiare nel tempo in base ai requisiti del job.
Per visualizzare la cronologia delle modifiche alla scalabilità automatica, fai clic sul pulsante Altra cronologia. . Viene visualizzata una tabella con informazioni sulla cronologia dei worker della pipeline.
Velocità effettiva
La velocità effettiva è il volume di dati elaborati in qualsiasi momento. Questo la metrica per passaggio viene visualizzata come numero di elementi al secondo. A vedi questa metrica in byte al secondo, guarda Grafico Velocità effettiva (byte/sec) più in basso nella pagina.
Conteggio log errori del worker
Conteggio log degli errori del worker mostra la percentuale di errori osservati tra tutti i worker in qualsiasi momento.
Aggiornamento dei dati (con e senza Streaming Engine)
La metrica di aggiornamento dei dati mostra la differenza in secondi tra il timestamp sull'elemento dati e sull'ora in cui l'evento viene elaborato nella pipeline. L'elemento di dati riceve un timestamp quando si verifica un evento sull'elemento, ad esempio come evento di clic su un sito web o come importazione da parte di Pub/Sub. La filigrana di output indica l'ora in cui i dati vengono elaborati.
Il job Dataflow sta elaborando più elementi in qualsiasi momento. La i punti dati nel grafico di aggiornamento dei dati mostrano l'elemento con rispetto all'ora dell'evento. Pertanto, la stessa linea nel grafico mostra dati per più elementi. Ciascun punto dati nella linea visualizza i dati per l'elemento più lento in quella fase della pipeline.
Se alcuni dati di input non sono stati ancora elaborati, la filigrana di output potrebbe subire ritardi. il che influisce sull'aggiornamento dei dati. Una differenza significativa tra l'ora della filigrana e quella dell'evento potrebbe indicare un'operazione lenta o bloccata.
Per i job di flussi aggiornati di recente, le informazioni sullo stato del job e sulla filigrana potrebbero non sarà disponibile. L'operazione di aggiornamento apporta varie modifiche che richiedono minuti per propagarsi all'interfaccia di monitoraggio di Dataflow. Prova aggiornando l'interfaccia di monitoraggio 5 minuti dopo l'aggiornamento del job.
Per ulteriori informazioni, consulta Filigrane e dati in ritardo nella documentazione di Apache Beam.
La dashboard include i due grafici seguenti:
- Aggiornamento dei dati per fase
- Aggiornamento dei dati
Nell'immagine precedente, l'area evidenziata mostra una differenza sostanziale tra l'ora dell'evento e quella della filigrana di output, che indicano un funzionamento lento.
Metriche di aggiornamento dei dati elevate (ad esempio metriche che indicano che i dati sono meno aggiornati) potrebbero essere causati da:
- Colli di bottiglia delle prestazioni: se la pipeline ha fasi con un'elevata latenza di sistema o log che indicano trasformazioni bloccate, la pipeline potrebbe avere problemi di prestazioni che potrebbero aumentare l'aggiornamento dei dati. Segui questi linee guida per la risoluzione dei problemi di pipeline lente per svolgere ulteriori indagini.
- Colli di bottiglia delle origini dati: se le tue origini dati hanno arretrati crescenti,
i timestamp degli eventi degli elementi potrebbero discostarsi dalla filigrana mentre attendono di essere
elaborati. Un arretrato elevato è spesso causato da colli di bottiglia delle prestazioni,
oppure a problemi relativi alle origini dati,
che vengono rilevati al meglio monitorando le origini utilizzate
dalla tua pipeline.
- Nota: origini non ordinate come Pub/Sub possono generare filigrane bloccate anche durante la stampa con una frequenza elevata. Questa situazione si verifica perché gli elementi non viene restituito in ordine di timestamp e la filigrana si basa sul numero minimo Timestamp non elaborato.
- Riprova frequenti: se noti errori che indicano che gli elementi non vengono riusciti per elaborare e riprovare, i timestamp meno recenti potrebbero aumentare l'aggiornamento dei dati. La elenco di errori comuni di Dataflow può aiutarti a risolvere i problemi.
Latenza di sistema (con e senza Streaming Engine)
La latenza di sistema è il numero massimo attuale di secondi di un dato dati in fase di elaborazione o in attesa di elaborazione. Questa metrica indica il tempo di attesa di un elemento all'interno di una un'origine nella pipeline. La durata massima viene regolata dopo l'elaborazione. I seguenti casi sono considerazioni aggiuntive:
- Per più origini e sink, la latenza di sistema è la massima quantità di tempo che un elemento attende all'interno di un'origine prima che venga scritto a tutti lavandini.
- A volte, un'origine non fornisce un valore per il periodo di tempo per il quale un elemento attende all'interno del tag sorgente. Inoltre, l'elemento potrebbe non disporre di metadati per definire l'ora dell'evento. In questo scenario, la latenza di sistema viene calcolata dal momento in cui la pipeline riceve per la prima volta l'elemento.
La dashboard include i due grafici seguenti:
- Latenza di sistema per fase
- Latenza di sistema
Backlog
La dashboard Backlog fornisce informazioni sugli elementi in attesa di essere elaborati. La dashboard include i due grafici seguenti:
- Secondi di backlog (solo Streaming Engine)
- Byte di backlog (con e senza Streaming Engine)
Il grafico Secondi di backlog mostra una stima del di tempo in secondi necessario per consumare il backlog attuale se non sono e la velocità effettiva non cambia. Il tempo di backlog stimato è calcolata sia dalla velocità effettiva che dai byte di backlog dall'origine di input che devono ancora essere elaborati. Questa metrica è utilizzata scalabilità automatica dei flussi per stabilire quando fare lo scale up o lo scale down.
Il grafico Byte di backlog mostra la quantità di input noti non elaborati per una fase in byte. Questa metrica confronta i byte rimanenti che ogni fase deve utilizzare con le fasi upstream. Affinché questa metrica generi report accurati, ogni origine importata dalla pipeline deve essere configurata correttamente. Le origini integrate come Pub/Sub e BigQuery sono già supportate fin dal primo avvio, ma le origini personalizzate richiedono un'implementazione aggiuntiva. Per maggiori dettagli, consulta la sezione sulla scalabilità automatica per origini personalizzate illimitate.
Elaborazione (solo Streaming Engine)
Quando esegui una pipeline Apache Beam sul servizio Dataflow, delle attività della pipeline vengono eseguite sulle VM worker. Dashboard di Elaborazione fornisce informazioni sulla quantità di tempo che le attività sono state elaborate delle VM worker. La dashboard include: due grafici:
- Mappa termica delle latenze di elaborazione utente
- Latenze di elaborazione utente per fase
La mappa termica delle latenze di elaborazione utente mostra il numero massimo di operazioni per le distribuzioni del 50°, 95° e 99° percentile. Usa la mappa termica per capire se sono presenti long-tail le operazioni causano un'elevata latenza complessiva del sistema o influiscono negativamente l'aggiornamento complessivo dei dati.
Per risolvere un problema upstream prima che si trasformi in un problema downstream, imposta un avviso per le latenze elevate nel 50° percentile.
Il grafico Latenze di elaborazione utente per fase mostra il 99° percentile per tutte le attività elaborate dai worker, suddivise per fase. Se il codice utente causa un collo di bottiglia, questo grafico mostra quale fase contiene il collo di bottiglia. Puoi utilizzare la modalità segui questi passaggi per eseguire il debug della pipeline:
Utilizza il grafico per trovare una fase con una latenza insolitamente elevata.
Nella pagina dei dettagli del job, nella scheda Dettagli esecuzione, per la Visualizzazione grafico, Seleziona Fase di flusso di lavoro. Individua la fase nel grafico Flusso di lavoro fase. con latenza insolitamente elevata.
Per trovare le operazioni utente associate, fai clic sul nodo per quella fase nel grafico.
Per trovare ulteriori dettagli, vai a Cloud Profiler e utilizzare Cloud Profiler per eseguire il debug dell'analisi dello stack nell'intervallo di tempo corretto. Aspetto per le operazioni utente identificate nel passaggio precedente.
Parallelismo (solo Streaming Engine)
Il grafico Elaborazione parallela mostra il numero approssimativo di chiavi in uso. per l'elaborazione dei dati in ogni fase. Dataflow scala in base 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 lo parallelizza e distribuisce automaticamente la logica di elaborazione della pipeline ai worker. L'elaborazione di una determinata chiave è serializzata, quindi il numero totale di chiavi per un rappresenta il massimo parallelismo disponibile in quella fase.
Le metriche di parallelismo possono essere utili per trovare chiavi di scelta rapida o colli di bottiglia per o pipeline bloccate.
Persistenza (solo motore di streaming)
La dashboard Persistenza fornisce informazioni sulla frequenza con cui l'archiviazione permanente viene scritta e letta da una particolare fase della pipeline in byte e un numero elevato di operazioni di I/O al secondo. I byte letti e scritti includono le operazioni sullo stato utente e lo stato per shuffling permanenti, duplicati rimozione, input aggiuntivi e monitoraggio della filigrana. I programmatori della pipeline e la memorizzazione nella cache influiscono byte letti e scritti. I byte di archiviazione potrebbero essere diversi dai byte elaborati a causa all'utilizzo della memoria interna e alla memorizzazione nella cache.
La dashboard include i due grafici seguenti:
- Scrittura spazio di archiviazione
- Lettura spazio di archiviazione
Duplicati (solo motore di streaming)
Il grafico Duplicati mostra il numero di messaggi elaborati da una determinata fase e filtrati come duplicati.
Dataflow supporta molte origini e sink che garantiscono la distribuzione di at least once. Lo svantaggio della pubblicazione con at least once è che può generare duplicati.
Dataflow garantisce la distribuzione exactly once, il che significa che i duplicati vengono filtrati automaticamente.
Le fasi downstream vengono salvate tramite la rielaborazione degli stessi elementi, il che garantisce che lo stato e gli output non siano interessati.
La pipeline può essere ottimizzata in termini di risorse e prestazioni riducendo il numero di duplicati prodotti in ogni fase.
Timer (solo motore di streaming)
La dashboard Timer fornisce informazioni sul numero di timer in attesa e il numero di timer già elaborati in una determinata fase della pipeline. Poiché le finestre si basano sui timer, questa metrica ti consente di tenere traccia dell'avanzamento delle finestre.
La dashboard include i due grafici seguenti:
- Timer in attesa per fase
- Elaborazione dei timer per fase
Questi grafici mostrano la frequenza con cui le finestre sono in attesa o in elaborazione in un momento specifico. Il grafico Timer in attesa per fase indica il numero di le finestre subiscono ritardi a causa di colli di bottiglia. Grafico Timer per fase di elaborazione indica quante finestre raccolgono elementi.
Questi grafici mostrano tutti i timer dei job, quindi se i timer vengono utilizzati altrove nel codice, anche questi timer appaiono in questi grafici.
Utilizzo CPU
L'utilizzo della CPU è la quantità di CPU utilizzata divisa per la quantità di CPU disponibili per l'elaborazione. Questa metrica per worker viene visualizzata in 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 due grafici seguenti:
- Utilizzo massimo della memoria dei worker (byte stimati al secondo)
- Utilizzo della memoria (byte stimati al secondo)
Il grafico Utilizzo massimo della memoria dei worker fornisce informazioni sui worker che utilizzano più memoria nel job Dataflow in ogni momento. Se, in momenti diversi durante un lavoro, il lavoratore utilizza il limite massimo quantità di memoria modificata, la stessa riga del grafico mostra i dati relativi a più worker. Ogni punto dati nella linea visualizza i dati per il worker utilizzando la quantità massima di memoria in quel momento. Il grafico confronta la memoria stimata utilizzata dal worker fino al limite di memoria in byte.
Puoi utilizzare questo grafico per risolvere i problemi di esaurimento della memoria. Memoria worker esaurita gli arresti anomali non vengono mostrati in questo grafico.
Il grafico Utilizzo 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 modalità flusso legge o scrive record utilizzando Pub/Sub, le metriche di input e quelle di output.
Vengono combinate tutte le metriche di input dello stesso tipo e 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 seguenti immagini mostrano tutte le sezioni disponibili.
I due grafici seguenti vengono visualizzati nelle sezioni Metriche di input e Metriche di output.
Richieste al secondo
Richieste al secondo è la frequenza di richieste API di lettura o scrittura di dati in base all'origine o al sink nel tempo. Se questo tasso scende a zero o diminuisce in modo significativo per un periodo di tempo prolungato. rispetto al comportamento previsto, l'esecuzione della pipeline potrebbe essere bloccata alcune operazioni. Inoltre, potrebbero non esserci dati da leggere. In tal caso, rivedi i passaggi del job con un livello elevato di filigrana di sistema. Esamina anche le log dei worker per rilevare errori o indicazioni sull'elaborazione lenta.
Errori di risposta al secondo per tipo di errore
Errori di risposta al secondo per tipo di errore è la percentuale di richieste API non riuscite da leggere o scrivere dati dall'origine o dal sink nel tempo. Se questi errori si verificano spesso, le richieste API potrebbero rallentare l'elaborazione. Le richieste API non riuscite devono essere analizzate. Per risolvere questi problemi, consulta le Documentazione sui codici di errore I/O. Esamina anche l'eventuale documentazione relativa ai codici di errore specifica utilizzata dall'origine o dal sink, come Codici di errore Pub/Sub.
