Risolvere gli errori di Dataflow

Se riscontri problemi con la pipeline o il job di Dataflow, in questa pagina sono elencati i messaggi di errore che potresti visualizzare e vengono forniti suggerimenti su come correggere ogni errore.

Gli 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 registrazione.

La pipeline potrebbe generare eccezioni durante l'elaborazione dei dati. Alcuni di questi errori sono temporanei, ad esempio quando si verificano difficoltà temporanee di accesso a un servizio esterno. Alcuni di questi errori sono permanenti, ad esempio quelli causati da dati di input corrotti o non decodificabili o da puntatori null durante il calcolo.

Dataflow elabora gli elementi in pacchetti arbitrari e riprova il pacchetto completo quando viene generato un errore per un elemento del pacchetto. Quando viene eseguito in modalità batch, i bundle che includono un elemento con errori vengono riprovati quattro volte. La pipeline non va a buon fine quando un singolo bundle non va a buon fine quattro volte. Quando viene eseguito in modalità di streaming, un bundle che include un elemento con errori viene riavviato indefinitamente, il che potrebbe causare l'interruzione permanente della pipeline.

Le eccezioni nel codice utente, ad esempio le istanze DoFn, vengono segnalate nell'interfaccia di monitoraggio di Dataflow. Se esegui la pipeline con BlockingDataflowPipelineRunner, vengono visualizzati anche messaggi di errore nella console o nella finestra del terminale.

Valuta la possibilità di proteggerti dagli errori nel codice aggiungendo gestori delle eccezioni. Ad esempio, se vuoi eliminare gli elementi che non superano una convalida degli input personalizzati eseguita in un ParDo, utilizza un blocco try/catch all'interno del ParDo per gestire l'eccezione, registrare e eliminare l'elemento. Per i workload di produzione, implementa un pattern di messaggio non elaborato. Per monitorare il conteggio degli errori, utilizza le trasformazioni di aggregazione.

File di log mancanti

Se non vedi nessun log per i tuoi job, rimuovi eventuali filtri di esclusione contenenti resource.type="dataflow_step" da tutti i sink del router dei log di Cloud Logging.

Vai a Router dei log

Per ulteriori dettagli sulla rimozione delle esclusioni dei log, consulta la guida Rimuovere le esclusioni.

Duplicati nell'output

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

Questo problema può verificarsi quando il job Dataflow utilizza la modalità di streaming della pipeline almeno una volta. Questa modalità garantisce che i record vengano elaborati almeno una volta. Tuttavia, in questa modalità sono possibili record duplicati.

Se il tuo flusso di lavoro non tollera record duplicati, utilizza la modalità di streaming esattamente una volta. In questa modalità, Dataflow garantisce che i record non vengano eliminati o duplicati durante il passaggio dei dati attraverso la pipeline.

Per verificare quale modalità di streaming è in uso per il job, consulta Visualizzare la modalità di streaming di un job.

Per ulteriori informazioni sulle modalità di streaming, consulta Impostare la modalità di streaming della pipeline.

Errori della pipeline

Le sezioni seguenti contengono gli errori comuni della pipeline che potresti riscontrare e i passaggi per risolverli o per la risoluzione dei problemi.

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 richieste non sono abilitate nel progetto.

Per risolvere il problema ed eseguire un job Dataflow, abilita le seguenti 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, consulta la sezione Inizia a utilizzare su come attivare le 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 per il percorso di Cloud Storage per i file temporanei (tempLocation o temp_location) contiene il simbolo @ seguito da un numero o da un asterisco (*).

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

Richiesta errata

Quando esegui un job Dataflow, i log di Monitoraggio di Cloud mostrano 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

Gli avvisi di richiesta non valida si verificano se le informazioni sullo stato del lavoratore non sono aggiornate o non sono sincronizzate a causa di ritardi nell'elaborazione. Spesso il job Dataflow riesce nonostante gli avvisi di richieste non valide. In questo caso, ignora gli avvisi.

Impossibile leggere e scrivere in posizioni diverse

Quando esegui un job Dataflow, potresti visualizzare il seguente errore nei 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. Inoltre, può verificarsi quando la posizione di staging e la destinazione si trovano in regioni diverse. Ad esempio, se il job legge da Pub/Sub e poi scrive in un bucket Cloud Storage temp prima di scrivere in una tabella BigQuery, il bucket Cloud Storage temp e la tabella BigQuery devono trovarsi nella stessa regione.

Le località a più regioni sono considerate diverse da quelle a singola regione, anche se la 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, assicurati che le posizioni di destinazione, di origine e di staging si trovino nella stessa regione. Le posizioni dei bucket Cloud Storage non possono essere modificate, pertanto 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 di Dataflow non riescono a stabilire o mantenere una connessione con l'origine dati o la destinazione.

Per risolvere il problema, segui questi passaggi:

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

Nessun oggetto di questo tipo

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

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

Questi errori si verificano in genere quando alcuni job Dataflow in esecuzione utilizzano lo stesso temp_location per eseguire il commit dei file di job temporanei creati durante l'esecuzione della pipeline. Quando più job simultanei condividono lo stesso temp_location, questi job potrebbero sovrascrivere i dati temporanei l'uno dell'altro e potrebbe verificarsi una race condition. Per evitare questo problema, ti consigliamo di utilizzare un temp_location unico per ogni job.

Dataflow non è in grado di determinare il backlog

Quando esegui una pipeline in streaming da Pub/Sub, viene visualizzato il seguente avviso:

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

Quando una pipeline Dataflow estrae dati da Pub/Sub, Dataflow deve richiedere ripetutamente informazioni a Pub/Sub. Queste informazioni includono la quantità di arretrati dell'abbonamento e la data del messaggio non confermato più vecchio. A volte, Dataflow non è in grado di recuperare queste informazioni da Pub/Sub a causa di problemi interni del sistema, che possono causare un accumulo transitorio del backlog.

Per ulteriori informazioni, consulta Streaming con Cloud Pub/Sub.

DEADLINE_EXCEEDED o Server non risponde

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

DEADLINE_EXCEEDED

In alternativa:

