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 utilizzi i modelli flessibili di Dataflow. Queste informazioni possono aiutarti a rilevare il timeout del polling, a determinare il motivo del timeout e a correggere il problema.

Risolvere i problemi di timeout del polling

Questa sezione fornisce i passaggi per identificare la causa dei timeout del 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. È stato eseguito l'override dell'immagine Docker di base.
  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 al set di indirizzi IP esterni utilizzati dalle API e dai servizi Google.
  4. Il completamento del programma che crea il grafico richiede troppo tempo.
  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 questo problema, verifica innanzitutto la presenza di errori temporanei controllando i log del job e riprova. Se queste procedure non risolvono il problema, prova a svolgere le seguenti operazioni per la risoluzione dei problemi.

Verifica il punto di ingresso Docker

Prova questo passaggio se esegui un modello da un'immagine Docker personalizzata anziché utilizzare uno dei modelli forniti.

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

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, viene eseguito l'override del punto di ingresso del container Docker. Ripristina il valore predefinito di $TEMPLATE_IMAGE.

Controlla le autorizzazioni degli account di servizio

Verifica che l'account di servizio menzionato nel messaggio disponga delle seguenti autorizzazioni:

  • Deve essere in grado di leggere e scrivere il percorso Cloud Storage che compila ${file_path} nel messaggio.
  • Deve essere in grado di leggere l'immagine Docker che riempie ${image_url} nel messaggio.

Configurazione dell'accesso privato Google

Se gli indirizzi IP esterni sono disabilitati, devi consentire alle VM di Compute Engine di connettersi al set di indirizzi IP esterni utilizzati dalle API e dai servizi Google. Abilita l'accesso privato Google sulla subnet utilizzata dall'interfaccia di rete della VM.

Per i dettagli di configurazione, consulta Configurazione dell'accesso privato Google.

Per impostazione predefinita, quando una VM di Compute Engine non ha un indirizzo IP esterno assegnato alla sua interfaccia di rete, può inviare pacchetti solo ad altre destinazioni di indirizzi IP interni.

Controlla se il programma Avvio app non riesce a uscire

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

Per individuare la causa nel codice:

  • Controlla i log del job e controlla se un'operazione sembra richiedere molto tempo. Un esempio potrebbe essere una richiesta per una risorsa esterna.
  • Assicurati che nessun thread stia bloccando l'uscita dal programma. Alcuni client potrebbero creare i propri thread e, se questi client non vengono arrestati, il programma attende all'infinito prima che vengano uniti.

Le pipeline lanciate direttamente che non utilizzano un modello non hanno queste limitazioni. Di conseguenza, se la pipeline ha funzionato direttamente, ma non come modello, la causa principale potrebbe essere l'utilizzo di un modello. L'individuazione del problema nel modello e la sua correzione potrebbe risolvere il problema.

Verifica se le opzioni della pipeline obbligatorie sono state soppresse

Quando utilizzi i modelli flessibili, puoi configurare alcune opzioni della pipeline, ma non tutte, durante l'inizializzazione della pipeline. 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 Dockerfile include un elemento requirements.txt con apache-beam[gcp], rimuovilo dal file e installalo separatamente. Il comando seguente mostra 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 tempi di avvio lunghi, spesso causando un timeout.

Timeout del polling quando si utilizza Python

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

Timeout in polling

L'errore è causato dal file requirements.txt utilizzato per installare le dipendenze richieste. Quando avvii un job Dataflow, tutte le dipendenze vengono pianificate per prime in modo da rendere accessibili questi file alle VM worker. Questo processo comporta il download e la compilazione di ogni dipendenza diretta e indiretta nel file requirements.txt. La compilazione di alcune dipendenze potrebbe richiedere diversi minuti. In particolare PyArrow potrebbe richiedere del tempo per la compilazione. PyArrow è una dipendenza indiretta utilizzata da Apache Beam e dalla maggior parte delle librerie client di Cloud.

