Risoluzione dei problemi relativi ai modelli flessibili

Questa pagina fornisce suggerimenti per la risoluzione dei problemi e strategie di debug che potrebbero esserti utili se hai utilizzando i modelli flessibili di Dataflow. Queste informazioni possono aiutarti a rilevare un timeout di polling, determinare il motivo del timeout e risolvere il problema.

Risolvere i problemi di timeout del polling

Questa sezione fornisce la procedura per identificare la causa dei timeout di polling.

Timeout del polling

Il job del modello flessibile potrebbe restituire il seguente messaggio di errore:

Timeout in polling result file: ${file_path}.
Service account: ${service_account_email}
Image URL: ${image_url}
Troubleshooting guide at https://cloud.google.com/dataflow/docs/guides/common-errors#timeout-polling

Questo errore può verificarsi per i seguenti motivi:

  1. L'immagine Docker di base è stata sostituita.
  2. L'account di servizio che compila ${service_account_email} non dispone di alcune autorizzazioni necessarie.
  3. Gli indirizzi IP esterni sono disabilitati e le VM non possono connettersi all'insieme di indirizzi IP esterni utilizzati dalle API e dai servizi Google.
  4. Il programma che crea il grafico impiega troppo tempo per essere completato.
  5. Le opzioni della pipeline vengono sovrascritte.
  6. (Solo Python) Si è verificato un problema con il file requirements.txt.
  7. Si è verificato un errore temporaneo.

Per risolvere il problema, verifica innanzitutto la presenza di errori temporanei controllando i log del job e riprova. Se questi passaggi non risolvono il problema, prova a seguire questi passaggi per la risoluzione dei problemi.

Verifica il punto di ingresso Docker

Prova questo passaggio se stai eseguendo un modello da un'immagine Docker personalizzata anziché utilizzando uno dei modelli forniti.

Verifica il punto di ingresso del container utilizzando il comando seguente:

docker inspect $TEMPLATE_IMAGE

È previsto il seguente output:

Java

/opt/google/dataflow/java_template_launcher

Python

/opt/google/dataflow/python_template_launcher

Se ottieni un output diverso, il punto di ingresso del container Docker con override. Ripristina il valore predefinito di $TEMPLATE_IMAGE.

Controllare le autorizzazioni dell'account di servizio

Verifica che l'account di servizio menzionato nel messaggio abbia le seguenti autorizzazioni:

  • Deve essere in grado di leggere e scrivere il percorso di Cloud Storage che viene compilato ${file_path} nel messaggio.
  • Deve essere in grado di leggere l'immagine Docker che compila ${image_url} nel per creare un nuovo messaggio email.

Configurazione dell'accesso privato Google

Se gli indirizzi IP esterni sono disabilitati, devi consentire a Compute Engine VM da connettere al set di indirizzi IP esterni utilizzato API e servizi Google. Attiva Accesso privato Google sulla subnet utilizzata dall'interfaccia di rete della VM.

Per i dettagli sulla configurazione, consulta Configurare l'accesso privato Google.

Per impostazione predefinita, quando una VM di Compute Engine non ha un indirizzo IP esterno assegnata alla propria interfaccia di rete, può inviare pacchetti solo ad altri Destinazioni degli indirizzi IP.

Controlla se il programma di avvio non riesce a uscire

Il programma che crea la pipeline deve terminare prima che la pipeline possa di Google Cloud. L'errore di polling potrebbe indicare che l'operazione ha richiesto troppo tempo.

Di seguito sono riportate alcune azioni che puoi eseguire per individuare la causa nel codice:

  • Controlla i log del job e verifica se le operazioni sembrano richiedere molto tempo completato. Un esempio è una richiesta di una risorsa esterna.
  • Assicurati che nessun thread stia bloccando l'uscita del programma. Alcuni client potrebbero creano i propri thread e, se questi client non vengono arrestati, il programma attende all'infinito il completamento di questi thread.

Le pipeline lanciate direttamente che non utilizzano un modello non presentano queste limitazioni. Pertanto, se la pipeline ha funzionato direttamente, ma non come modello, l'utilizzo di un modello potrebbe essere la causa principale. Individuare il problema nel modello e correggerlo potrebbe risolvere il problema.

Verificare se le opzioni di pipeline richieste sono eliminate

Quando utilizzi i modelli flessibili, puoi configurare alcune opzioni della pipeline, ma non tutte l'inizializzazione della pipeline. Per Per ulteriori informazioni, consulta la sezione Impossibile leggere il file del job. in questo documento.

Rimuovi Apache Beam dal file dei requisiti (solo Python)

Se il tuo Dockerfile include un elemento requirements.txt con apache-beam[gcp], rimuoverlo dal file e installarlo separatamente. Il seguente comando dimostra come completare questo passaggio:

RUN pip install apache-beam[gcp]
RUN pip install -U -r ./requirements.txt

L'inserimento di Apache Beam nel file dei requisiti può causare lunghi tempi di avvio, e spesso causa un timeout.

Timeout di polling quando si utilizza Python