Server Unresponsive

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

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

  In alcuni casi, i lavoratori 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 utilizzando le porte TCP 12345 e 12346 all'interno della rete VPC. In questo scenario, l'errore include il nome del cablaggio del worker e la porta TCP bloccata. 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 il flag gcloud compute firewall-rules create rules per consentire il traffico di rete alle porte 12345 e 12346. L'esempio seguente dimostra 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 tuo job è soggetto a ordinamento casuale.

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

  Java

  • Se il job non utilizza lo shuffle basato su servizi, passa a utilizzare Dataflow Shuffle basato su servizi impostando--experiments=shuffle_mode=service. Per dettagli e disponibilità, consulta Dataflow Shuffle.
  • Aggiungi altri worker. Prova a impostare --numWorkers con un valore più alto 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 basato su 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 a utilizzare Dataflow Shuffle basato su servizi impostando--experiments=shuffle_mode=service. Per dettagli e disponibilità, consulta Dataflow Shuffle.
  • Aggiungi altri worker. Prova a impostare --num_workers con un valore più alto 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 basato su 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 a utilizzare Dataflow Shuffle basato su servizi impostando--experiments=shuffle_mode=service. Per dettagli e disponibilità, consulta Dataflow Shuffle.
  • Aggiungi altri worker. Prova a impostare --num_workers con un valore più alto 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 basato su SSD. Prova a impostare --disk_type="compute.googleapis.com/projects/PROJECT_ID/zones/ZONE/diskTypes/pd-ssd" quando esegui la pipeline.

Errori di codifica, IOException o comportamento inaspettato nel codice utente

Gli SDK Apache Beam e i worker di Dataflow dipendono da componenti di terze parti comuni. Questi componenti importano dipendenze aggiuntive. I conflitti di versione possono causare comportamenti imprevisti nel servizio. Inoltre, alcune librerie non sono compatibili con le versioni successive. Potresti dover bloccare le versioni elencate che rientrano nell'ambito durante l'esecuzione. Dipendenze di SDK e nodi worker contiene un elenco di dipendenze e delle relative versioni richieste.

Errore durante l'esecuzione di LookupEffectiveGuestPolicies

Quando esegui un job Dataflow, potresti visualizzare il seguente errore nei 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 la gestione della configurazione del sistema operativo è abilitata per l'intero progetto.

Per risolvere il problema, disabilita i criteri di VM Manager che si applicano all'intero progetto. Se non è possibile disattivare le norme di VM Manager per l'intero progetto, puoi ignorare tranquillamente questo errore e filtrarlo dagli strumenti di monitoraggio dei log.

Java Runtime Environment ha rilevato un errore fatale

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 eseguire codice non Java e questo codice o le associazioni JNI contengono un errore.

Errore della chiave dell'attributo googclient_deliveryattempt

Il job Dataflow non va a buon fine con 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).

In alternativa:

Invalid extensions name: googclient_deliveryattempt

Questo errore si verifica quando il job Dataflow presenta le seguenti caratteristiche:

• Il job Dataflow utilizza Streaming Engine.
• La pipeline ha un sink Pub/Sub.
• La pipeline utilizza una sottoscrizione pull.
• La pipeline utilizza una delle API di servizio Pub/Sub per pubblicare i messaggi anziché utilizzare l'emissario I/O Pub/Sub integrato.
• Pub/Sub utilizza la libreria client Java o C#.
• La sottoscrizione Pub/Sub ha un argomento messaggi non recapitabili.

Questo errore si verifica perché quando utilizzi la libreria client Java o C# di Pub/Sub e un argomento messaggi non recapitabili in arrivo per un abbonamento è abilitato, i tentativi di recapito si trovano nell'attributo messaggio googclient_deliveryattempt anziché nel campo delivery_attempt. Per maggiori informazioni, consulta la sezione Monitorare i tentativi di recapito nella pagina "Gestire gli errori di recapito dei messaggi".

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

• Disattiva Streaming Engine.
• Utilizza il connettore Apache Beam PubSubIO integrato anziché l'API di servizio Pub/Sub.
• Utilizza un tipo di sottoscrizione Pub/Sub diverso.
• Rimuovi l'argomento della posta inutilizzata.
• Non utilizzare la libreria client Java o C# con l'abbonamento pull Pub/Sub. Per altre opzioni, consulta Esempi di codice della libreria client.
• Nel codice della pipeline, quando le chiavi degli attributi iniziano con goog, cancella gli attributi del messaggio prima di pubblicarli.

È stata rilevata una hot key

Si verifica il seguente errore:

A hot key HOT_KEY_NAME was detected in...

Questi errori si verificano se i dati contengono una hot key. Una hot key è una chiave con elementi sufficienti per influire negativamente sul rendimento della pipeline. Queste chiavi limitano la capacità di Dataflow di elaborare gli elementi in parallelo, il che aumenta il tempo di esecuzione.

Per stampare la chiave leggibile quando viene rilevato un tasto di scelta rapida nella pipeline, utilizza l'opzione della pipeline per i tasti di scelta rapida.

Per risolvere il problema, verifica che i dati siano distribuiti in modo uniforme. Se una chiave ha un numero sproporzionato di valori, valuta le seguenti opzioni:

• Modifica la chiave dei dati. Applica una trasformazione ParDo per generare nuove coppie chiave-valore.
• Per i job Java, utilizza la trasformazione Combine.PerKey.withHotKeyFanout.
• Per i job Python, utilizza la trasformazione CombinePerKey.with_hot_key_fanout.
• Attiva Dataflow Shuffle.

Per visualizzare i tasti di scelta rapida nell'interfaccia di monitoraggio di Dataflow, consulta Risolvere i problemi relativi ai job 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 ha accesso all'API Data Catalog.

Per risolvere il problema, abilita l'API Data Catalog nel progetto Google Cloud che utilizzi per scrivere ed eseguire query.

In alternativa, assegna il ruolo roles/datacatalog.viewer al service account 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 i 10 MB. Determinate condizioni nella pipeline possono causare il superamento del limite del grafo dei job. Le condizioni più comuni includono:

• Una trasformazione Create che include una grande quantità di dati in memoria.
• Un'istanza DoFn di grandi dimensioni serializzata per la trasmissione ai lavoratori da remoto.
• Un DoFn come istanza di classe interna anonima che (eventualmente inavvertitamente) carica una grande quantità di dati da serializzare.
• Un grafo diretto aciclico (DAG) viene utilizzato all'interno di un loop programmatico che enumera un elenco di grandi dimensioni.

Per evitare queste condizioni, ti consigliamo di ristrutturare la pipeline.

Commit della chiave troppo grande

Quando esegui un job di streaming, nei file log del worker viene visualizzato il seguente errore:

KeyCommitTooLargeException

Questo errore si verifica negli scenari di streaming se viene raggruppata una quantità molto grande di dati senza utilizzare una trasformazione Combine o se viene prodotta una grande quantità di dati da un singolo elemento di input.

Per ridurre la possibilità di riscontrare questo errore, utilizza le seguenti strategie:

• Assicurati che l'elaborazione di un singolo elemento non possa comportare output o modifiche dello stato che superano il limite.
• Se più elementi sono stati raggruppati in base a una chiave, valuta la possibilità di aumentare lo spazio della chiave per ridurre gli elementi raggruppati per chiave.
• Se gli elementi per una chiave vengono emessi ad alta frequenza in un breve periodo di tempo, potrebbero generarsi molti GB di eventi per quella chiave nelle finestre. Riscrivere la pipeline per rilevare chiavi come questa ed emettere solo un output che indichi che la chiave era presente di frequente in quella finestra.
• Utilizza le trasformazioni Combine dello spazio sublineare per le operazioni associative e commutative. Non utilizzare un combinatore se non riduce lo spazio. Ad esempio, l'operatore combinatore per le stringhe che le accoda semplicemente è peggiore rispetto a non utilizzarlo.

Rifiuto del messaggio di dimensioni superiori a 7168 KB

Quando esegui un job Dataflow creato da un modello, il job potrebbe non riuscire con 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 inutilizzati superano il limite di dimensione di 7168 K. Come soluzione alternativa, attiva Streaming Engine, che ha un limite di dimensioni più elevato. Per attivare Streaming Engine, utilizza la seguente opzione della pipeline.

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

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

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 la dimensione massima della richiesta di 20 MB.

Le dimensioni del job sono legate alla rappresentazione JSON della pipeline. Una pipeline più grande significa una richiesta più grande. Dataflow ha una limitazione che impone un limite di 20 MB per le richieste.

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

Questo comando scrive una rappresentazione JSON del job in un file. Le dimensioni del file serializzato sono una buona stima delle dimensioni della richiesta. Le dimensioni effettive sono leggermente superiori a causa di alcune informazioni aggiuntive incluse nella richiesta.

Determinate condizioni nella pipeline possono causare il superamento del limite per la rappresentazione JSON. Le condizioni più comuni includono:

• Una trasformazione Create che include una grande quantità di dati in memoria.
• Un'istanza DoFn di grandi dimensioni serializzata per la trasmissione ai lavoratori da remoto.
• Un DoFn come istanza di classe interna anonima che (eventualmente inavvertitamente) carica una grande quantità di dati da serializzare.

Per evitare queste condizioni, ti consigliamo di ristrutturare la pipeline.

Le opzioni della pipeline dell'SDK o l'elenco dei file di staging 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.

In alternativa:

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

Questi errori si verificano se non è stato possibile avviare la pipeline a causa del 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. Il limite è documentato nelle limitazioni dei metadati personalizzati di Compute Engine.

I seguenti scenari possono causare il superamento del limite della rappresentazione JSON:

• Esistono troppi file JAR da eseguire in anteprima.
• Il campo della richiesta sdkPipelineOptions è troppo grande.

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

Le dimensioni del file di output di questo comando devono essere inferiori a 256 KB. I 512 KB nel messaggio di errore si riferiscono alle dimensioni totali del file di output e alle opzioni di metadati personalizzati per l'istanza VM Compute Engine.

Puoi ottenere una stima approssimativa dell'opzione dei metadati personalizzati per l'istanza VM dai job Dataflow in esecuzione nel progetto. Scegli un job Dataflow in esecuzione. Prendi un'istanza VM e vai alla pagina dei dettagli dell'istanza VM Compute Engine per verificare la presenza della sezione dei metadati personalizzati. La lunghezza totale dei metadati personalizzati e del file deve essere inferiore a 512 KB. Non è possibile una stima accurata del job non riuscito, poiché le VM non vengono avviate per i job non riusciti.

Se l'elenco JAR sta raggiungendo il limite di 256 KB, rivedilo e riduci eventuali file JAR non necessari. Se è ancora troppo grande, prova a eseguire il job Dataflow utilizzando un JAR uber. Per un esempio che illustra come creare e utilizzare il JAR uber, consulta Creare e implementare un JAR uber.

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

--experiments=no_display_data_on_gce_metadata

Chiave di riproduzione 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 a un determinato (Co-)GroupByKey è troppo grande dopo l'applicazione del coder corrispondente. Dataflow ha un limite per le chiavi di ordinamento serializzate.

Per risolvere il problema, riduci le dimensioni delle chiavi o utilizza codificatori più efficienti in termini di spazio.

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

Il numero totale di oggetti BoundedSource ... è superiore al limite consentito

Quando esegui job con Java, potrebbe verificarsi uno dei seguenti errori:

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

In alternativa:

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

NameError

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

NameError

Questo errore non si verifica quando esegui il codice localmente, ad esempio quando lo esegui utilizzando DirectRunner.

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

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

Per risolvere il problema, utilizza uno dei seguenti metodi. Se i DoFn sono definiti nel file principale e fanno riferimento a importazioni e funzioni nello spazio dei nomi globale, imposta l'opzione della pipeline --save_main_session su True. Questa modifica pickles lo stato dello spazio dei nomi globale e lo carica sul lavorare di Dataflow.

Se nello spazio dei nomi globale sono presenti oggetti che non possono essere sottoposti a pickling, si verifica un errore di pickling. Se l'errore riguarda un modulo che dovrebbe essere disponibile nella distribuzione di Python, importalo localmente, dove viene utilizzato.

Ad esempio, invece di:

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

utilizzo:

def myfunc():
  import re
  # use re module

In alternativa, se i tuoi DoFn si estendono su più file, utilizza un approccio diverso per impacchettare il flusso di lavoro e gestire le dipendenze.

L'oggetto è soggetto al criterio di conservazione del bucket

Quando un job Dataflow scrive in un bucket Cloud Storage, non riesce e restituisce il seguente errore:

Object 'OBJECT_NAME' is subject to bucket's retention policy or object retention and cannot be deleted or overwritten

Potresti anche visualizzare il seguente errore:

Unable to rename "gs://BUCKET"

Il primo errore si verifica quando la conservazione degli oggetti è attivata nel bucket Cloud Storage in cui scrive il job Dataflow. Per ulteriori informazioni, consulta Attivare e utilizzare le configurazioni di conservazione degli oggetti.

