Risoluzione degli errori di Dataflow

Se riscontri problemi con la pipeline o il job Dataflow, questo che elenca i messaggi di errore che potrebbero essere visualizzati e fornisce suggerimenti su come correggere ogni errore.

Errori nei tipi di log dataflow.googleapis.com/worker-startup. dataflow.googleapis.com/harness-startup e dataflow.googleapis.com/kubelet indicano problemi di configurazione di un job. Possono anche indicare condizioni che impediscono il funzionamento del normale percorso di logging.

La pipeline potrebbe generare eccezioni durante l'elaborazione dei dati. Alcuni di questi errori sono temporanei, ad esempio quando si ha difficoltà temporanee ad accedere a un del servizio. Alcuni di questi errori sono permanenti, ad esempio quelli causati da dati di input danneggiati o non analizzabili oppure puntatori nulli durante il calcolo.

Dataflow elabora gli elementi in bundle arbitrari e riprova il bundle completo quando viene generato un errore per un qualsiasi elemento del bundle. Quando in modalità batch, i pacchetti che includono un elemento con errori vengono ritentati quattro volte. Si verifica un errore completo della pipeline quando si verifica un errore del singolo bundle quattro volte. Quando in esecuzione in modalità flusso di dati, viene ritentato un bundle che include un elemento con errori a tempo indeterminato, il che potrebbe causare il blocco permanente della pipeline.

Eccezioni nel codice utente, ad esempio le istanze DoFn, sono segnalati nel Interfaccia di monitoraggio di Dataflow. Se esegui la pipeline con BlockingDataflowPipelineRunner, puoi anche vedere messaggi di errore stampati nella console o nella finestra del terminale.

Previeni gli errori nel codice aggiungendo gestori di eccezioni. Per Ad esempio, se vuoi eliminare elementi che non superano la convalida dell'input personalizzato fatto in un ParDo, usa un blocco trips/catch all'interno di ParDo per gestire e registrare l'elemento. Per i carichi di lavoro di produzione, implementa pattern del messaggio non elaborato. Per monitorare il numero di errori, utilizzi trasformazioni di aggregazione:

File di log mancanti

Se non vedi alcun log per i tuoi job, rimuovi gli eventuali filtri di esclusione contenenti resource.type="dataflow_step" da tutto il router dei log di Cloud Logging lavandini.

Vai al router dei log

Per saperne di più sulla rimozione delle esclusioni dei log, consulta Guida alla rimozione delle esclusioni.

Duplicati nell'output

Quando esegui un job Dataflow, l'output contiene duplicati record.

Questo problema può verificarsi quando il job Dataflow utilizza la classe modalità flusso di dati della pipeline "at-least-once". Questa modalità garantisce che i record elaborati almeno una volta. Tuttavia, in questa modalità sono possibili record duplicati.

Se il flusso di lavoro non è in grado di tollerare record duplicati, utilizza il metodo "exactly-once" modalità flusso di dati. In questa modalità, Dataflow garantisce che i record non vengano eliminati o duplicati mentre i dati si spostano attraverso la pipeline.

Per verificare quale modalità flusso di dati è in uso nel job, consulta Visualizza la modalità flusso di dati di un job.

Per ulteriori informazioni sulle modalità flusso di dati, vedi Imposta la modalità flusso di dati della pipeline.

Errori della pipeline

Le sezioni seguenti contengono errori comuni della pipeline che potresti riscontrare e i passaggi per risolverli o per risolvere gli errori.

Alcune API Cloud devono essere abilitate

Quando provi a eseguire un job Dataflow, si verifica il seguente errore:

Some Cloud APIs need to be enabled for your project in order for Cloud Dataflow to run this job.

Questo problema si verifica perché alcune API obbligatorie non sono abilitate nel tuo progetto.

Per risolvere il problema ed eseguire un job Dataflow, abilita quanto segue API Google Cloud nel tuo progetto:

  • API Compute Engine (Compute Engine)
  • API Cloud Logging
  • Cloud Storage
  • API Cloud Storage JSON
  • API BigQuery
  • Pub/Sub
  • API Datastore

Per istruzioni dettagliate, vedi Sezione Guida introduttiva all'abilitazione delle API Google Cloud .

"@*" e "@N" sono specifiche di sharding riservate

Quando provi a eseguire un job, nei file di log viene visualizzato il seguente errore e il job non va a buon fine:

Workflow failed. Causes: "@*" and "@N" are reserved sharding specs. Filepattern must not contain any of them.

Questo errore si verifica se il nome del file del percorso di Cloud Storage per file temporanei (tempLocation o temp_location) seguiti da una chiocciola (@) da un numero o da un asterisco (*).

Per risolvere il problema, modifica il nome del file in modo che venga seguito il simbolo @ da un carattere supportato.

Richiesta errata

Quando esegui un job Dataflow, Visualizzazione dei log di Cloud Monitoring una serie di avvisi simili ai seguenti:

Unable to update setup work item STEP_ID error: generic::invalid_argument: Http(400) Bad Request
Update range task returned 'invalid argument'. Assuming lost lease for work with id LEASE_ID
with expiration time: TIMESTAMP, now: TIMESTAMP. Full status: generic::invalid_argument: Http(400) Bad Request

Vengono visualizzati avvisi di richiesta errata se le informazioni sullo stato del worker sono obsolete o non sincronizzate a causa di ritardi nell'elaborazione. Spesso, il job Dataflow ha esito positivo nonostante gli avvisi di richiesta errata. In questo caso, ignora gli avvisi.

Impossibile leggere e scrivere in posizioni diverse

Quando esegui un job Dataflow, potresti visualizzare il seguente errore in i file di log:

message:Cannot read and write in different locations: source: SOURCE_REGION, destination: DESTINATION_REGION,reason:invalid

Questo errore si verifica quando l'origine e la destinazione si trovano in regioni diverse. it può verificarsi anche quando la posizione di gestione temporanea e la destinazione si trovano in diversi regioni. Ad esempio, se il job legge da Pub/Sub e poi scrive in una Cloud Storage temp prima di scrivere in una tabella BigQuery, Il bucket Cloud Storage temp e la tabella BigQuery devono essere in nella stessa regione.

Le località multiregionali sono considerate diverse dalle località a singola regione, anche se una singola regione rientra nell'ambito della località a più regioni. Ad esempio, us (multiple regions in the United States) e us-central1 sono regioni diverse.

Per risolvere il problema, fai in modo che le località di destinazione, origine e gestione temporanea siano in la stessa regione. Le località dei bucket Cloud Storage non possono essere modificate, quindi potrebbe essere necessario creare un nuovo bucket Cloud Storage nella regione corretta.

Timeout della connessione

Quando esegui un job Dataflow, potresti visualizzare il seguente errore nei file di log:

org.springframework.web.client.ResourceAccessException: I/O error on GET request for CONNECTION_PATH: Connection timed out (Connection timed out); nested exception is java.net.ConnectException: Connection timed out (Connection timed out)

Questo problema si verifica quando i worker Dataflow non riescono a stabilire o mantenere una connessione con l'origine dati o la destinazione.

Per risolvere il problema, segui questi passaggi per la risoluzione dei problemi:

  • Verifica che l'origine dati sia in esecuzione.
  • Verifica che la destinazione sia in esecuzione.
  • Esamina i parametri di connessione. utilizzata nella configurazione della pipeline Dataflow.
  • Verifica che i problemi di prestazioni non influiscano sull'origine o sulla destinazione.
  • Assicurati che le regole firewall non blocchino la connessione.

Oggetto non trovato

Quando esegui i job Dataflow, potresti visualizzare il seguente errore in i file di log:

..., 'server': 'UploadServer', 'status': '404'}>, <content <No such object:...

Questi errori in genere si verificano quando alcuni dei job Dataflow in esecuzione utilizza lo stesso temp_location per lo stage dei file di job temporanei creati quando delle esecuzioni della pipeline. Quando più job simultanei condividono lo stesso temp_location, questi job potrebbero penetrare sui dati temporanei l'uno dell'altro e una race condition potrebbe che si verificano. Per evitare questo problema, ti consigliamo di utilizzare un'istanza temp_location univoca per ogni job.

Dataflow non è in grado di determinare il backlog

Quando esegui una pipeline in modalità flusso da Pub/Sub, quanto segue si verifica un avviso:

Dataflow is unable to determine the backlog for Pub/Sub subscription

Quando una pipeline Dataflow estrae i dati da Pub/Sub, Dataflow deve richiedere ripetutamente informazioni in Pub/Sub. Queste informazioni includono l'importo del backlog dell'abbonamento e età del messaggio non confermato meno recente. Occasionalmente, Dataflow non è in grado di recuperare queste informazioni da Pub/Sub a causa di problemi di sistema interni, che potrebbero causare un di accumulo di backlog.

Per ulteriori informazioni, vedi Flusso di dati con Cloud Pub/Sub.

DEADLINE_EXCEEDED o il server non risponde