Se esegui un job Dataflow utilizzando un modello flessibile e Python, il job potrebbe essere in coda per un periodo, non riuscire a essere eseguito e poi visualizzare il seguente errore:

Timeout in polling

Il file requirements.txt utilizzato per installare le dipendenze richieste causa l'errore. Quando avvii un job Dataflow, tutte le dipendenze vengono prima messe in fase per rendere questi file accessibili alle VM worker. Questa procedura comporta il download e la compilazione ogni dipendenza diretta e indiretta nel file requirements.txt. La compilazione di alcune dipendenze potrebbe richiedere diversi minuti. In particolare PyArrow potrebbe richiedono tempo per la compilazione. PyArrow è una dipendenza indiretta usata Apache Beam e la maggior parte delle librerie client di Cloud.

Per ottimizzare le prestazioni del job, usa un Dockerfile o un container personalizzato precompilare le dipendenze. Per ulteriori informazioni, vedi Dipendenze pacchetto in "Configura modelli flessibili".

Errori di avvio del job

La sezione seguente contiene gli errori comuni che causano i fallimenti del lancio dei job e i passaggi per risolverli o per la risoluzione dei problemi.

Problemi di avvio iniziale

Se il processo di avvio del modello ha esito negativo in una fase iniziale, I log dei modelli potrebbero non essere disponibili. Per esaminare i problemi di avvio, abilita il logging della porta seriale per la VM di avvio dei modelli.

Per abilitare il logging per i modelli Java, imposta l'opzione enableLauncherVmSerialPortLogging su true. Per attivare la registrazione per i modelli Python e Go, imposta l'opzione enable_launcher_vm_serial_port_logging su true. Nella console Google Cloud, il parametro è elencato in Parametri facoltativi come Abilita il logging della porta seriale della VM del programma di lancio.

Puoi visualizzare i log di output delle porte seriali della VM di avvio dei modelli in e in Cloud Logging. Per trovare i log per una determinata VM Avvio app, usa la query resource.type="gce_instance" "launcher-number" dove inizia number con la data corrente nel formato YYYMMDD.

Criteri della tua organizzazione potrebbe impedirti di abilitare il logging degli output delle porte seriali.

Impossibile leggere il file del job

Quando provi a eseguire un job da un modello flessibile, il job potrebbe non riuscire con uno dei seguenti errori:

Failed to read the job file : gs://dataflow-staging-REGION-PROJECT_ID/staging/template_launches/TIMESTAMP/job_object with error message: ...: Unable to open template file

Oppure:

Failed to read the result file : gs://BUCKET_NAME with error message: (ERROR_NUMBER): Unable to open template file: gs://BUCKET_NAME

Questo errore si verifica quando le opzioni di inizializzazione della pipeline necessarie vengono sovrascritte. Quando utilizzando i modelli flessibili, puoi configurare alcune opzioni della pipeline, ma non tutte durante durante l'inizializzazione. Se gli argomenti della riga di comando richiesti dal modello flessibile vengono sovrascritti, il job potrebbe ignorare, ignorare o ignorare le opzioni della pipeline trasmesso dall'utilità di avvio dei modelli. Il job potrebbe non essere avviato o un job che non utilizza il modello flessibile potrebbe essere lanciato.

Per evitare questo problema, durante l'inizializzazione della pipeline, non modificare le seguenti opzioni della pipeline nel codice utente o nel file metadata.json:

Java

  • runner
  • project
  • jobName
  • templateLocation
  • region

Python

  • runner
  • project
  • job_name
  • template_location
  • region

Vai

  • runner
  • project
  • job_name
  • template_location
  • region

Autorizzazione negata per la risorsa

Quando provi a eseguire un job da un modello flessibile, il job potrebbe non riuscire con il seguente errore:

Permission "MISSING_PERMISSION" denied on resource "projects/PROJECT_ID/locations/REGION/repositories/REPOSITORY_NAME" (or it may not exist).

Questo errore si verifica quando l'account di servizio utilizzato non dispone di le autorizzazioni di accesso alle risorse necessarie per eseguire un modello flessibile.

Per evitare questo problema, verifica che l'account di servizio disponga delle autorizzazioni richieste. Modifica le autorizzazioni dell'account di servizio in base alle esigenze.

Flag fornito ma non definito

Quando provi a eseguire un modello Go Flex con la pipeline worker_machine_type , la pipeline genera un errore e genera il seguente errore:

flag provided but not defined: -machine_type

Questo errore è causato da un problema noto nelle versioni dell'SDK Apache Beam Go 2.47.0 e precedenti. Per risolvere il problema, esegui l'upgrade ad Apache Beam Go 2.48.0 o versioni successive.

Impossibile recuperare il file jar del server di job remoto

Se tenti di eseguire un job da un modello flessibile quando non sei connesso internet, il job potrebbe non riuscire e restituire il seguente errore:

Unable to fetch remote job server jar at
https://repo.maven.apache.org/maven2/org/apache/beam/beam-sdks-java-io-expansion-service/VERSION/beam-sdks-java-io-expansion-service-VERSION.jar:
\u003curlopen error [Errno 101] Network is unreachable\u003e