Per risolvere il problema, utilizza una delle seguenti soluzioni alternative:

• Scrivi in un bucket Cloud Storage che non ha un criterio di conservazione per la cartella temp.

• Rimuovi il criterio di conservazione dal bucket in cui scrive il job. Per ulteriori informazioni, vedi Impostare la configurazione di conservazione di un oggetto.

Il secondo errore può indicare che la conservazione degli oggetti è abilitata nel bucket Cloud Storage oppure che l'account di servizio del worker Dataflow non dispone dell'autorizzazione per scrivere nel bucket Cloud Storage.

Se visualizzi il secondo errore e la conservazione degli oggetti è attivata nel bucket Cloud Storage, prova le soluzioni alternative descritte in precedenza. Se la conservazione degli oggetti non è abilitata nel bucket Cloud Storage, verifica se l'account di servizio del worker Dataflow dispone dell'autorizzazione in scrittura sul bucket Cloud Storage. Per ulteriori informazioni, consulta Accedere ai bucket Cloud Storage.

Elaborazione bloccata o operazione in corso

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

Questo comportamento ha due possibili cause:

• Il codice DoFn è lento o è in attesa del completamento di un'operazione esterna lenta.
• Il codice DoFn potrebbe essere bloccato, in stato di deadlock o impiegare un tempo anomalo per completare l'elaborazione.

Per determinare quale sia il caso, espandi la voce di log di Cloud Monitoring per visualizzare una analisi dello stack. Cerca messaggi che indicano che il codice DoFn è bloccato o sta riscontrando problemi. Se non sono presenti messaggi, il problema potrebbe riguardare la velocità di esecuzione del codice DoFn. Valuta la possibilità di utilizzare Cloud Profiler o un altro strumento per esaminare le prestazioni del codice.

Se la pipeline è basata sulla VM Java (utilizzando Java o Scala), puoi esaminare la causa del blocco del codice. Esegui un dump completo del thread di tutta la JVM (non solo del thread bloccato) seguendo questi passaggi:

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

4. Esegui questo comando:

   curl http://localhost:8081/threadz
   

Operazione in corso nel pacchetto

Quando esegui una lettura della pipeline da JdbcIO, le letture partizionate da JdbcIO sono lente e nei file di log del worker viene visualizzato il seguente messaggio:

Operation ongoing in bundle process_bundle-[0-9-]* for PTransform{id=Read from JDBC with Partitions\/JdbcIO.Read\/JdbcIO.ReadAll\/ParDo\(Read\)\/ParMultiDo\(Read\).*, state=process} for at least (0[1-9]h[0-5][0-9]m[0-5][0-9]s) without outputting or completing:

Per risolvere il problema, apporta una o più delle seguenti modifiche alla pipeline:

• Utilizza le partizioni per aumentare il parallelismo dei job. Leggi con più partizioni più piccole per una migliore scalabilità.

• Controlla se la colonna di partizionamento è una colonna di indice o una colonna di partizionamento effettiva nell'origine. Attiva l'indicizzazione e la partizione di questa colonna nel database di origine per ottenere le migliori prestazioni.

• Utilizza i parametri lowerBound e upperBound per saltare la ricerca dei limiti.

Errori relativi alle quote di Pub/Sub

Quando esegui una pipeline in streaming da Pub/Sub, si verificano i seguenti errori:

429 (rateLimitExceeded)

In alternativa:

Request was throttled due to user QPS limit being reached

Questi errori si verificano se il progetto ha una quota Pub/Sub insufficiente.

Per scoprire se il tuo progetto ha una quota insufficiente, segui questi passaggi per verificare la presenza di errori client:

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

La richiesta è vietata dalle norme 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 non è all'interno del perimetro del servizio.

Per risolvere il problema, crea una regola di uscita che consenta l'accesso al bucket all'esterno del perimetro di servizio.

Il pacchetto in fase di staging...non è accessibile

I job che in precedenza andavano a buon fine potrebbero non riuscire a causa del seguente errore:

Staged package...is inaccessible

Per risolvere il problema:

• Verifica che il bucket Cloud Storage utilizzato per l'implementazione non abbia impostazioni TTL che causano l'eliminazione dei pacchetti sottoposti a staging.

• Verifica che l'account di servizio del worker del progetto Dataflow abbia l'autorizzazione per accedere al bucket Cloud Storage utilizzato per lo staging. 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 dall'accesso granulare all'accesso uniforme a livello di bucket. A causa dell'incongruenza tra i criteri IAM e ACL, la migrazione del bucket di staging all'accesso uniforme a livello di bucket non consente gli ACL per le risorse Cloud Storage. Le ACL includono le autorizzazioni detenute dall'account di servizio worker del progetto Dataflow sul bucket di staging.

Per ulteriori informazioni, consulta Accedere ai bucket Cloud Storage nei progetti Google Cloud.

Un elemento di lavoro non è riuscito 4 volte

Quando un job batch non va a buon fine, si verifica il seguente errore:

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

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

Quando viene eseguito in modalità di streaming, un bundle che include un elemento con errori viene tentato nuovamente indefinitamente, il che potrebbe causare l'interruzione definitiva della pipeline.

Non puoi configurare questa soglia di errore. Per maggiori dettagli, consulta la sezione sulla gestione di errori ed eccezioni della pipeline.

Per risolvere il problema, cerca i quattro singoli errori nei log di Monitoraggio cloud del job. Nei log del worker, cerca voci di log con livello di errore o livello di errore fatale che mostrano eccezioni o errori. L'eccezione o l'errore deve essere visualizzato almeno quattro volte. Se i log contengono solo errori di timeout generici relativi all'accesso a risorse esterne, come MongoDB, verifica che l'account di servizio del worker abbia l'autorizzazione per accedere alla sottorete della risorsa.

Timeout nel file del risultato del polling

Quando un job non va a buon fine, 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 al modo in cui vengono installate le dipendenze Python utilizzando il file requirements.txt. Lo stager di Apache Beam scarica il codice sorgente di tutte le dipendenze da PyPI, incluse le sorgenti delle dipendenze transitive. Poi, la compilazione di wheel avviene implicitamente durante il comando di 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, consulta il bug del team Apache Arrow che monitora questo problema. La soluzione alternativa suggerita è installare apache-beam direttamente nel Dockerfile. In questo modo, il timeout per il file requirements.txt non viene applicato.