Quando esegui i job, potresti riscontrare eccezioni di timeout RPC o uno dei i seguenti errori:

DEADLINE_EXCEEDED

Oppure:

Server Unresponsive

In genere questi errori si verificano per uno dei seguenti motivi:

  • Nella rete Virtual Private Cloud (VPC) utilizzata per il job potrebbe mancare un regola firewall. La regola firewall deve abilitare tutto il traffico TCP tra le VM nella rete VPC specificato nelle opzioni della pipeline. Per ulteriori informazioni, vedi Regole firewall per Dataflow.

    In alcuni casi, i worker non sono in grado di comunicare tra loro. Quando esegui un job Dataflow che non utilizza Dataflow Shuffle o Streaming Engine, i worker devono comunicare tra loro tramite le porte TCP 12345 e 12346 all'interno della rete VPC. In questo scenario, l'errore include il nome del cablaggio worker e la porta TCP che viene bloccato. L'errore è simile a uno dei seguenti esempi:

    DEADLINE_EXCEEDED: (g)RPC timed out when SOURCE_WORKER_HARNESS
talking to DESTINATION_WORKER_HARNESS:12346.

    Rpc to WORKER_HARNESS:12345 completed with error UNAVAILABLE: failed to connect to all addresses
Server unresponsive (ping error: Deadline Exceeded, UNKNOWN: Deadline Exceeded...)

    Per risolvere il problema, utilizza gcloud compute firewall-rules create flag rules per consentire il traffico di rete alle porte 12345 e 12346. Nell'esempio che segue illustra il comando Google Cloud CLI:

    gcloud compute firewall-rules create FIREWALL_RULE_NAME \
  --network NETWORK \
  --action allow \
  --direction IN \
  --target-tags dataflow \
  --source-tags dataflow \
  --priority 0 \
  --rules tcp:12345-12346

    Sostituisci quanto segue:

    • FIREWALL_RULE_NAME: il nome della regola firewall
    • NETWORK: il nome della tua rete

  • Il job è associato allo shuffling.

    Per risolvere il problema, apporta una o più delle seguenti modifiche.

    Java

    • Se il job non utilizza lo shuffle basato su servizi, passa all'utilizzo Dataflow Shuffle basato su servizi per impostazione --experiments=shuffle_mode=service. Per dettagli e disponibilità, vedi Dataflow Shuffle.
    • Aggiungi altri lavoratori. Prova a impostare --numWorkers con un quando esegui la pipeline.
    • Aumenta le dimensioni del disco collegato per i worker. Prova a impostare --diskSizeGb con un valore più alto quando esegui la pipeline.
    • Utilizza un disco permanente supportato da SSD. Prova a impostare --workerDiskType="compute.googleapis.com/projects/PROJECT_ID/zones/ZONE/diskTypes/pd-ssd" quando esegui la pipeline.

    Python

    • Se il job non utilizza lo shuffle basato su servizi, passa all'utilizzo Dataflow Shuffle basato su servizi per impostazione --experiments=shuffle_mode=service. Per dettagli e disponibilità, vedi Dataflow Shuffle.
    • Aggiungi altri lavoratori. Prova a impostare --num_workers con un quando esegui la pipeline.
    • Aumenta le dimensioni del disco collegato per i worker. Prova a impostare --disk_size_gb con un valore più alto quando esegui la pipeline.
    • Utilizza un disco permanente supportato da SSD. Prova a impostare --worker_disk_type="compute.googleapis.com/projects/PROJECT_ID/zones/ZONE/diskTypes/pd-ssd" quando esegui la pipeline.

    Vai

    • Se il job non utilizza lo shuffle basato su servizi, passa all'utilizzo Dataflow Shuffle basato su servizi per impostazione --experiments=shuffle_mode=service. Per dettagli e disponibilità, vedi Dataflow Shuffle.
    • Aggiungi altri lavoratori. Prova a impostare --num_workers con un quando esegui la pipeline.
    • Aumenta le dimensioni del disco collegato per i worker. Prova a impostare --disk_size_gb con un valore più alto quando esegui la pipeline.
    • Utilizza un disco permanente supportato da SSD. Prova a impostare --disk_type="compute.googleapis.com/projects/PROJECT_ID/zones/ZONE/diskTypes/pd-ssd" quando esegui la pipeline.

Errori di codifica, IOEccezioni o comportamenti imprevisti nel codice utente

Gli SDK Apache Beam e i worker Dataflow dipendono componenti di terze parti. Questi componenti importano dipendenze aggiuntive. Versione le collisioni possono causare un comportamento imprevisto nel servizio. Inoltre, alcune librerie non sono compatibili con l'inoltro. Potresti dover bloccare le versioni elencate che sono nell'ambito durante l'esecuzione. SDK e dipendenze worker contiene un elenco di dipendenze con le versioni richieste.

Errore durante l'esecuzione di LookupEffectiveGuestPolicy

Quando esegui un job Dataflow, potresti visualizzare il seguente errore in i file di log:

OSConfigAgent Error policies.go:49: Error running LookupEffectiveGuestPolicies:
error calling LookupEffectiveGuestPolicies: code: "Unauthenticated",
message: "Request is missing required authentication credential.
Expected OAuth 2 access token, login cookie or other valid authentication credential.

Questo errore si verifica se OS Configuration Management è abilitato per l'intero progetto.

Per risolvere questo problema, disabilita VM Manager e i criteri applicabili all'intero progetto. Se disabiliti VM Manager non è possibile definire criteri per l'intero progetto, puoi ignorare questo errore e filtrarla dagli strumenti di monitoraggio dei log.

Pool di risorse esaurito

Quando crei una risorsa Google Cloud, potresti visualizzare il seguente errore per un pool di risorse esaurito:

ERROR: ZONE_RESOURCE_POOL_EXHAUSTED

Questo errore si verifica per condizioni temporanee di esaurimento scorte per una risorsa specifica in di una zona specifica.

Per risolvere il problema, puoi attendere o creare il la stessa risorsa in un'altra zona. Come best practice, ti consigliamo di a distribuire le risorse più zone e regioni per tollerare le interruzioni del servizio.

Java Runtime Environment ha rilevato un errore irreversibile

Durante l'avvio del worker si verifica il seguente errore:

A fatal error has been detected by the Java Runtime Environment

Questo errore si verifica se la pipeline utilizza Java Native Interface (JNI) per l'esecuzione il codice non Java e questo codice o le associazioni JNI contengono un errore.

Errore chiave dell'attributo googclient_deliveryattempt

Il job Dataflow ha esito negativo e genera uno dei seguenti errori:

The request contains an attribute key that is not valid (key=googclient_deliveryattempt). Attribute keys must be non-empty and must not begin with 'goog' (case-insensitive).

Oppure:

Invalid extensions name: googclient_deliveryattempt

Questo errore si verifica quando il job Dataflow ha quanto segue caratteristiche:

Questo errore si verifica perché quando utilizzi Pub/Sub Java o C# libreria client e un argomento messaggi non recapitabili per una sottoscrizione, tentativi nell'attributo del messaggio googclient_deliveryattempt anziché nel campo delivery_attempt. Per ulteriori informazioni, vedi Monitorare i tentativi di consegna nella sezione "Gestire gli errori dei messaggi" .

Per evitare questo problema, apporta una o più delle seguenti modifiche.

È stato rilevato un tasto di scelta rapida ...

Si verifica il seguente errore:

A hot key HOT_KEY_NAME was detected in...

Questi errori si verificano se i dati contengono una chiave di scelta rapida. Una scorciatoia è una chiave abbastanza elementi da influire negativamente sulle prestazioni della pipeline. Limite di queste chiavi la capacità di Dataflow di elaborare elementi in parallelo, aumenta il tempo di esecuzione.

Per stampare la chiave leggibile nei log quando viene rilevata una chiave di scelta rapida nel utilizza la pipeline opzione pipeline di scelta rapida.

Per risolvere il problema, verifica che i dati siano distribuiti uniformemente. Se una chiave ha molti valori sono sproporzionati, prendi in considerazione le seguenti azioni:

Per visualizzare le chiavi di scelta rapida nell'interfaccia di monitoraggio di Dataflow, consulta Risolvi i problemi relativi agli elementi in ritardo nei job batch.

Specifica della tabella non valida in Data Catalog

Quando utilizzi Dataflow SQL per creare job Dataflow SQL, il job potrebbe non riuscire con il seguente errore nei file di log:

Invalid table specification in Data Catalog: Could not resolve table in Data Catalog

Questo errore si verifica se l'account di servizio Dataflow non dispone l'accesso all'API Data Catalog.

Per risolvere il problema, abilitare l'API Data Catalog in Google Cloud progetto che stai utilizzando per scrivere ed eseguire query.

In alternativa, assegna il ruolo roles/datacatalog.viewer a Account di servizio Dataflow.

Il grafico del job è troppo grande

Il job potrebbe non riuscire con il seguente errore:

The job graph is too large. Please try again with a smaller job graph,
or split your job into two or more smaller jobs.