Per ottimizzare le prestazioni del job, usa un Dockerfile o un container personalizzato per preparare le dipendenze. Per ulteriori informazioni, consulta Dipendenze dei pacchetti in "Configurare i modelli flessibili".

Errori di avvio del job

La seguente sezione contiene errori comuni che causano errori di avvio dei job e i passaggi per risolverli o per risolverli.

Problemi relativi all'avvio iniziale

Quando il processo di avvio del modello non va a buon fine in una fase iniziale, i log normali del modello flessibile potrebbero non essere disponibili. Per esaminare i problemi di avvio, abilita il logging delle porte seriali per la VM del programma di avvio dei modelli.

Per abilitare il logging per i modelli Java, imposta l'opzione enableLauncherVmSerialPortLogging su true. Per abilitare il logging 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 delle porte seriali delle VM di Avvio app.

Puoi visualizzare i log di output della porta seriale della VM di avvio dei modelli in Cloud Logging. Per trovare i log per una determinata VM dell'avvio app, utilizza la query resource.type="gce_instance" "launcher-number" in cui number inizia con la data corrente nel formato YYYMMDD.

Il criterio dell'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 utilizzi i modelli flessibili, puoi configurare alcune opzioni della pipeline, ma non tutte, durante l'inizializzazione della pipeline. Se gli argomenti della riga di comando richiesti dal modello flessibile vengono sovrascritti, il job potrebbe ignorare, sostituire o ignorare le opzioni della pipeline trasmesse dall'avvio dei modelli. Potrebbe non essere possibile avviare il job oppure un job che non utilizza il modello flessibile potrebbe essere avviato.

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

Go

  • 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 e generare 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 delle autorizzazioni per accedere alle risorse necessarie per eseguire un modello flessibile.

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

Flag fornito ma non definito

Quando provi a eseguire un modello Go Flex con l'opzione della pipeline worker_machine_type, la pipeline si guasta con l'errore seguente:

flag provided but not defined: -machine_type

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

Ritardo Avvio app Flex

Quando invii un job del modello flessibile, la richiesta del job viene inviata a una coda Spanner. L'Avvio app dei modelli prende il job dalla coda Spanner e poi esegue il modello. Quando Spanner ha un backlog di messaggi, potrebbe verificarsi un ritardo significativo tra l'invio del job e l'avvio del job.

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

I parametri del modello non sono validi

Quando provi a utilizzare gcloud CLI 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 le opzioni defaultSdkHarnessLog e defaultWorkerLog.

Come soluzione alternativa, copia il file delle 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 comando seguente per eseguirlo.

--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 delle specifiche del modello

I log di Avvio applicazioni dei modelli flessibili mostrano la gravità errata

Quando l'avvio 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 in genere compare nei log precedenti a questo messaggio con gravità INFO. Anche se questo livello di log potrebbe non essere corretto, è previsto perché l'Avvio app del modello flessibile non ha un modo per estrarre i dettagli sulla gravità dai messaggi di log generati dall'applicazione Apache Beam.

Se vuoi visualizzare la gravità corretta per ogni messaggio nel log di Avvio app, configura il tuo modello per generare log in formato JSON anziché in testo normale. Questa configurazione consente all'Avvio app dei modelli di estrarre la gravità corretta dei messaggi di log. Utilizza la seguente struttura di messaggi:

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

In Java, puoi utilizzare il Logback logger con un'implementazione appender JSON personalizzata. Per maggiori informazioni, consulta la pagina relativa alla configurazione di esempio di logback e al codice di esempio dell'appender JSON in GitHub.

Questo problema interessa solo i log generati dall'Avvio app flessibile dei modelli all'avvio della pipeline. Una volta che il lancio ha esito positivo e la pipeline è in esecuzione, i log prodotti dai worker Dataflow hanno la gravità adeguata.

I modelli forniti da Google mostrano la gravità corretta durante l'avvio del job, perché i modelli forniti da Google utilizzano questo approccio di logging JSON.