Scrittura del file corretto/Scrittura/WriteImpl/PreFinalize non riuscita

Quando esegui un job, il job non riesce in modo intermittente 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 in esecuzione contemporaneamente.

Per risolvere il problema, non utilizzare la stessa sottodirectory come posizione di archiviazione temporanea 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 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

In alternativa:

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

Potresti anche visualizzare 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 il problema, se utilizzi l'SDK Python, esegui l'upgrade ad Apache Beam 2.57.0 o versioni successive. Le versioni dell'SDK Python 2.57.0 e successive migliorano l'elaborazione di elementi di grandi dimensioni e aggiungono la registrazione pertinente.

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

Quando gli oggetti PCollection nella pipeline hanno elementi di grandi dimensioni, i requisiti di RAM per la pipeline aumentano. Gli elementi di grandi dimensioni possono anche causare errori di runtime, soprattutto quando oltrepassano i confini delle fasi fuse.

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

Se l'errore si verifica in un passaggio che utilizza un input laterale, tieni presente che l'utilizzo di input laterali può introdurre una barriera di fusione. Controlla se la trasformazione che produce un elemento di grandi dimensioni e la trasformazione che lo utilizza appartengono alla stessa fase.

Quando crei la pipeline, segui queste best practice:

• In PCollections, utilizza più elementi di piccole dimensioni anziché un unico elemento di grandi dimensioni.
• Archivia blob di grandi dimensioni in sistemi di archiviazione esterni. Utilizza PCollections per trasmettere i metadati o un codificatore 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 è limitata a 2 GB. Per ulteriori informazioni, consulta Quote e limiti.

Errori relativi ai job di archiviazione

Le sezioni seguenti contengono gli errori comuni che potresti riscontrare quando provi a archiviare un job Dataflow utilizzando l'API.

Nessun valore fornito

Quando provi ad archiviare un job Dataflow utilizzando l'API, potrebbe verificarsi il seguente 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 segue il formato corretto. Questo problema può verificarsi a causa di errori ortografici.

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

Per risolvere questo errore, verifica che il comando passato all'API corrisponda al formato richiesto. Per maggiori dettagli, consulta Archiviare un job.

L'API non riconosce il valore

Quando provi ad archiviare un job Dataflow utilizzando l'API, potrebbe verificarsi il seguente 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 è 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 il comando passato all'API corrisponda al formato richiesto. Per maggiori dettagli, consulta Archiviare un job.

Impossibile aggiornare sia lo stato che la maschera

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

Cannot update both state and mask.

Questo errore si verifica quando si tenta di aggiornare sia lo stato del job che lo stato dell'archiviazione nella stessa chiamata all'API. Non puoi aggiornare sia lo stato del job sia il parametro di query 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, potrebbe verificarsi il seguente errore:

Workflow modification failed.

Questo errore si verifica in genere quando si tenta 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 stati:

• JOB_STATE_CANCELLED
• JOB_STATE_DRAINED
• JOB_STATE_DONE
• JOB_STATE_FAILED
• JOB_STATE_UPDATED

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

Errori delle immagini container

Le sezioni seguenti contengono gli errori comuni che potresti riscontrare quando utilizzi i contenitori personalizzati e i passaggi per risolverli o per la risoluzione dei problemi. Gli errori sono in genere preceduti dal seguente messaggio:

Unable to pull container image due to error: DETAILED_ERROR_MESSAGE

L'autorizzazione "containeranalysis.occurrences.list" è stata negata

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"]

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

Per ulteriori informazioni, consulta la Panoramica della ricerca di malware nel sistema operativo e la sezione Configurazione del controllo dell'accesso nella documentazione di Artifact Analysis.

Errore durante la sincronizzazione del pod ... impossibile "avviare il contenitore"

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 di container Docker colocalizzati in esecuzione su un worker Dataflow. Questo errore si verifica quando non riesce ad avviarsi uno dei container Docker nel pod. Se l'errore non è recuperabile, il worker Dataflow non riesce ad avviarsi e i job batch di Dataflow alla fine non riescono a completarsi con 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 contenitori si arresta in modo anomalo continuamente 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 worker con errori di avvio del container. Per limitare le voci di log, completa i 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 al resource_name, quindi su Mostra voci corrispondenti.

In Esplora log, i log di Dataflow sono organizzati in diversi stream di log. Il messaggio Error syncing pod viene emesso nel log denominato kubelet. Tuttavia, i log del contenitore con errori potrebbero trovarsi in un altro stream di log. Ogni contenitore ha un nome. Utilizza la tabella seguente per determinare quale stream di log potrebbe contenere i log pertinenti al contenitore con errori.

Quando esegui una query in Esplora log, assicurati che includa i nomi dei log pertinenti nell'interfaccia di Query Builder o che non abbia limitazioni per il nome del log.

Dopo aver selezionato i log pertinenti, il risultato della query potrebbe essere simile all'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é i log che segnalano il sintomo dell'errore del contenitore a volte vengono segnalati come INFO, includi i log INFO nell'analisi.

Le cause tipiche degli errori dei contenitori includono:

1. La pipeline Python ha dipendenze aggiuntive installate al runtime e l'installazione non va a buon fine. Potresti visualizzare errori come pip install failed with error. Questo problema potrebbe verificarsi a causa di requisiti in conflitto o a causa di una configurazione di rete limitata che impedisce a un worker Dataflow di estrarre una dipendenza esterna da un repository pubblico tramite internet.

2. Un worker non funziona correttamente nel mezzo dell'esecuzione della pipeline a causa di un errore di esaurimento della memoria. Potresti visualizzare un errore come 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 insufficiente, consulta Risolvere gli errori di memoria insufficiente di Dataflow.

3. Dataflow non riesce a estrarre l'immagine del contenitore. Per ulteriori informazioni, consulta la sezione Richiesta di pull di immagini non riuscita con errore.

4. Il contenitore utilizzato non è compatibile con l'architettura della CPU della VM worker. Nei log di avvio del cablaggio, potresti visualizzare un errore simile al seguente: exec /opt/apache/beam/boot: exec format error. Per controllare l'architettura dell'immagine del contenitore, esegui docker image inspect $IMAGE:$TAG e cerca la parola chiave Architecture. Se viene visualizzato il messaggio Error: No such image: $IMAGE:$TAG, potrebbe essere necessario estrarre prima l'immagine eseguendo docker pull $IMAGE:$TAG. Per informazioni sulla creazione di immagini multi-architettura, consulta Creare un'immagine container multi-architettura.