Questo errore si verifica se le dimensioni del grafico del job superano 10 MB. Determinati nella pipeline può causare il superamento del limite da parte del grafico del job. Comuni le condizioni includono:

  • Una trasformazione Create che include una grande quantità di dati in memoria.
  • Un'istanza DoFn di grandi dimensioni serializzata per la trasmissione al telecomando worker.
  • Un DoFn come istanza di classe interna anonima che (probabilmente inavvertitamente) estrae una grande quantità di dati da serializzare.
  • Un grafo diretto aciclico (DAG) viene utilizzato come parte di un loop di pubblicità programmatica che enumera un elenco lungo.

Per evitare queste condizioni, valuta la possibilità di ristrutturare la pipeline.

Commit chiave troppo grande

Quando esegui un job in modalità flusso, nel log worker viene visualizzato il seguente errore file:

KeyCommitTooLargeException

Questo errore si verifica negli scenari in modalità flusso quando viene eseguita una grande quantità di dati raggruppati senza utilizzare una trasformazione Combine o se viene eseguita una grande quantità di dati generate da un singolo elemento di input.

Per ridurre le possibilità di riscontrare questo errore, utilizza quanto segue: strategie:

  • Assicurati che l'elaborazione di un singolo elemento non possa generare output o stato modifiche superano il limite consentito.
  • Se più elementi sono stati raggruppati in base a una chiave, valuta la possibilità di aumentare la chiave per ridurre gli elementi raggruppati per chiave.
  • Se gli elementi di una chiave vengono emessi ad alta frequenza su un breve nel tempo, questo potrebbe generare molti GB di eventi per quella chiave nelle finestre. Riscrivi la pipeline per rilevare chiavi come questa ed emettere solo un output che indica che la chiave era presente spesso in quella finestra.
  • Usa le trasformazioni dello spazio sublineare Combine per le trasformazioni commutative e operazioni associate. Non utilizzare un combinatore se non riduce lo spazio. Per Ad esempio, il combinatore per le stringhe che si limita a unire le stringhe è peggiore rispetto a non utilizzare il combinatore.

Rifiuto dei messaggi di dimensioni superiori a 7168.000

Quando esegui un job Dataflow creato da un modello, potrebbe non riuscire e restituire il seguente errore:

Error: CommitWork failed: status: APPLICATION_ERROR(3): Pubsub publish requests are limited to 10MB, rejecting message over 7168K (size MESSAGE_SIZE) to avoid exceeding limit with byte64 request encoding.

Questo errore si verifica quando i messaggi scritti in una coda di messaggi non recapitabili superano le dimensioni di 7168 K. Come soluzione alternativa, abilita Motore di flussi di dati che prevede un limite di dimensioni più elevato. Per abilitare Streaming Engine, utilizza quanto segue opzione pipeline.

Java

--enableStreamingEngine=true

Python

--enable_streaming_engine=true