Questo errore si verifica perché la VM non è in grado di scaricare Apache Beam pacchetto Java da internet. Questo pacchetto è obbligatorio se esegui un'istanza un job multilingue utilizzando un modello flessibile.

Per risolvere il problema, apporta una delle seguenti modifiche:

  • Connettiti a internet. Quando è connesso a internet, il tuo job può accedere al file richiesto.

  • Includi il pacchetto Java Apache Beam nella directory locale in modo che un job può accedervi localmente. Posiziona il file nella seguente directory: /root/.apache_beam/cache/jars/. Ad esempio: /root/.apache_beam/cache/jars/beam-sdks-java-io-expansion-service-SDK_VERSION.jar.

Impossibile recuperare il file system dal percorso specificato

Quando provi a eseguire un job da un modello flessibile, il job potrebbe non riuscire con il seguente errore:

ValueError: Unable to get filesystem from specified path, please use
the correct path or ensure the required dependency is installed, e.g., pip
install apache-beam[gcp]. Path specified: PATH

Questo errore si verifica quando il job utilizza un'immagine container di Flex Template e l'immagine container non contiene un'installazione di Java.

Per risolvere il problema, aggiungi la seguente riga al Dockerfile:

sh RUN apt-get update && apt-get install -y openjdk-17-jdk

Questo comando installa Java nell'ambiente del contenitore.

Ritardo avvio avvio modello flessibile

Quando invii un job di modello flessibile, la richiesta viene inserita in una coda Spanner. Il programma di avvio del modello recupera il job dalla coda Spanner e poi esegue il modello. Quando Spanner ha un backlog di messaggi, potrebbe verificarsi un ritardo significativo tra il momento in cui invii il job e il momento in cui viene avviato.

Per risolvere questo problema, avvia il modello flessibile da un'altra regione.

I parametri del modello non sono validi

Quando provi a utilizzare l'interfaccia a riga di comando gcloud per eseguire un job che utilizza un modello fornito da Google, si verifica il seguente errore:

ERROR: (gcloud.beta.dataflow.flex-template.run) INVALID_ARGUMENT: The template
parameters are invalid. Details: defaultSdkHarnessLogLevel: Unrecognized
parameter defaultWorkerLogLevel: Unrecognized parameter

Questo errore si verifica perché alcuni modelli forniti da Google non supportano Opzioni defaultSdkHarnessLog e defaultWorkerLog.

Come soluzione alternativa, copia il file di specifiche del modello in un bucket Cloud Storage. Aggiungi i seguenti parametri aggiuntivi al file.

"metadata": {
    ...
    "parameters": [
      ...,
      {
        "name": "defaultSdkHarnessLogLevel",
        "isOptional": true,
        "paramType": "TEXT"
      },
      {
        "name": "defaultWorkerLogLevel",
        "isOptional": true,
        "paramType": "TEXT"
      }
    ]
  }

Dopo aver apportato questa modifica al file del modello, utilizza il seguente comando per eseguire il modello.

--template-file-gcs-location=gs://BUCKET_NAME/FILENAME

Sostituisci i seguenti valori:

  • BUCKET_NAME: il nome del bucket Cloud Storage
  • FILENAME: il nome del file di specifica del modello

I log del programma di lancio del modello flessibile mostrano una gravità errata

Quando il lancio di un modello flessibile personalizzato non va a buon fine, nei file di log viene visualizzato il seguente messaggio con la gravitàERROR:

ERROR: Error occurred in the launcher container: Template launch failed. See console logs.

La causa principale dell'errore di avvio solitamente compare nei log precedenti a questo messaggio con la gravità INFO. Anche se questo livello di log potrebbe non essere corretto, è previsto, perché il programma di lancio del modello flessibile non ha modo di estrarre i dettagli sulla gravità dai messaggi di log prodotti dall'applicazione Apache Beam.

Se vuoi visualizzare la gravità corretta per ogni messaggio nel log del programma di avvio, configura il modello in modo da generare i log in formato JSON anziché in testo normale. Questa configurazione consente al programma di avvio del modello di estrarre la gravità corretta del messaggio log. Utilizza la seguente struttura del messaggio:

{
  "message": "The original log message",
  "severity": "DEBUG/INFO/WARN/ERROR"
}

In Java, puoi utilizzare il logger Logback con un'implementazione di appender JSON personalizzato. Per ulteriori informazioni, consulta Configurazione di esempio di logback e ai Codice di esempio dell'appendice JSON in GitHub.

Questo problema riguarda solo i log generati dall'utilità di avvio dei modelli flessibili al momento dell'avvio della pipeline. Se il lancio è andato a buon fine e la pipeline è in esecuzione, i log prodotti dai worker Dataflow hanno la gravità corretta.

Modelli forniti da Google mostrare la gravità corretta durante l'avvio del job, poiché lo standard fornito da Google utilizzano questo approccio di logging JSON.