Dopo aver identificato l'errore che causa l'errore del contenitore, prova a risolvere il problema e invia di nuovo la pipeline.

Richiesta di pull delle immagini non riuscita con errore

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

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 riesce ad avviarsi perché non riesce a eseguire il pull di un'immagine del contenitore Docker. Questo problema si verifica nei seguenti scenari:

• L'URL dell'immagine del contenitore dell'SDK personalizzato non è corretto
• L'operatore non dispone delle credenziali o dell'accesso alla rete per l'immagine remota

Per risolvere il problema:

• Se utilizzi un'immagine contenitore personalizzata con il tuo job, verifica che l'URL dell'immagine sia corretto e che abbia un tag o un digest valido. Anche i worker Dataflow devono avere accesso all'immagine.
• Verifica che le immagini pubbliche possano essere estratte localmente eseguendo docker pull $image da un computer non autenticato.

Per immagini private o lavoratori privati:

• Se utilizzi Container Registry per ospitare l'immagine del contenitore, ti consigliamo di utilizzare Artifact Registry. Dal 15 maggio 2023, Container Registry è deprecato. Se utilizzi Container Registry, puoi eseguire la transizione ad Artifact Registry. Se le immagini si trovano in un progetto diverso da quello utilizzato per eseguire il job Google Cloud, configura il controllo dell'accesso per l'account di servizio Google Cloud predefinito.
• Se utilizzi un Virtual Private Cloud (VPC) condiviso, assicurati che i worker possano accedere all'host del repository dei contenitori personalizzati.
• Utilizza ssh per connetterti a una VM worker di job in esecuzione ed esegui docker pull $image per verificare direttamente che il worker sia configurato correttamente.

Se i worker non riescono più volte di seguito a causa di questo errore e il lavoro su un job è iniziato, il job può non riuscire con un errore simile al seguente messaggio:

Job appears to be stuck.

Se rimuovi l'accesso all'immagine durante l'esecuzione del job, rimuovendo l'immagine stessa o revocando le credenziali dell'account di servizio del worker Dataflow o l'accesso a internet per accedere alle immagini, Dataflow registra solo errori. Dataflow non arresta il job. Dataflow evita inoltre che le pipeline di inserimento flussi di lunga durata non funzionino correttamente per evitare di perdere lo stato della pipeline.

Altri possibili errori possono derivare da problemi o interruzioni della quota del repository. Se hai problemi a superare la quota di Docker Hub per il recupero di immagini pubbliche o interruzioni generali dei repository di terze parti, ti consigliamo di utilizzare Artifact Registry come repository di immagini.

SystemError: opcode sconosciuto

La pipeline del contenitore personalizzato Python potrebbe non riuscire con il seguente errore immediatamente dopo l'invio del job:

SystemError: unknown opcode

Inoltre, la analisi dello stack potrebbe includere

apache_beam/internal/pickler.py

Per risolvere il problema, verifica che la versione di Python in uso localmente sia uguale a quella nell'immagine del contenitore fino alla versione maggiore e minore. La differenza nella versione della patch, ad esempio 3.6.7 rispetto a 3.6.8, non crea problemi di compatibilità. La differenza nella versione minore, ad esempio 3.6.8 rispetto a 3.8.2, può causare errori nella pipeline.

Errori del worker

Le sezioni seguenti contengono gli errori comuni dei lavoratori che potresti riscontrare e i passaggi per risolverli o per la risoluzione dei problemi.

La chiamata dall'harness del worker Java a DoFn di Python non va a buon fine a causa di un errore

Se una chiamata dall'ambiente di lavoro Java a un DoFn Python non va a buon fine, viene visualizzato un messaggio di errore pertinente.

Per esaminare l'errore, espandi la voce del log degli errori di Cloud Monitoring e controlla il messaggio di errore e il traceback. Mostra il codice che non è andato a buon fine in modo da poterlo correggere, se necessario. Se ritieni che l'errore sia un bug di Apache Beam o Dataflow, segnala il bug.

EOFError: dati di marshal troppo brevi

Nei log del worker viene visualizzato il seguente errore:

EOFError: marshal data too short

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

Per risolvere il problema, consulta Nessun spazio rimanente sul dispositivo.

Impossibile collegare il disco

Quando provi a lanciare un job Dataflow che utilizza VM C3 con Persistent Disk, il job non va a buon fine con 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 VM C3 con un tipo di Persistent Disk non supportato. Per ulteriori informazioni, consulta Tipi di dischi supportati per C3.

Per utilizzare le VM C3 con il tuo job Dataflow, scegli il pd-ssd tipo di disco del worker. Per saperne di più, consulta Opzioni a livello di lavoratore.

Spazio esaurito sul dispositivo

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

No space left on device

Questo errore può verificarsi per uno dei seguenti motivi:

• Lo spazio di archiviazione persistente del worker esaurisce lo spazio libero, il che può verificarsi per uno dei seguenti motivi:
  • Un job scarica dipendenze di grandi dimensioni in fase di esecuzione
  • Un job utilizza container personalizzati di grandi dimensioni
  • Un job scrive molti dati temporanei sul disco locale
• Quando utilizzi Dataflow Shuffle, Dataflow imposta dimensioni del disco predefinite inferiori. Di conseguenza, questo errore potrebbe verificarsi con i job che passano dall'ordinamento basato su worker.
• Il disco di avvio del worker si riempie perché registra più di 50 voci al secondo.

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

Per visualizzare le risorse del disco associate a un singolo worker, cerca i dettagli dell'istanza VM per le VM worker associate al tuo job. Parte dello spazio su disco viene impiegata dal sistema operativo, dai binari, dai log e dai contenitori.

Per aumentare lo spazio del disco permanente o del disco di avvio, modifica l'opzione della pipeline delle dimensioni del disco.

Monitora l'utilizzo dello spazio su disco nelle istanze VM worker utilizzando Cloud Monitoring. Consulta la sezione Ricevere le metriche VM worker dall'agente di monitoraggio per istruzioni su come eseguire la configurazione.

Cerca i problemi di spazio sul disco di avvio visualizzando l'output della porta seriale sulle istanze VM worker e cerca messaggi come:

Failed to open system journal: No space left on device

Se hai molte istanze VM worker, puoi creare uno script per eseguire gcloud compute instances get-serial-port-output su tutte contemporaneamente. Puoi invece esaminare l'output.