Request Entity Too Large (Dimensioni dell'entità richiesta eccessive)

Quando invii il job, nella console viene visualizzato uno dei seguenti errori oppure finestra del terminale:

413 Request Entity Too Large
The size of serialized JSON representation of the pipeline exceeds the allowable limit
Failed to create a workflow job: Invalid JSON payload received
Failed to create a workflow job: Request payload exceeds the allowable limit

Quando si verifica un errore relativo al payload JSON durante l'invio del job, la rappresentazione JSON della pipeline supera le dimensioni massime della richiesta di 20 MB.

La dimensione del job è legata alla rappresentazione JSON del una pipeline o un blocco note personalizzato. Una pipeline più grande significa una richiesta più grande. Dataflow prevede un limite che limita le richieste a 20 MB.

Per stimare le dimensioni della richiesta JSON della pipeline, eseguila con la seguente opzione:

Java

--dataflowJobFile=PATH_TO_OUTPUT_FILE

Python

--dataflow_job_file=PATH_TO_OUTPUT_FILE

Vai

L'output del job come JSON non è supportato in Go.

Questo comando scrive una rappresentazione JSON del job in un file. Le dimensioni il file serializzato è una stima accurata delle dimensioni della richiesta. Le dimensioni effettive è leggermente più grande a causa di alcune informazioni aggiuntive incluse nella richiesta.

Determinate condizioni nella pipeline possono causare il superamento della rappresentazione JSON il limite. Le condizioni comuni includono:

  • Una trasformazione Create che include una grande quantità di dati in memoria.
  • Un'istanza DoFn di grandi dimensioni serializzata per la trasmissione al telecomando worker.
  • Un DoFn come istanza anonima della classe interna che (probabilmente inavvertitamente) estrae una grande quantità di dati da serializzare.

Per evitare queste condizioni, valuta la possibilità di ristrutturare la pipeline.

Le opzioni della pipeline dell'SDK o l'elenco dei file temporanei superano il limite di dimensioni

Quando esegui una pipeline, si verifica uno dei seguenti errori:

SDK pipeline options or staging file list exceeds size limit.
Please keep their length under 256K Bytes each and 512K Bytes in total.

Oppure:

Value for field 'resource.properties.metadata' is too large: maximum size

Questi errori si verificano se non è stato possibile avviare la pipeline a causa di Superamento dei limiti di metadati di Compute Engine. Questi limiti non possono essere modificati. Dataflow utilizza i metadati di Compute Engine per le opzioni della pipeline. La è documentato nei metadati personalizzati di Compute Engine limitazioni.

Nei seguenti scenari, la rappresentazione JSON può superare il limite:

  • Troppi file JAR da inserire nello stage.
  • Il campo della richiesta sdkPipelineOptions è troppo grande.

Per stimare le dimensioni della richiesta JSON della pipeline, eseguila con la seguente opzione:

Java

--dataflowJobFile=PATH_TO_OUTPUT_FILE

Python

--dataflow_job_file=PATH_TO_OUTPUT_FILE

Vai

L'output del job come JSON non è supportato in Go.

Le dimensioni del file di output da questo comando devono essere inferiori a 256 kB. I 512 kB nel messaggio di errore si riferiscono alla dimensione totale del e le opzioni dei metadati personalizzati per l'istanza VM di Compute Engine.

Puoi ottenere una stima approssimativa dell'opzione di metadati personalizzati per un'istanza VM da dei job Dataflow nel progetto. Scegli qualsiasi tipo di corsa del job Dataflow. Prendi un'istanza VM e poi vai al pagina dei dettagli dell'istanza VM di Compute Engine per quella VM, in modo da verificare la presenza dei metadati. La lunghezza totale dei metadati personalizzati e del file deve essere inferiore a 512 kB. Non è possibile una stima accurata per il job non riuscito perché le VM non vengono avviate per job non riusciti.

Se il tuo elenco JAR sta raggiungendo il limite di 256 kB, controllalo e riduci le dimensioni non necessari. Se è ancora troppo grande, prova a eseguire il comando Job Dataflow utilizzando un'uber JAR. Ad esempio, spiega come creare e utilizzare Uber JAR, Crea ed esegui il deployment di un'JAR Uber.

Se il campo della richiesta sdkPipelineOptions è troppo grande, includi la seguente opzione quando esegui la pipeline. L'opzione pipeline è la stessa per Java, Python e Go.

--experiments=no_display_data_on_gce_metadata

Chiave casuale troppo grande

Nei file di log del worker viene visualizzato il seguente errore:

Shuffle key too large

Questo errore si verifica se la chiave serializzata emessa in un determinato (Co-)GroupByKey è troppo grande dopo l'applicazione del programmatore corrispondente. Dataflow ha un limite per le chiavi di shuffling serializzate.

Per risolvere il problema, riduci le dimensioni delle chiavi o utilizza uno spazio più efficiente programmatori.

Per ulteriori informazioni, consulta i limiti di produzione per Dataflow.

Il numero totale di oggetti BoundedSource ... è maggiore del limite consentito

Durante l'esecuzione di job con Java potrebbe verificarsi uno dei seguenti errori:

Total number of BoundedSource objects generated by splitIntoBundles() operation is larger than the allowable limit

Oppure:

Total size of the BoundedSource objects generated by splitIntoBundles() operation is larger than the allowable limit

Java

Questo errore può verificarsi se leggi da un numero molto elevato di file utilizzando TextIO, AvroIO, BigQueryIO tramite EXPORT o altri tipi di file sorgente. Il limite specifico dipende dai dettagli dell'origine, ma sono nell'ordine delle decine di migliaia di file in una pipeline. Ad esempio: lo schema di incorporamento in AvroIO.Read consente meno file.

Questo errore può verificarsi anche se hai creato un'origine dati personalizzata per pipeline e il metodo splitIntoBundles dell'origine hanno restituito un elenco di BoundedSource oggetti che, se serializzati, occupano più di 20 MB.

Il limite consentito per la dimensione totale degli oggetti BoundedSource generato dall'operazione splitIntoBundles() della tua origine personalizzata è 20 MB

Per aggirare questa limitazione, apporta una delle seguenti modifiche:

  1. Attiva Runner V2. Runner v2 converte le origini in DoFns suddivisibili che non hanno questo limite di suddivisione dell'origine.

  2. Modifica la sottoclasse BoundedSource personalizzata in modo che la dimensione totale il numero di oggetti BoundedSource generati è inferiore al limite di 20 MB. Per Ad esempio, l'origine potrebbe inizialmente generare meno suddivisioni e fare affidamento Ribilanciamento dinamico del lavoro per suddividere ulteriormente gli input on demand.

NameError

Quando esegui la pipeline utilizzando il servizio Dataflow, si verifica il seguente errore:

NameError

Questo errore non si verifica quando esegui localmente, ad esempio quando utilizzando l'DirectRunner.

Questo errore si verifica se i tuoi DoFn utilizzano valori nello spazio dei nomi globale che non sono disponibili sul worker Dataflow.

Per impostazione predefinita, le importazioni globali, le funzioni e le variabili sono definite nella sessione principale non vengono salvati durante la serializzazione di un job Dataflow.

Per risolvere il problema, utilizza uno dei seguenti metodi. Se i tuoi DoFn sono definiti nel file principale e fa riferimento alle importazioni e alle funzioni nella imposta l'opzione pipeline --save_main_session su True. Questa modifica sottrae lo stato dello spazio dei nomi globale e lo carica Worker Dataflow.

Se nello spazio dei nomi globale sono presenti oggetti che non possono essere deprecati, viene eseguito si verifica un errore. Se l'errore riguarda un modulo che dovrebbe essere disponibile nel nella distribuzione Python, importa il modulo localmente, dove viene utilizzato.

Ad esempio, invece di:

import re
…
def myfunc():
  # use re module

usa:

def myfunc():
  import re
  # use re module

In alternativa, se i tuoi DoFn coprono più file, usa un approccio diverso alla pacchettizzazione del flusso di lavoro gestione delle dipendenze.

Elaborazione bloccata o operazione in corso

Se Dataflow trascorre più tempo a eseguire un'DoFn rispetto al tempo specificato in TIME_INTERVAL senza restituire, viene visualizzato il seguente messaggio.

Java

Uno dei due messaggi di log seguenti, a seconda della versione:

Processing stuck in step STEP_NAME for at least TIME_INTERVAL

Operation ongoing in bundle BUNDLE_ID for at least TIME_INTERVAL without outputting or completing: at STACK_TRACE

Python

Operation ongoing for over TIME_INTERVAL in state STATE in step STEP_ID without returning. Current Traceback: TRACEBACK

Vai

Operation ongoing in transform TRANSFORM_ID for at least TIME_INTERVAL without outputting or completing in state STATE

Questo comportamento ha due possibili cause:

  • Il codice DoFn è lento o in attesa di operazioni esterne lente per completare l'operazione.
  • Il codice di DoFn potrebbe essere bloccato, bloccato o insolitamente lento da completare e l'elaborazione dei dati.

Per determinare quale sia il caso, espandi la Voce di log di Cloud Monitoring in per visualizzare un'analisi dello stack. Cerca i messaggi che indicano che il codice DoFn è bloccato o incontrare problemi. Se non sono presenti messaggi, il problema potrebbe essere la velocità di esecuzione del codice DoFn. Valuta l'uso Cloud Profiler o un altro strumento per analizza le prestazioni del codice.

Se la tua pipeline è creata sulla VM Java (utilizzando Java o Scala), puoi indaga sulla causa del codice bloccato. Esegui un dump completo del thread l'intera JVM (non solo il thread bloccato) seguendo questi passaggi:

  1. Prendi nota del nome del worker nella voce di log.
  2. Nella sezione Compute Engine della console Google Cloud, trova l'istanza Compute Engine con il nome worker che hai annotato.
  3. Utilizza SSH per connetterti all'istanza con quel nome.

  4. Esegui questo comando:

    curl http://localhost:8081/threadz

Errori di quota Pub/Sub

Quando esegui una pipeline in modalità flusso da Pub/Sub, quanto segue che si verificano:

429 (rateLimitExceeded)

Oppure:

Request was throttled due to user QPS limit being reached

Questi errori si verificano se il progetto non è sufficiente Quota Pub/Sub.

Per sapere se la quota del progetto è insufficiente, segui questi passaggi per controllare per gli errori del client:

  1. Vai alla console Google Cloud.
  2. Nel menu a sinistra, seleziona API e Google Cloud.
  3. Nella casella di ricerca, cerca Cloud Pub/Sub.
  4. Fai clic sulla scheda Utilizzo.
  5. Controlla Codici di risposta e cerca i codici di errore del client (4xx).

La richiesta è vietata dai criteri dell'organizzazione

Quando esegui una pipeline, si verifica il seguente errore:

Error trying to get gs://BUCKET_NAME/FOLDER/FILE:
{"code":403,"errors":[{"domain":"global","message":"Request is prohibited by organization's policy","reason":"forbidden"}],
"message":"Request is prohibited by organization's policy"}

Questo errore si verifica se il bucket Cloud Storage si trova all'esterno perimetro di servizio.

Per risolvere il problema, crea una regola di traffico in uscita che consente al bucket all'esterno del perimetro di servizio.

Il pacchetto temporaneo non è accessibile

I job che hanno avuto esito positivo potrebbero non riuscire con il seguente errore:

Staged package...is inaccessible

Per risolvere il problema:

  • Verifica che il bucket Cloud Storage utilizzato per la gestione temporanea non abbia Impostazioni TTL che determinano la pubblicazione di pacchetti eliminati.

  • Verifica che l'account di servizio worker del progetto Dataflow dispone dell'autorizzazione per accedere al bucket Cloud Storage utilizzato gestione temporanea. Le lacune nelle autorizzazioni possono essere dovute a uno dei seguenti motivi:

    • Il bucket Cloud Storage utilizzato per la gestione temporanea è presente in un progetto diverso.
    • È stata eseguita la migrazione del bucket Cloud Storage utilizzato per la gestione temporanea da un accesso granulare accesso uniforme a livello di bucket. A causa dell'incoerenza tra i criteri IAM e ACL, la migrazione del bucket gestione temporanea all'accesso uniforme a livello di bucket non consente ACL per le risorse Cloud Storage. Gli ACL includono autorizzazioni dell'account di servizio worker del tuo progetto Dataflow sul bucket gestione temporanea.

Per ulteriori informazioni, vedi Accesso ai bucket Cloud Storage nei progetti Google Cloud.

Un elemento di lavoro ha avuto esito negativo per 4 volte

L'errore seguente si verifica in caso di errore di un job batch:

The job failed because a work item has failed 4 times.

Questo errore si verifica se una singola operazione in un job batch comporta l'errore del codice worker volte. Dataflow non riesce a completare il job e viene visualizzato questo messaggio.

Durante l'esecuzione in modalità flusso di dati, viene effettuato un nuovo tentativo per un bundle che include un elemento con errori a tempo indeterminato, il che potrebbe causare il blocco permanente della pipeline.

Non puoi configurare questa soglia di errore. Per ulteriori dettagli, consulta gestione degli errori della pipeline e delle eccezioni.

Per risolvere il problema, cerca nel Cloud Monitoring log del job per e quattro singoli errori. Nei log del worker, cerca il log a livello di errore o a livello di errore. che mostrano eccezioni o errori. L'eccezione dovrebbe essere visualizzato almeno quattro volte. Se i log contengono solo errori di timeout relativi all'accesso a risorse esterne, come MongoDB, che l'account di servizio worker sia autorizzato ad accedere alla subnet della risorsa.

Timeout nel file dei risultati di polling

In caso di errore di un job, si verifica quanto segue:

Timeout in polling result file: PATH. Possible causes are:
1. Your launch takes too long time to finish. Please check the logs on stackdriver.
2. Service account SERVICE_ACCOUNT may not have enough permissions to pull
container image IMAGE_PATH or create new objects in PATH.
3. Transient errors occurred, please try again.

Il problema è spesso correlato all'installazione delle dipendenze Python usando il file requirements.txt. Lo stager Apache Beam scarica il codice sorgente da tutte le dipendenze da PyPi, incluse le origini delle dipendenze transitive. La compilazione di wheel viene quindi implicita durante il download di pip per alcuni dei pacchetti Python che sono dipendenze di apache-beam. Potrebbe verificarsi un problema di timeout a causa del file requirements.txt.

Per ulteriori informazioni, vedi del team Apache Arrow che monitora il problema. La soluzione alternativa suggerita consiste nell'installare apache-beam direttamente nel Dockerfile. In questo modo, il timeout per il file requirements.txt non è applicata.

Scrittura/scrittura/scrittura/scrittura corretta del file/preFinalizzazione non riuscita

Durante l'esecuzione di un job, il job non riesce a intermittenza e si verifica il seguente errore:

Workflow failed. Causes: S27:Write Correct File/Write/WriteImpl/PreFinalize failed., Internal Issue (ID): ID:ID, Unable to expand file pattern gs://BUCKET_NAME/temp/FILE

Questo errore si verifica quando viene utilizzata la stessa sottocartella come posizione di archiviazione temporanea per più job eseguiti contemporaneamente.

Per risolvere il problema, non utilizzare la stessa sottocartella dello spazio di archiviazione temporaneo per più pipeline. Per ogni pipeline, fornisci una sottocartella univoca da utilizzare come posizione di archiviazione temporanea.

L'elemento supera le dimensioni massime del messaggio protobuf

Quando esegui job Dataflow e la tua pipeline contiene elementi di grandi dimensioni, potresti visualizzare errori simili ai seguenti esempi:

Exception serializing message!
ValueError: Message org.apache.beam.model.fn_execution.v1.Elements exceeds maximum protobuf size of 2GB

Oppure:

Buffer size ... exceeds GRPC limit 2147483548. This is likely due to a single element that is too large.

Potresti anche vedere un avviso simile al seguente esempio:

Data output stream buffer size ... exceeds 536870912 bytes. This is likely due to a large element in a PCollection.

Questi errori si verificano quando la pipeline contiene elementi di grandi dimensioni.

Per risolvere questo problema, se utilizzi l'SDK Python, esegui l'upgrade ad Apache Beam versione 2.57.0 o successiva. Le versioni 2.57.0 e successive dell'SDK Python consentono di migliorare l'elaborazione di elementi di grandi dimensioni e aggiungere il logging pertinente.

Se gli errori persistono dopo l'upgrade o se non utilizzi l'SDK Python, identificare il passaggio del job in cui si verifica l'errore, e prova a ridurre le dimensioni degli elementi in quel passaggio.

Quando PCollection oggetti nella pipeline hanno elementi di grandi dimensioni, i requisiti di RAM per la pipeline aumentano. Anche elementi di grandi dimensioni possono causare errori di runtime, soprattutto quando superano i confini delle fasi unite.

Possono verificarsi elementi di grandi dimensioni quando una pipeline materializza inavvertitamente iterabile. Ad esempio, una pipeline che passa l'output un'operazione GroupByKey in un'operazione Reshuffle non necessaria materializza gli elenchi come singoli elementi. Questi elenchi potrebbero contenere un numero elevato di valori per ogni chiave.

Se l'errore si verifica in un passaggio che utilizza un input aggiuntivo, tieni presente che l'uso possono introdurre una barriera di fusione. Controlla se la trasformazione che produce un elemento di grandi dimensioni e la che la consuma appartiene alla stessa fase.

Quando crei la pipeline, segui queste best practice:

  • In PCollections, utilizza più elementi piccoli anziché un singolo elemento grande.
  • Archiviare BLOB di grandi dimensioni in sistemi di archiviazione esterni. Usa PCollections per passare i propri metadati o utilizzare un programmatore personalizzato che riduce le dimensioni dell'elemento.
  • Se devi passare una PCollection che può superare i 2 GB come input aggiuntivo, utilizza viste iterabili, come AsIterable e AsMultiMap.

La dimensione massima di un singolo elemento in un job Dataflow è limitato a 2 GB. Per ulteriori informazioni, vedi Quote e limiti.

Archivia errori del job

Le seguenti sezioni contengono errori comuni che potresti riscontrare quando prova ad archiviare un job Dataflow utilizzando l'API.

Nessun valore fornito

Quando provi ad archiviare un job Dataflow utilizzando l'API, viene restituito potrebbe verificarsi un errore:

The field mask specifies an update for the field job_metadata.user_display_properties.archived in job JOB_ID, but no value is provided. To update a field, please provide a field for the respective value.

Questo errore si verifica per uno dei seguenti motivi:

  • Il percorso specificato per il campo updateMask non è nel formato corretto. Questo problema può verificarsi a causa di errori di battitura.

  • La JobMetadata non è specificato correttamente. Nel campo JobMetadata, per userDisplayProperties, utilizza la coppia chiave-valore "archived":"true".

Per risolvere questo errore, verifica che che passi all'API sia nel formato richiesto. Per ulteriori dettagli, consulta Archiviare un job.

L'API non riconosce il valore

Quando provi ad archiviare un job Dataflow utilizzando l'API, viene restituito potrebbe verificarsi un errore:

The API does not recognize the value VALUE for the field job_metadata.user_display_properties.archived for job JOB_ID. REASON: Archived display property can only be set to 'true' or 'false'

Questo errore si verifica quando il valore fornito nella coppia chiave-valore dei job di archiviazione non è un supportato. I valori supportati per la coppia chiave-valore dei job di archiviazione sono "archived":"true" e "archived":"false".

Per risolvere questo errore, verifica che che passi all'API sia nel formato richiesto. Per ulteriori dettagli, consulta Archiviare un job.

Impossibile aggiornare stato e maschera

Quando provi ad archiviare un job Dataflow utilizzando l'API, viene restituito potrebbe verificarsi un errore:

Cannot update both state and mask.

Questo errore si verifica quando provi ad aggiornare sia stato del job e l'archivio nella stessa chiamata API. Non puoi aggiornare sia lo stato del job sia updateMask nella stessa chiamata API.

Per risolvere questo errore, aggiorna lo stato del job in una chiamata API separata. Apporta aggiornamenti allo stato del job prima di aggiornare lo stato di archiviazione del job.

Modifica del flusso di lavoro non riuscita

Quando provi ad archiviare un job Dataflow utilizzando l'API, viene restituito potrebbe verificarsi un errore:

Workflow modification failed.

Questo errore di solito si verifica quando tenti di archiviare un job in esecuzione.

Per risolvere questo errore, attendi il completamento del job prima di archiviarlo. I job completati hanno uno dei seguenti valori: stati lavoro:

  • JOB_STATE_CANCELLED
  • JOB_STATE_DRAINED
  • JOB_STATE_DONE
  • JOB_STATE_FAILED
  • JOB_STATE_UPDATED

Per ulteriori informazioni, vedi Rileva il completamento del job Dataflow.

Errori nell'immagine container

Le seguenti sezioni contengono errori comuni che potresti riscontrare durante l'utilizzo di container personalizzati e i passaggi per risolvere gli errori. La gli errori sono in genere preceduti dal messaggio seguente:

Unable to pull container image due to error: DETAILED_ERROR_MESSAGE

Autorizzazione "containeranalysis.realtimes.list" rifiutato

Nei file di log viene visualizzato il seguente errore:

Error getting old patchz discovery occurrences: generic::permission_denied: permission "containeranalysis.occurrences.list" denied for project "PROJECT_ID", entity ID "" [region="REGION" projectNum=PROJECT_NUMBER projectID="PROJECT_ID"]

per l'analisi delle vulnerabilità è necessaria l'API Container Analysis.

Per ulteriori informazioni, vedi Panoramica della scansione del sistema operativo e Configurazione del controllo dell'accesso nella documentazione di Artifact Analysis.

Errore di sincronizzazione del pod ... non riuscito in "StartContainer"

Durante l'avvio del worker si verifica il seguente errore:

Error syncing pod POD_ID, skipping: [failed to "StartContainer" for CONTAINER_NAME with CrashLoopBackOff: "back-off 5m0s restarting failed container=CONTAINER_NAME pod=POD_NAME].

Un pod è un gruppo distribuito di container Docker in esecuzione su un Worker Dataflow. Questo errore si verifica quando uno dei deployment dei container nel pod non viene avviato. Se l'errore non è recuperabile, Il worker Dataflow non è in grado di avviarsi e Dataflow alla fine dei job batch non riescono e vengono generati errori come i seguenti:

The Dataflow job appears to be stuck because no worker activity has been seen in the last 1h.

Questo errore si verifica in genere quando uno dei container ha un arresto anomalo continuo durante l'avvio.

Per comprendere la causa principale, cerca i log acquisiti immediatamente prima dell'errore. Per analizzare i log, utilizza Esplora log. In Esplora log, limita i file di log alle voci di log emesse dal con errori di avvio del container. Per limitare le voci di log, completa la seguenti passaggi:

  1. In Esplora log, individua la voce di log Error syncing pod.
  2. Per visualizzare le etichette associate alla voce di log, espandi la voce di log.
  3. Fai clic sull'etichetta associata a resource_name, quindi fai clic su Mostra voci corrispondenti.

La pagina Esplora log in cui sono evidenziati i passaggi per limitare i file di log.

In Esplora log, i log di Dataflow sono organizzati in diversi flussi di log. Il messaggio Error syncing pod viene emesso nel log denominato kubelet. Tuttavia, i log del container in errore potrebbero trovarsi in una flusso di log. Ogni container ha un nome. Utilizza la seguente tabella per determinare quale flusso di log potrebbe contenere i log relativi al container in errore.

Nome container Nomi log
sdk, sdk0, sdk1, sdk-0-0 e simili docker
imbracatura cablaggio, avvio-bracciale
python, java-batch, flusso java avvio-lavoro, worker
artefatto artefatto

Quando esegui una query su Esplora log, assicurati che la query includa i nomi log pertinenti nell'interfaccia di Query Builder o non presenta restrizioni sul nome del log.

Una query di Esplora log che include i nomi dei log pertinenti.

Dopo aver selezionato i log pertinenti, il risultato della query potrebbe essere simile a nell'esempio seguente:

resource.type="dataflow_step"
resource.labels.job_id="2022-06-29_08_02_54-JOB_ID"
labels."compute.googleapis.com/resource_name"="testpipeline-jenkins-0629-DATE-cyhg-harness-8crw"
logName=("projects/apache-beam-testing/logs/dataflow.googleapis.com%2Fdocker"
OR
"projects/apache-beam-testing/logs/dataflow.googleapis.com%2Fworker-startup"
OR
"projects/apache-beam-testing/logs/dataflow.googleapis.com%2Fworker")

Poiché a volte i log che segnalano il sintomo dell'errore del container segnalato come INFO, includi i log INFO nell'analisi.

Le cause tipiche degli errori dei container includono quanto segue:

  1. La tua pipeline Python ha dipendenze aggiuntive installate runtime e l'installazione non riesce. Potresti visualizzare errori quali pip install failed with error. Questo problema potrebbe verificarsi a causa di conflitti o a causa di una configurazione di rete limitata che impedisce a un worker Dataflow dal estrarre una dipendenza esterna da un un repository pubblico su internet.

  2. Un worker non funziona nel mezzo dell'esecuzione della pipeline a causa di un'esaurimento della memoria . Potresti visualizzare un errore simile a uno dei seguenti:

    • java.lang.OutOfMemoryError: Java heap space
    • Shutting down JVM after 8 consecutive periods of measured GC thrashing. Memory is used/total/max = 24453/42043/42043 MB, GC last/max = 58.97/99.89 %, #pushbacks=82, gc thrashing=true. Heap dump not written.

    Per eseguire il debug di un problema di memoria esaurita, consulta Risolvere i problemi di esaurimento della memoria di Dataflow.

  3. Dataflow non è in grado di eseguire il pull dell'immagine container. Per ulteriori informazioni le informazioni, vedi Richiesta di pull dell'immagine non riuscita con errore.

  4. Il container utilizzato non è compatibile con l'architettura della CPU della VM worker. Nei log di avvio del cablaggio, potrebbe essere visualizzato un errore simile al seguente: exec /opt/apache/beam/boot: exec format error. Per controllare il container dell'architettura dell'immagine, esegui docker image inspect $IMAGE:$TAG e cerca Architecture parola chiave. Se è indicato Error: No such image: $IMAGE:$TAG, potresti dover prima eseguire il pull dell'immagine eseguendo docker pull $IMAGE:$TAG. Per informazioni sulla creazione di immagini con più architetture, vedi Crea un'immagine container con più architetture.

Dopo aver identificato l'errore che causa il mancato funzionamento del container, prova a risolvere il problema e poi invia nuovamente la pipeline.

Richiesta di pull dell'immagine non riuscita con errore

Durante l'avvio del worker, nel worker o nel job viene visualizzato uno dei seguenti errori log:

Image pull request failed with error

pull access denied for IMAGE_NAME

manifest for IMAGE_NAME not found: manifest unknown: Failed to fetch

Get IMAGE_NAME: Service Unavailable

Questi errori si verificano se un worker non è in grado di avviarsi perché non può eseguire il pull di un'immagine container Docker. Questo problema si verifica nei seguenti scenari:

  • L'URL dell'immagine del container SDK personalizzato non è corretto
  • Il worker non ha le credenziali o l'accesso alla rete all'immagine remota

Per risolvere il problema:

  • Se utilizzi un'immagine container personalizzata con il tuo job, verifica che l'URL dell'immagine sia corretto e abbia un tag o un digest valido. La Anche i worker Dataflow hanno bisogno di accedere all'immagine.
  • Verifica che il pull delle immagini pubbliche possa essere eseguito localmente eseguendo docker pull $image da una macchina non autenticata.

Per immagini private o worker privati:

  • Se utilizzi Container Registry per l'hosting dell'immagine container, ti consigliamo di usare Artifact Registry. Comunicazione Il 15 maggio 2023 Container Registry è deprecato. Se utilizzi Container Registry, puoi transizione ad Artifact Registry. Se le immagini si trovano in un progetto diverso rispetto a quello usato per eseguire il job Google Cloud, configurare il controllo dell'accesso l'account di servizio predefinito di Google Cloud.
  • Se utilizzi un VPC condiviso, assicurati che i worker può accedere al container personalizzato dell'host del repository.
  • Utilizza ssh per connetterti a una VM worker job in esecuzione ed esegui docker pull $image per confermare direttamente che il worker è configurato correttamente.

Se i worker si verificano diverse volte di seguito a causa di questo errore e il lavoro è iniziato il un job può non riuscire e viene restituito un errore simile al seguente messaggio:

Job appears to be stuck.

Se rimuovi l'accesso all'immagine mentre il job è in esecuzione, puoi rimuovere l'immagine stessa o la revoca del worker Dataflow le credenziali dell'account di servizio o l'accesso a internet per accedere alle immagini; Solo Dataflow log degli errori. Dataflow non fallisce il job. Dataflow evita anche il malfunzionamento di pipeline di flusso a lunga esecuzione per evitare di perdere lo stato della pipeline.

Altri possibili errori possono derivare da problemi o interruzioni delle quote del repository. Se riscontrano problemi che superano Quota di Docker Hub per il pull di immagini pubbliche o per eventuali interruzioni dei repository di terze parti, considera utilizzando Artifact Registry come repository di immagini.

Errore di sistema: codice operativo sconosciuto

La pipeline del container personalizzato Python potrebbe avere esito negativo con il seguente errore subito dopo l'invio del job:

SystemError: unknown opcode

Inoltre, l'analisi dello stack potrebbe includere

apache_beam/internal/pickler.py

Per risolvere questo problema, verifica che la versione Python che stai utilizzando localmente corrisponde alla versione dell'immagine container fino alla versione principale e secondaria. La differenza nella versione patch, ad esempio 3.6.7 rispetto alla 3.6.8, non crea o problemi di compatibilità. La differenza nella versione secondaria, ad esempio 3.6.8 rispetto 3.8.2 può causare errori nella pipeline.

Errori worker

Le seguenti sezioni contengono errori del worker comuni che potresti riscontrare. i passaggi per risolvere gli errori o risolverli.

La chiamata dal cablaggio del worker Java al DoFn Python non riesce e restituisce un errore

Se una chiamata dal cablaggio del worker Java a un DoFn Python non va a buon fine, viene restituito .

Per esaminare l'errore, espandi la sezione Log degli errori di Cloud Monitoring ed esaminare il messaggio di errore e il traceback. Ti mostra il codice non è andato a buon fine, puoi correggerlo se necessario. Se ritieni che l'errore sia un bug di Apache Beam o Dataflow, segnala il bug.

EOFError: dati marshal troppo brevi

Nei log del worker viene visualizzato il seguente errore:

EOFError: marshal data too short

Questo errore a volte si verifica quando i worker della pipeline Python esauriscono lo spazio su disco.

Per risolvere il problema, vedi Spazio esaurito sul dispositivo.

Impossibile collegare il disco

Quando provi ad avviare un job Dataflow che utilizza VM C3 con Persistent Disk, il job non va a buon fine e restituisce uno o entrambi i seguenti errori:

Failed to attach disk(s), status: generic::invalid_argument: One or more operations had an error

Can not allocate sha384 (reason: -2), Spectre V2 : WARNING: Unprivileged eBPF is enabled with eIBRS on...

Questi errori si verificano quando utilizzi le VM C3 con un tipo di Persistent Disk non supportato. Per ulteriori informazioni, vedi Tipi di disco supportati per C3.

Per utilizzare le VM C3 con il tuo job Dataflow, scegli il Tipo di disco worker pd-ssd. Per ulteriori informazioni, vedi Opzioni a livello di worker.

Java

--workerDiskType=pd-ssd

Python

--worker_disk_type=pd-ssd

Vai

disk_type=pd-ssd

Spazio esaurito sul dispositivo

Quando un job esaurisce lo spazio su disco, potrebbe essere visualizzato il seguente errore nella log dei worker:

No space left on device

Questo errore può verificarsi per uno dei seguenti motivi:

  • L'archiviazione permanente dei worker esaurisce lo spazio libero, cosa che può verificarsi per per uno dei seguenti motivi:
    • Un job scarica grandi dipendenze in fase di runtime
    • Un job utilizza container personalizzati di grandi dimensioni
    • Un job scrive molti dati temporanei sul disco locale
  • Quando si utilizza Dataflow Shuffle, Set Dataflow di dimensioni predefinite del disco inferiori. Di conseguenza, questo errore potrebbe verificarsi con lo spostamento dei job dall'ambiente shuffling.
  • Il disco di avvio del worker si riempie perché sta registrando più di 50 voci per secondo.

Per risolvere il problema, segui questi passaggi per la risoluzione dei problemi:

Per vedere le risorse del disco associate a un singolo worker, cerca un'istanza VM per le VM worker associate al job. Parte dello spazio su disco è consumato dal sistema operativo, da binari, log e container.

Per aumentare lo spazio su disco permanente o di avvio, regola il valore opzione pipeline di dimensione del disco.

Tieni traccia dell'utilizzo dello spazio su disco nelle istanze VM worker tramite Cloud Monitoring. Consulta Ricevi metriche delle VM worker dall'agente Monitoring per istruzioni sulla procedura di configurazione.

Cerca problemi di spazio su disco di avvio Visualizzazione dell'output della porta seriale sulle istanze VM worker e alla ricerca di messaggi come:

Failed to open system journal: No space left on device

Se hai molte istanze VM worker, puoi creare uno script esegui gcloud compute instances get-serial-port-output su tutti contemporaneamente. Puoi invece rivedere questo output.

La pipeline Python ha esito negativo dopo un'ora di inattività del worker

Quando utilizzi l'SDK Apache Beam per Python con Dataflow Runner V2 sulle macchine worker con molti core della CPU, utilizza Apache Beam SDK 2.35.0 o versioni successive. Se il tuo job utilizza un container personalizzato, usa Apache Beam SDK 2.46.0 o versioni successive.

Valuta la possibilità di pre-creare il tuo container Python. Questo passaggio può migliorare la VM tempi di avvio e prestazioni della scalabilità automatica orizzontale. Per usare questa abilita l'API Cloud Build sul tuo progetto e invia la pipeline con il seguente parametro:

‑‑prebuild_sdk_container_engine=cloud_build.

Per ulteriori informazioni, vedi Dataflow Runner V2.

Puoi anche Utilizza un'immagine container personalizzata con tutte le dipendenze preinstallate.

L'avvio del pool di worker nella zona non è riuscito a richiamare uno dei worker desiderati

Si verifica il seguente errore:

Startup of the worker pool in zone ZONE_NAME failed to bring up any of the desired NUMBER workers.
The project quota may have been exceeded or access control policies may be preventing the operation;
review the Cloud Logging 'VM Instance' log for diagnostics.

Questo errore si verifica per uno dei seguenti motivi:

  • Hai superato una delle quote di Compute Engine consentite da Dataflow della creazione dei worker.
  • La tua organizzazione ha vincoli che proibiscono alcuni aspetti del processo di creazione delle istanze VM, come l'account in uso o la zona target.

Per risolvere il problema, segui questi passaggi per la risoluzione dei problemi:

Esamina il log delle istanze VM

  1. Vai al visualizzatore Cloud Logging
  2. Nell'elenco a discesa Risorsa controllata, seleziona Istanza VM.
  3. Nell'elenco a discesa Tutti i log, seleziona compute.googleapis.com/activity_log.
  4. Analizza il log per individuare eventuali voci relative all'errore di creazione dell'istanza VM.

Verifica l'utilizzo delle quote di Compute Engine

  1. Per visualizzare l'utilizzo delle risorse Compute Engine rispetto a Quote di Dataflow per la zona che hai scelto come target, esegui questo comando:

    gcloud compute regions describe [REGION]

  2. Esamina i risultati delle seguenti risorse per verificare se superano quota:

    • CPU
    • DISKS_TOTAL_GB
    • IN_USE_ADDRESSES
    • INSTANCE_GROUPS
    • ISTANZE
    • REGIONAL_INSTANCE_GROUP_MANAGERS

  3. Se necessario, richiedi una modifica della quota.

Esamina i vincoli dei criteri dell'organizzazione

  1. Vai alla sezione Pagina Criteri dell'organizzazione
  2. Esamina i vincoli relativi a eventuali che potrebbero limitare la creazione di istanze VM per all'account in uso (per impostazione predefinita, Account di servizio Dataflow) o nella zona che hai scelto come target.
  3. Se hai un criterio che limita l'utilizzo degli indirizzi IP esterni, attiva dagli indirizzi IP esterni per questo job. Per ulteriori informazioni su come girare dagli indirizzi IP esterni, vedi Configura l'accesso a internet e le regole del firewall.

Timeout durante l'attesa di un aggiornamento da parte del worker

In caso di errore di un job Dataflow, si verifica il seguente errore:

Root cause: Timed out waiting for an update from the worker. For more information, see https://cloud.google.com/dataflow/docs/guides/common-errors#worker-lost-contact.

A volte questo errore si verifica quando il worker esaurisce la memoria o esegue lo scambio spazio. Per risolvere il problema, come primo passaggio, prova a eseguire il di nuovo il lavoro. Se il job continua a non riuscire e si verifica lo stesso errore, prova a utilizzare un worker con più memoria e spazio su disco. Ad esempio, aggiungi il seguente avvio della pipeline :

--worker_machine_type=m1-ultramem-40 --disk_size_gb=500

La modifica del tipo di worker potrebbe influire sui costi fatturati. Per ulteriori informazioni, consulta Risolvere gli errori di esaurimento della memoria di Dataflow.

Questo errore può verificarsi anche quando i dati contengono una chiave di scelta rapida. In questo scenario, L'utilizzo della CPU è elevato su alcuni worker per la maggior parte della durata del job. Tuttavia, il numero di worker non raggiunge il massimo consentito. Per ulteriori informazioni sulle chiavi di scelta rapida e le possibili soluzioni, consulta Scrittura di pipeline Dataflow in funzione della scalabilità.

Per ulteriori soluzioni a questo problema, vedi È stato rilevato un tasto di scelta rapida ....

Se il codice Python chiama il codice C/C++ utilizzando il meccanismo di estensione Python, verifica se il codice dell'estensione rilascia il codice GIL (Global Interpreter Lock) Python in modalità di calcolo ad alta intensità di calcolo parti di codice che non accedono allo stato Python. Se il GIL non viene rilasciato per un periodo di tempo prolungato, potresti ricevere messaggi di errore come: Unable to retrieve status info from SDK harness <...> within allowed time e SDK worker appears to be permanently unresponsive. Aborting the SDK.

Le librerie che facilitano le interazioni con le estensioni come Cython e PyBind hanno delle primitive per controllare lo stato GIL. Puoi anche rilasciare manualmente GIL e riacquisirlo prima di restituire il controllo all'interprete Python usando Macro Py_BEGIN_ALLOW_THREADS e Py_END_ALLOW_THREADS. Per saperne di più, vedi Stato del thread e Blocco interprete globale nella documentazione Python.

Potrebbe essere possibile recuperare le analisi dello stack di un thread che contiene il GIL su un worker Dataflow in esecuzione come segue:

# SSH to a currently running Dataflow worker VM, for example:
gcloud compute ssh --zone "us-central1-a" "beamapp-someworker-harness-abcd" --project "project-id"

# Find a container running the Python SDK harness.
CONTAINER_ID=`docker ps | grep python | head -1 | awk '{print $1}'`

# Start a shell in the running container.
docker exec --privileged -it $CONTAINER_ID /bin/bash

# Inspect python processes in the running container.
ps -A | grep python
PYTHON_PID=$(ps -A | grep python | head -1 | awk '{print $1}')

# Use pystack to retrieve stacktraces from the python process. Note which thread holds the GIL.
pip install pystack
pystack remote $PYTHON_PID

# To look up the native (C/C++) frames, use --native-all flag or use gdb:
pystack remote --native-all $PYTHON_PID
apt update && apt install -y gdb
gdb --quiet \
  --eval-command="set pagination off" \
  --eval-command="thread apply all bt" \
  --eval-command "set confirm off" \
  --eval-command="quit"  -p $PYTHON_PID

Nelle pipeline Python, nella configurazione predefinita, presuppone che ogni processo Python in esecuzione sui worker ne utilizzi in modo efficiente di un singolo core vCPU. Se il codice della pipeline ignora i limiti GIL, ad esempio utilizzando librerie implementate in C++, elaborando potrebbero utilizzare risorse di più di un core vCPU, i worker potrebbero non ricevere abbastanza risorse della CPU. Per aggirare questo problema, riduci il numero di thread sui worker.

Errori temporanei durante la pubblicazione nell'argomento

Quando il job di flussi di dati utilizza la modalità flusso di dati "Almeno una volta" e pubblica in un sink Pub/Sub, nei log del job viene visualizzato il seguente errore:

There were transient errors publishing to topic

Se il job viene eseguito correttamente, questo errore è benigno e puoi ignorarlo. Dataflow riprova automaticamente a inviare Pub/Sub con un ritardo di backoff.

Problemi di dipendenza Java

Classi e librerie incompatibili possono causare problemi di dipendenza Java. Quando la tua pipeline presenta problemi di dipendenza Java, si verifica uno dei seguenti errori che potrebbero verificarsi:

  • NoClassDefFoundError: questo errore si verifica quando un intero corso non è disponibile durante il runtime.
  • NoSuchMethodError: questo errore si verifica quando la classe nel classpath utilizza una versione che non contiene il metodo corretto o quando il metodo firma modificata.
  • NoSuchFieldError: questo errore si verifica quando la classe nel classpath utilizza una versione che non ha un campo obbligatorio durante il runtime.
  • FATAL ERROR in native method: questo errore si verifica quando non è possibile caricare correttamente una dipendenza integrata. Se utilizzi uber JAR (ombreggiato), non includere librerie che utilizzano firme (come Conscrypt) nello stesso JAR.

Se la pipeline contiene impostazioni e codice specifici dell'utente, il codice non può contenere versioni miste delle librerie. Se usi una libreria di gestione delle dipendenze, ti consigliamo di usare BOM delle librerie Google Cloud.

Se utilizzi l'SDK Apache Beam, per importare il BOM delle librerie corretto, usa beam-sdks-java-io-google-cloud-platform-bom:

Maven 

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.apache.beam</groupId>
      <artifactId>beam-sdks-java-google-cloud-platform-bom</artifactId>
      <version>BEAM_VERSION</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

Gradle 

dependencies {
    implementation(platform("org.apache.beam:beam-sdks-java-google-cloud-platform-bom:BEAM_VERSION"))
}

Per ulteriori informazioni, vedi Gestire le dipendenze della pipeline in Dataflow.

InaccessibilitàObjectException in JDK 17 e versioni successive

Quando esegui pipeline con la piattaforma Java, JDK (Standard Edition Development Kit) versioni 17 e successive, nei file di log del worker potrebbe essere visualizzato il seguente errore:

Unable to make protected METHOD accessible:
    module java.MODULE does not "opens java.MODULE" to ...

Questo problema si verifica perché a partire da Java versione 9, Java Virtual Machine con modulo aperto (JVM) sono necessarie per accedere agli interni JDK. In Java 16 e versioni successive, sono sempre necessarie opzioni JVM a modulo aperto per accedere agli interni JDK.

Per risolvere il problema, quando passi i moduli al tuo la pipeline Dataflow da aprire, utilizza il formato MODULE/PACKAGE=TARGET_MODULE(,TARGET_MODULE)* con l'opzione pipeline jdkAddOpenModules. Questo formato permette di accedere alla libreria necessaria.

Ad esempio, se l'errore è module java.base does not "opens java.lang" to unnamed module @..., includi la seguente opzione per la pipeline quando esegui la pipeline:

--jdkAddOpenModules=java.base/java.lang=ALL-UNNAMED

Per ulteriori informazioni, consulta DataflowPipelineOptions documentazione del corso.

Errori del connettore BigQuery

Le seguenti sezioni contengono errori comuni del connettore BigQuery che che potresti riscontrare e i passaggi per risolverli o per risolverlo.

quotaExceeded

Quando utilizzi il connettore BigQuery per scrivere in BigQuery utilizzando di inserimento di flussi di dati, la velocità effettiva di scrittura è inferiore a quanto previsto e potrebbe verificarsi un errore:

quotaExceeded

Una velocità effettiva lenta potrebbe essere dovuta al fatto che la pipeline supera il limite Quota di inserimento di flussi di dati BigQuery. Se sì, i dati relativi alla quota i messaggi di errore di BigQuery vengono visualizzati nella log dei worker (cerca quotaExceeded errori).

Se visualizzi quotaExceeded di errori, per risolvere il problema:

  • Quando utilizzi l'SDK Apache Beam per Java, imposta il sink BigQuery opzione ignoreInsertIds().
  • Quando utilizzi l'SDK Apache Beam per Python, usa l'ignore_insert_ids .

Queste impostazioni ti rendono idoneo a un 1 GB al secondo per ogni progetto BigQuery velocità effettiva di inserimento di flussi di dati. Per ulteriori informazioni sulle avvertenze relative la deduplicazione automatica dei messaggi, Documentazione di BigQuery. Per aumentare la quota di inserimento di flussi di dati BigQuery al di sopra di 1 GBps, inviare una richiesta tramite la console Google Cloud.

Se non vedi errori relativi alla quota nei log dei worker, il problema potrebbe essere che i parametri predefiniti relativi al raggruppamento o al raggruppamento in batch non forniscono parallelismo per la scalabilità della pipeline. Puoi modificare diverse impostazioni Configurazioni correlate al connettore Dataflow di BigQuery a raggiungere le prestazioni previste durante la scrittura in BigQuery utilizzando di inserimento di flussi di dati. Ad esempio, per l'SDK Apache Beam per Java, regola numStreamingKeys affinché corrisponda al numero massimo di worker e considera di insertBundleParallelism in aumento per configurare il connettore BigQuery scrivere in BigQuery usando più thread paralleli.

Per le configurazioni disponibili nell'SDK Apache Beam per Java, vedi BigQueryPipelineOptions, e per le configurazioni disponibili nell'SDK Apache Beam per Python, consulta Trasformazione WriterToBigQuery:

rateLimitExceeded

Quando utilizzi il connettore BigQuery, si verifica il seguente errore:

rateLimitExceeded

Questo errore si verifica se BigQuery Richieste API vengono inviati per un breve periodo di tempo. BigQuery prevede limiti di quota a breve termine. La tua pipeline Dataflow può superare temporaneamente tale quota. In questo scenario, Richieste API dalla tua pipeline Dataflow a BigQuery, potrebbe causare rateLimitExceeded errori nei log del worker.

Dataflow riprova a utilizzare questi errori, quindi puoi tranquillamente ignorarli errori. Se ritieni che la tua pipeline sia interessata da rateLimitExceeded errori, contatta l'assistenza clienti Google Cloud.

Errori vari

Le seguenti sezioni contengono vari errori che potresti riscontrare e i passaggi per risolverli o per risolvere gli errori.

Impossibile allocare sha384

Il job viene eseguito correttamente, ma nei log del job viene visualizzato il seguente errore:

ima: Can not allocate sha384 (reason: -2)

Se il job viene eseguito correttamente, questo errore è benigno e puoi ignorarlo. A volte le immagini di base della VM worker producono questo messaggio. Dataflow risponde e affronta automaticamente di base.

Esiste una richiesta di funzionalità per modificare il livello di questo messaggio dalle ore WARN alle ore INFO. Per ulteriori informazioni, vedi Abbassamento del livello di log degli errori di avvio del sistema Dataflow su WARN o INFO.

Errore durante l'inizializzazione del prober plug-in dinamico

Il job viene eseguito correttamente, ma nei log del job viene visualizzato il seguente errore:

Error initializing dynamic plugin prober" err="error (re-)creating driver directory: mkdir /usr/libexec/kubernetes: read-only file system

Se il job viene eseguito correttamente, questo errore è benigno e puoi ignorarlo. Questo errore si verifica quando il job Dataflow tenta di creare un'istanza senza le autorizzazioni di scrittura necessarie e l'attività non va a buon fine. Se il tuo job ha esito positivo, la directory non era necessaria oppure Dataflow ha affrontato di base.

Esiste una richiesta di funzionalità per modificare il livello di questo messaggio dalle ore WARN alle ore INFO. Per ulteriori informazioni, vedi Abbassamento del livello di log degli errori di avvio del sistema Dataflow su WARN o INFO.

Oggetto non trovato: pipeline.pb

Quando elenchi offerte di lavoro utilizzando JOB_VIEW_ALL, si verifica il seguente errore:

No such object: BUCKET_NAME/PATH/pipeline.pb

Questo errore può verificarsi se elimini il file pipeline.pb dai file temporanei per il lavoro.

Ignorare la sincronizzazione dei pod

Il job viene eseguito correttamente, ma nei log del job viene visualizzato uno dei seguenti errori:

Skipping pod synchronization" err="container runtime status check may not have completed yet"

Oppure:

Skipping pod synchronization" err="[container runtime status check may not have completed yet, PLEG is not healthy: pleg has yet to be successful]"

Se il job viene eseguito correttamente, questi errori non sono gravi e puoi ignorarli. Viene visualizzato il messaggio container runtime status check may not have completed yet quando il kubelet di Kubernetes salta la sincronizzazione dei pod perché in attesa dell'inizializzazione del runtime del container. Questo scenario si verifica per diversi motivi, ad esempio quando il runtime del container ha è avviato o si sta riavviando.

Quando il messaggio include PLEG is not healthy: pleg has yet to be successful, il kubelet è in attesa che il generatore di eventi del ciclo di vita dei pod (PLEG) diventi integro prima di sincronizzare i pod. Il PLEG è responsabile della generazione degli eventi utilizzate dal kubelet per monitorare lo stato dei pod.

Esiste una richiesta di funzionalità per modificare il livello di questo messaggio dalle ore WARN alle ore INFO. Per ulteriori informazioni, vedi Abbassamento del livello di log degli errori di avvio del sistema Dataflow su WARN o INFO.

Consigli

Per indicazioni sui suggerimenti generati da Dataflow Insights, consulta la sezione Approfondimenti.