La pipeline Python non va a buon fine dopo un'ora di inattività del worker

Quando utilizzi l'SDK Apache Beam per Python con Dataflow Runner v2 su macchine di lavoro con molti core CPU, utilizza l'SDK Apache Beam 2.35.0 o versioni successive. Se il job utilizza un contenitore personalizzato, utilizza l'SDK Apache Beam 2.46.0 o versioni successive.

Valuta la possibilità di predefinire il container Python. Questo passaggio può migliorare i tempi di avvio delle VM e le prestazioni della scalabilità automatica orizzontale. Per utilizzare questa funzionalità, attiva l'API Cloud Build nel tuo progetto e invia la pipeline con il seguente parametro:

‑‑prebuild_sdk_container_engine=cloud_build.

Per ulteriori informazioni, consulta Dataflow Runner v2.

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

RESOURCE_POOL_EXHAUSTED

Quando crei una risorsa Google Cloud, si verifica il seguente errore:

Startup of the worker pool in zone ZONE_NAME failed to bring up any of the desired NUMBER workers.
ZONE_RESOURCE_POOL_EXHAUSTED_WITH_DETAILS: Instance 'INSTANCE_NAME' creation failed: The zone 'projects/PROJECT_ID/zones/ZONE_NAME' does not have enough resources available to fulfill the request. '(resource type:RESOURCE_TYPE)'.

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

Per risolvere il problema, puoi attendere o creare la stessa risorsa in un'altra zona.

Come soluzione alternativa, implementa un ciclo di ripetizione per i job in modo che, quando si verifica un errore di esaurimento scorte, il job riprovi automaticamente finché le risorse non sono disponibili. Per creare un ciclo di ripetizione, implementa il seguente flusso di lavoro:

1. Crea un job Dataflow e ottieni l'ID job.
2. Effettua il polling dello stato del job finché non diventa RUNNING o FAILED.
   • Se lo stato del job è RUNNING, esci dal ciclo di ripetizione.
   • Se lo stato del job è FAILED, utilizza l'API Cloud Logging per eseguire query sui log del job in cerca della stringa ZONE_RESOURCE_POOL_EXHAUSTED_WITH_DETAILS. Per maggiori informazioni, consulta Utilizzare i log della pipeline.
     • Se i log non contengono la stringa, esci dal ciclo di ripetizione.
     • Se i log contengono la stringa, crea un job Dataflow, recupera l'ID job e riavvia il ciclo di ripetizione.

Come best practice, distribuisci le risorse su più zone e regioni per tollerare le interruzioni.

Quota del progetto ... o criteri di controllo dell'accesso che impediscono l'operazione

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 su cui si basa la creazione di worker Dataflow.
• La tua organizzazione ha imposto limitazioni che vietano alcuni aspetti della procedura di creazione delle istanze VM, ad esempio l'account utilizzato o la zona di destinazione.

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

Esamina il log dell'istanza VM

1. Vai al visualizzatore Cloud Logging
2. Nell'elenco a discesa Risorsa sottoposta a controllo, seleziona Istanza VM.
3. Nell'elenco a discesa Tutti i log, seleziona compute.googleapis.com/activity_log.
4. Esamina il log per verificare la presenza di eventuali voci relative al mancato completamento della creazione dell'istanza VM.

Verifica il tuo utilizzo delle quote di Compute Engine

1. Per visualizzare l'utilizzo delle risorse di Compute Engine rispetto alle quote di Dataflow per la zona di destinazione, esegui il seguente comando:

   gcloud compute regions describe [REGION]

2. Esamina i risultati per le seguenti risorse per verificare se alcune superano la 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 pagina delle policy dell'organizzazione.
2. Esamina i vincoli per verificare se potrebbero limitare la creazione di istanze VM per l'account in uso (per impostazione predefinita, l'account di servizio Dataflow) o nella zona di destinazione.
3. Se hai un criterio che limita l'utilizzo di indirizzi IP esterni, disattivali per questo job. Per ulteriori informazioni su come disattivare gli indirizzi IP esterni, consulta la pagina Configurare l'accesso a internet e le regole firewall.

Timeout durante l'attesa di un aggiornamento dal worker

Quando un job Dataflow non va a buon fine, viene visualizzato 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 lo spazio di scambio. Per risolvere il problema, come primo passaggio, prova a eseguire di nuovo il job. 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 la seguente opzione di avvio della pipeline:

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

La modifica del tipo di lavoratore potrebbe influire sul costo fatturato. Per ulteriori informazioni, consulta Risolvere gli errori di esaurimento della memoria di Dataflow.

Questo errore può verificarsi anche quando i dati contengono una hot key. 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 su tasti di scelta rapida e possibili soluzioni, consulta Scrivere pipeline Dataflow tenendo presente la scalabilità.

Per altre soluzioni a questo problema, consulta È stata rilevata una hot key.

Se il codice Python chiama il codice C/C++ utilizzando il meccanismo di estensione Python, controlla se il codice dell'estensione rilascia il blocco dell'interprete globale (GIL) di Python nelle parti di codice con un'elaborazione intensiva che non accedono allo stato di Python. Se il GIL non viene rilasciato per un periodo di tempo prolungato, potresti visualizzare 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 estensioni come Cython e PyBind hanno primitive per controllare lo stato di GIL. Puoi anche rilasciare manualmente il GIL e riacquistarlo prima di restituire il controllo all'interprete Python utilizzando le macro Py_BEGIN_ALLOW_THREADS e Py_END_ALLOW_THREADS. Per ulteriori informazioni, consulta Stato del thread e blocco dell'interprete globale nella documentazione di Python.

Potrebbe essere possibile recuperare le stacktrace di un thread che detiene 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=`sudo crictl ps | grep python | head -1 | awk '{print $1}'`

# Start a shell in the running container.
sudo crictl 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, Dataflow assume che ogni processo Python in esecuzione sui worker utilizzi in modo efficiente un core vCPU. Se il codice della pipeline aggira le limitazioni del GIL, ad esempio utilizzando librerie implementate in C++, gli elementi di elaborazione potrebbero utilizzare le risorse di più di un core vCPU e i worker potrebbero non ricevere risorse CPU sufficienti. Per risolvere il problema, riduci il numero di thread sui worker.

Errori temporanei durante la pubblicazione nell'argomento

Quando il job di streaming utilizza la modalità di streaming 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 funziona correttamente, questo errore è benigno e puoi ignorarlo. Dataflow tenta automaticamente di inviare i messaggi Pub/Sub con un ritardo di backoff.

Problemi di dipendenza Java

Classi e librerie incompatibili possono causare problemi di dipendenza da Java. Quando la pipeline presenta problemi di dipendenza da Java, potrebbe verificarsi uno dei seguenti errori:

• NoClassDefFoundError: questo errore si verifica quando un'intera classe non è disponibile durante il runtime.
• NoSuchMethodError: questo errore si verifica quando la classe nel percorso di classe utilizza una versione che non contiene il metodo corretto o quando la firma del metodo è cambiata.
• NoSuchFieldError: questo errore si verifica quando la classe nel percorso di classe 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. Quando utilizzi il JAR uber (ombreggiato), non includere le librerie che utilizzano le firme (come Conscrypt) nello stesso JAR.

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

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

<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>

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

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

InaccessibleObjectException in JDK 17 e versioni successive

Quando esegui pipeline con la piattaforma Java, Standard Edition Development Kit (JDK) 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 dalla versione 9 di Java, sono necessarie opzioni della JVM (Java Virtual Machine) con modulo aperto per accedere ai componenti interni del JDK. In Java 16 e versioni successive, le opzioni JVM del modulo aperte sono sempre necessarie per accedere agli elementi interni di JDK.

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

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

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

Per ulteriori informazioni, consulta la documentazione della classe DataflowPipelineOptions.

Errori del connettore BigQuery

Le sezioni seguenti contengono gli errori comuni del connettore BigQuery che potresti riscontrare e i passaggi per risolverli o per la risoluzione dei problemi.

quotaExceeded

Quando utilizzi il connettore BigQuery per scrivere in BigQuery utilizzando gli inserimenti in streaming, il throughput di scrittura è inferiore alle aspettative e potrebbe verificarsi il seguente errore:

quotaExceeded

Il throughput lento potrebbe essere dovuto al fatto che la pipeline supera la quota di inserimento di flussi di dati di BigQuery disponibile. In questo caso, nei log dei worker di Dataflow vengono visualizzati messaggi di errore relativi alle quote di BigQuery (cerca gli errori quotaExceeded).

Se visualizzi errori quotaExceeded, per risolvere il problema:

• Quando utilizzi l'SDK Apache Beam per Java, imposta l'opzione di destinazione BigQuery ignoreInsertIds().
• Quando utilizzi l'SDK Apache Beam per Python, utilizza l'opzione ignore_insert_ids.

Queste impostazioni ti rendono idoneo per un throughput di inserimento di flussi di dati di BigQuery di 1 GB al secondo per progetto. Per ulteriori informazioni sui limiti relativi alla duplicazione automatica dei messaggi, consulta la documentazione di BigQuery. Per aumentare la quota di inserimento di flussi di dati di BigQuery oltre 1 Gbps, invia una richiesta tramite la console Google Cloud.

Se non visualizzi errori relativi alla quota nei log dei worker, il problema potrebbe essere che i parametri relativi al raggruppamento o al batching predefiniti non forniscono un parallelismo adeguato per la scalabilità della pipeline. Puoi modificare diverse configurazioni relative al connettore BigQuery di Dataflow per ottenere il rendimento previsto quando scrivi in BigQuery utilizzando gli inserimenti in streaming. Ad esempio, per l'SDK Apache Beam per Java, modifica numStreamingKeys in modo che corrisponda al numero massimo di worker e valuta la possibilità di aumentare insertBundleParallelism per configurare il connettore BigQuery in modo che scriva in BigQuery utilizzando più thread paralleli.

Per le configurazioni disponibili nell'SDK Apache Beam per Java, consulta BigQueryPipelineOptions e per le configurazioni disponibili nell'SDK Apache Beam per Python, consulta la trasformazione WriteToBigQuery.

rateLimitExceeded

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

rateLimitExceeded

Questo errore si verifica se a BigQuery vengono inviate troppe richieste API in un breve periodo di tempo. BigQuery ha limiti di quota a breve termine. È possibile che la pipeline Dataflow superi temporaneamente una quota di questo tipo. In questo scenario, le richieste API dalla pipeline Dataflow a BigQuery potrebbero non riuscire, il che potrebbe comportare errori rateLimitExceeded nei log dei worker.

Dataflow riprova questi errori, quindi puoi ignorarli in tutta sicurezza. Se ritieni che la tua pipeline sia interessata da errorirateLimitExceeded, contatta l'assistenza clienti Google Cloud.

Errori vari

Le sezioni seguenti contengono errori vari che potresti riscontrare e i passaggi per risolverli o per la risoluzione dei problemi.

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 funziona correttamente, questo errore è benigno e puoi ignorarlo. A volte le immagini di base delle VM worker producono questo messaggio. Dataflow risponde e risolve automaticamente il problema di fondo.

Esiste una richiesta di funzionalità per modificare il livello di questo messaggio da WARN a INFO. Per ulteriori informazioni, consulta Abbassare il livello del log degli errori di lancio del sistema Dataflow su WARN o INFO.

Errore durante l'inizializzazione del sondatore dei plug-in dinamici

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 funziona correttamente, questo errore è benigno e puoi ignorarlo. Questo errore si verifica quando il job Dataflow tenta di creare una directory senza le autorizzazioni di scrittura necessarie e l'attività non va a buon fine. Se il job va a buon fine, la directory non era necessaria o Dataflow ha risolto il problema di fondo.

Esiste una richiesta di funzionalità per modificare il livello di questo messaggio da WARN a INFO. Per ulteriori informazioni, consulta Abbassare il livello del log degli errori di lancio del sistema Dataflow su WARN o INFO.

Oggetto non trovato: pipeline.pb

Quando elenchi i job utilizzando l'opzione 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 di staging per il job.

Ignorare la sincronizzazione del 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"

In alternativa:

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 funziona correttamente, questi errori sono innocui e puoi ignorarli. Il messaggio container runtime status check may not have completed yet si verifica 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 contenitore è stato avviato di recente o è in fase di riavvio.

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

Esiste una richiesta di funzionalità per modificare il livello di questo messaggio da WARN a INFO. Per ulteriori informazioni, consulta Abbassare il livello del log degli errori di lancio del sistema Dataflow su WARN o INFO.

Consigli

Per indicazioni sui consigli generati da Dataflow Insights, consulta Approfondimenti.