Risolvere i 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 template flessibili di Dataflow. Per impostazione predefinita, il processo di avvio del template flessibile ha un timeout di 12 minuti. Questo processo di avvio include il pull dell'immagine container del template e l'esecuzione del codice per creare il grafico del job. Se l'avvio non viene completato entro questa finestra di 12 minuti, il job non va a buon fine e viene visualizzato l'errore "Timeout in polling result file". Queste informazioni possono aiutarti a rilevare un timeout di polling, determinare il motivo del timeout e correggere il problema.

Errore durante il caricamento dell'elenco dei template nella console Google Cloud

Nella console Google Cloud , quando provi a visualizzare l'elenco dei template nella pagina Crea job da template di Dataflow, viene visualizzato un errore simile al seguente:

Error retrieving templates. Custom templates can still be used.

Se la tua organizzazione utilizza le policy dei confini di accesso dell'entità (PAB), alle entità (come utenti o service account) potrebbe essere impedito di visualizzare ed eseguire i template forniti da Google. Per risolvere il problema, prova a seguire le indicazioni riportate in Accedi ai modelli forniti da Google con le policy dei limiti di accesso delle entità.

Errori di timeout del polling

Il job potrebbe restituire uno dei seguenti messaggi di errore:

Timeout in polling result file: 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 FILE_PATH.
3. Transient errors occurred, please try again.

Timeout in polling result file: FILE_PATH.
Service account: SERVICE_ACCOUNT
Image URL: IMAGE_PATH
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. Il account di servizio che compila SERVICE_ACCOUNT 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 di Google e dai servizi.
  4. La VM di avvio non può risolvere o accedere a gcr.io.
  5. Immagine container di template flessibile di grandi dimensioni.
  6. Il programma che crea il grafico impiega troppo tempo per essere completato.
  7. Il codice in esecuzione nella VM di avvio impiega troppo tempo per essere completato.
  8. Errori di rete o di Cloud Storage intermittenti.
  9. Le opzioni della pipeline vengono sovrascritte.
  10. Utenti Python: l'installazione o la gestione temporanea delle dipendenze richiede troppo tempo.
  11. Si è verificato un errore temporaneo.

Per risolvere il problema, controlla innanzitutto se sono presenti errori temporanei controllando i log del job e riprovando.

Segui le indicazioni riportate nella sezione Problemi di avvio iniziale per attivare il logging della porta seriale, che potrebbe rivelare ulteriori informazioni.

Se questi passaggi non risolvono il problema, prova a svolgere le seguenti operazioni di risoluzione dei problemi.

(Facoltativo) Esegui i template per diagnosticare ulteriormente il problema

Per identificare ulteriormente quale dei motivi precedenti potrebbe causare questo errore, utilizza le seguenti strategie:

  1. Esegui il modello WordCount fornito da Google. Assicurati di fornire parametri univoci per il tuo caso d'uso, come la subnet di un progetto VPC condiviso, l'IP privato per le VM worker e il account di servizio worker Dataflow che vuoi utilizzare. Per saperne di più su come fornire questi parametri, consulta il riferimento gcloud e il riferimento API.

    Se riesci a completare correttamente questo job, significa che il networking, le autorizzazioni IAM e l'accesso privato Google sono probabilmente configurati correttamente.

  2. Completa la guida rapida Esegui una pipeline utilizzando il generatore di job, che esegue il job come template flessibile. Se il job non riesce prima di avviare la VM worker, accedi alla VM di lancio e prova a scaricare un'immagine Docker di esempio utilizzando un comando simile al seguente:

    docker run --entrypoint /bin/bash -it gcr.io/dataflow-templates/2025-03-11-00_rc02/yaml-template

    Se questo comando non va a buon fine, potrebbe esserci un problema di rete con il download delle immagini. In questo caso, collabora con il tuo team di networking interno.

  3. Esegui un template flessibile fornito da Google e controlla il risultato. Se il job del modello fornito da Google viene completato correttamente, significa che il problema è probabilmente correlato ai file di codice del modello personalizzato specifico. In questo caso, devi continuare a risolvere i problemi del tuo codice specifico per risolvere il problema.

Verifica l'entrypoint Docker

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

Controlla l'entrypoint del container utilizzando il seguente comando:

docker inspect $TEMPLATE_IMAGE

L'output previsto è il seguente:

Java

/opt/google/dataflow/java_template_launcher

Python

/opt/google/dataflow/python_template_launcher

Se l'output è diverso, l'entrypoint del container Docker è stato sostituito. Ripristina $TEMPLATE_IMAGE sul valore predefinito.

Controlla le autorizzazioni del account di servizio

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

  • Deve essere in grado di leggere e scrivere il percorso di Cloud Storage che compila ${file_path} nel messaggio.
  • Deve essere in grado di leggere l'immagine Docker che sostituisce ${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 all'insieme di indirizzi IP esterni utilizzati dalle API di Google e dai servizi Google. Abilita l'accesso privato Google sulla subnet utilizzata dall'interfaccia di rete della VM.

Per i dettagli sulla 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 con indirizzi IP interni.

Problemi di accesso a GCR.io

Le VM di avvio dei template flessibili richiedono l'accesso a gcr.io per eseguire il pull di un container dell'agente Logging (gcr.io/dataflow-templates-base/template-launcher-logger-distroless). Questo agente è responsabile dello streaming dei log di avvio in Cloud Logging. Se la VM di avvio non riesce a risolvere o connettersi a gcr.io, il processo di avvio potrebbe non rispondere, causando un timeout di polling.

Questo problema può verificarsi anche se l'immagine del modello personalizzato è archiviata in Artifact Registry, perché l'agente Logging viene sempre estratto da gcr.io.

Per diagnosticare e risolvere il problema:

  1. Attiva il logging della porta seriale: segui i passaggi descritti nella sezione Problemi di avvio iniziale. Se noti che il processo cloud-init è bloccato o se si verificano errori relativi a gcr-wait-online.service, è probabile che si tratti di un problema di DNS o di rete.

  2. Accedi alla VM di avvio tramite SSH: utilizza il comando gcloud compute ssh per connetterti alla VM di avvio mentre è ancora in esecuzione:

    gcloud compute ssh launcher-JOB_ID --tunnel-through-iap

    Sostituisci JOB_ID con l'ID del tuo job Dataflow.

  3. Verifica la risoluzione DNS: esegui i seguenti comandi all'interno della VM di avvio:

    curl -I https://gcr.io

    Se il comando non va a buon fine e viene visualizzato un errore "Could not resolve host", nella configurazione DNS manca una voce per gcr.io.

  4. Controlla se sono presenti servizi di avvio bloccati: esamina il log di output cloud-init:

    sudo cat /var/log/cloud-init-output.log

    Cerca i messaggi che indicano che il processo è in attesa della rete o che gcr.io diventi accessibile.

Inoltre, assicurati che le impostazioni DNS del VPC consentano la risoluzione di gcr.io. In alcune configurazioni di rete privata, potrebbe essere necessario aggiungere un record DNS A specifico per gcr.io che punti agli intervalli IP delle API di Google con limitazioni o delle API di Google private.

Immagine container di grandi dimensioni

Se l'immagine container del template flessibile è di grandi dimensioni, il pull e l'avvio del template potrebbero superare il timeout predefinito di 12 minuti, causando l'errore del job.

Per mitigare il problema, prova le seguenti strategie:

  • Ottimizza l'immagine per ridurne le dimensioni e velocizzare il processo di pull.
  • Utilizza il flag --launcher-machine-type per selezionare un tipo di macchina con più core della CPU, in modo da eseguire il pull dell'immagine più velocemente e velocizzare l'avvio.
  • Estendi il timeout di avvio oltre il limite predefinito di 12 minuti (720 secondi) utilizzando il flag --launcher-vm-timeout-secs in gcloud CLI o l'opzione di avvio ft_launch_timeout_secs nell'API REST e in Managed Service for Apache Airflow. Per esempi, consulta Estendi il timeout di avvio del template flessibile.

Controlla se il programma di avvio non si chiude

Il programma che costruisce la pipeline deve terminare prima che la pipeline possa essere avviata. L'errore di polling potrebbe indicare che l'operazione ha richiesto troppo tempo.

Ecco alcune azioni che puoi eseguire per individuare la causa nel codice:

  • Assicurati che non ci siano thread che impediscono l'uscita dal programma. Alcuni client potrebbero creare i propri thread e, se questi client non vengono arrestati, il programma attende all'infinito che questi thread vengano uniti.
  • Nel codice che definisce la pipeline, non utilizzare waitUntilFinish (per Java) o wait_until_finish (per Python). Queste funzioni impediscono l'uscita dal programma, il che impedisce al template flessibile di avviare la pipeline.

Le pipeline avviate 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.

Codice a lunga esecuzione nella VM di avvio

Se l'esecuzione del codice nel programma principale richiede troppo tempo, il template flessibile potrebbe scadere prima dell'avvio della pipeline. Questo può accadere se il codice esegue calcoli complessi o effettua chiamate sincrone a risorse esterne durante l'inizializzazione.

Per diagnosticare questo problema, controlla i log dei job per individuare eventuali operazioni che richiedono molto tempo per essere completate. Ad esempio, richieste di risorse esterne, ricerche di dati di grandi dimensioni o logica di inizializzazione complessa che puoi spostare nella fase di esecuzione della pipeline. Se la pipeline richiede ancora più di 12 minuti per l'avvio dopo l'ottimizzazione dell'inizializzazione, consulta Estendi il timeout di avvio del template flessibile.

Errori di rete o di Cloud Storage intermittenti

A causa di un'elevata latenza di rete o di problemi temporanei con l'API Cloud Storage, possono verificarsi errori intermittenti "Timeout in polling result file" o "Failed to read the result file". La contesa di rete cronica nel VPC, in particolare all'interno del percorso di accesso privato Google, spesso causa latenze di 400-500 ms.

Un "Timeout in polling result file" (Timeout nel file dei risultati del polling) è in genere un errore lento, mentre un "Failed to read the result file" (Impossibile leggere il file dei risultati) è un errore rapido, ma entrambi spesso indicano lo stesso problema di connettività sottostante.

Per diagnosticare questi errori intermittenti:

  1. Controlla la latenza di rete: monitora la latenza di rete all'interno del VPC. Una latenza elevata prolungata può causare timeout quando la VM di avvio tenta di scrivere o leggere il file dei risultati del job da Cloud Storage.

  2. Monitora le metriche dell'API Cloud Storage:

    1. Nella console Google Cloud , vai alla dashboard API e servizi.

      Vai ad API e servizi abilitati

    2. Filtra e seleziona l'API Cloud Storage.

    3. Esamina i grafici relativi al Traffico (byte inviati e ricevuti) e alla Percentuale di errori.

    4. Cerca picchi di errori 5xx (ad esempio errori 503) che corrispondono all'ora esatta degli errori del job.

Se identifichi picchi di errori o latenza elevata, esamina le prestazioni di rete del VPC o contatta l'assistenza clienti Google Cloud per ricevere assistenza in caso di potenziali interruzioni del servizio.

Verifica se le opzioni della pipeline richieste sono state soppresse

Quando utilizzi i template flessibili, puoi configurare alcune, ma non tutte, le opzioni della pipeline durante l'inizializzazione della pipeline. Per saperne di più, consulta la sezione Impossibile leggere il file del job in questo documento.

Utenti Python: gestione delle dipendenze

Se esegui un job di template flessibile Python che fornisce dipendenze aggiuntive in un file requirements.txt, l'avvio del job potrebbe non riuscire. Questo errore si verifica quando il download o l'installazione delle dipendenze specificate nel file dei requisiti richiede più tempo di quello assegnato per l'avvio del modello flessibile.

Per ottimizzare le prestazioni del job, pacchettizza in anticipo le dipendenze durante la creazione del template per evitare di doverle scaricare o installare durante l'avvio del template. Per saperne di più, consulta la sezione Dipendenze dei pacchetti per Python in "Configura i template flessibili". Se la gestione temporanea delle dipendenze o la creazione del grafico di esecuzione supera ancora il timeout di avvio predefinito di 12 minuti, consulta Estendi il timeout di avvio del template flessibile.

Estendi il timeout di avvio del template flessibile

Per impostazione predefinita, Dataflow applica un timeout di 720 secondi (12 minuti) alla fase di avvio del template flessibile. Se il pull di immagini container di grandi dimensioni, la gestione temporanea delle dipendenze o la creazione di grafici di esecuzione complessi richiedono più di 720 secondi, puoi aumentare questo timeout configurando l'opzione di timeout di avvio per il tuo metodo di avvio.

gcloud CLI

Per estendere il timeout della VM di avvio quando esegui un template flessibile da gcloud CLI, passa il flag --launcher-vm-timeout-secs al comando gcloud dataflow flex-template run:

gcloud dataflow flex-template run JOB_NAME \
  --template-file-gcs-location=TEMPLATE_GCS_PATH \
  --region=REGION \
  --launcher-vm-timeout-secs=TIMEOUT_SECONDS

Sostituisci i seguenti valori:

  • JOB_NAME: il nome del job Dataflow.
  • TEMPLATE_GCS_PATH: l'URI Cloud Storage del file di specifica del template flessibile, ad esempio gs://my-bucket/templates/my-template.json.
  • REGION: la regione Dataflow in cui viene eseguito il job.
  • TIMEOUT_SECONDS: la durata del timeout della VM di avvio in secondi. Specifica un numero intero positivo senza un suffisso di unità. Il timeout predefinito è 720, ovvero 12 minuti. Per estendere il timeout, specifica un numero intero maggiore di 720 e fino a 5400, ovvero 90 minuti, ad esempio 1200 per 20 minuti o 1800 per 30 minuti.

API REST

Quando avvii un template flessibile chiamando l'endpoint REST projects.locations.flexTemplates.launch, imposta la chiave ft_launch_timeout_secs nella mappa launchParameter.launchOptions su una stringa contenente la durata del timeout in secondi come numero intero, senza un suffisso di unità:

{
  "launchParameter": {
    "jobName": "JOB_NAME",
    "containerSpecGcsPath": "TEMPLATE_GCS_PATH",
    "launchOptions": {
      "ft_launch_timeout_secs": "TIMEOUT_SECONDS"
    }
  }
}

Sostituisci i seguenti valori:

  • JOB_NAME: il nome del job Dataflow.
  • TEMPLATE_GCS_PATH: l'URI Cloud Storage del file di specifica del template flessibile, ad esempio gs://my-bucket/templates/my-template.json.
  • TIMEOUT_SECONDS: la durata del timeout della VM di avvio in secondi. Specifica un numero intero positivo come stringa senza un suffisso di unità. Il timeout predefinito è "720", ovvero 12 minuti. Per estendere il timeout, specifica un numero intero maggiore di 720 e fino a 5400, ovvero 90 minuti, ad esempio "1200" per 20 minuti o "1800" per 30 minuti.

Managed Airflow

Quando orchestri i job dei template flessibili in Managed Airflow o Apache Airflow con l'operatore DataflowStartFlexTemplateOperator, includi la chiave ft_launch_timeout_secs in launchParameter.launchOptions nel dizionario body:

from airflow.providers.google.cloud.operators.dataflow import (
    DataflowStartFlexTemplateOperator,
)

start_flex_template = DataflowStartFlexTemplateOperator(
    task_id="start_flex_template",
    project_id="PROJECT_ID",
    location="REGION",
    body={
        "launchParameter": {
            "jobName": "JOB_NAME",
            "containerSpecGcsPath": "TEMPLATE_GCS_PATH",
            "launchOptions": {
                "ft_launch_timeout_secs": "TIMEOUT_SECONDS",
            },
        }
    },
)

Sostituisci i seguenti valori:

  • PROJECT_ID: l'ID del tuo progetto Google Cloud .
  • REGION: la regione Dataflow in cui viene eseguito il job.
  • JOB_NAME: il nome del job Dataflow.
  • TEMPLATE_GCS_PATH: l'URI Cloud Storage del file di specifica del template flessibile, ad esempio gs://my-bucket/templates/my-template.json.
  • TIMEOUT_SECONDS: la durata del timeout della VM di avvio in secondi. Specifica un numero intero positivo come stringa senza un suffisso di unità. Il timeout predefinito è "720", ovvero 12 minuti. Per estendere il timeout, specifica un numero intero maggiore di 720 e fino a 5400, ovvero 90 minuti, ad esempio "1200" per 20 minuti o "1800" per 30 minuti.

Errori di avvio dei job

La sezione seguente contiene gli errori comuni che causano errori di avvio dei job e i passaggi per risolverli o eseguire il relativo troubleshooting.

Autorizzazione negata durante il caricamento di un file modello

Quando provi a eseguire un modello fornito da Google utilizzando gcloud CLI, viene visualizzato un errore simile al seguente:

ERROR: (gcloud.dataflow.flex-template.run) PERMISSION_DENIED: Template file
failed to load: TEMPLATE_PATH. Permissions denied.
USER does not have storage.objects.get access to the Google
Cloud Storage object. Operations on resource are denied due to an IAM
Principal Access Boundary Policy.

TEMPLATE_PATH è il percorso di un template in un bucket Cloud Storage che contiene i template forniti da Google, ad esempio gs://dataflow-templates o gs://dataflow-templates-REGION_NAME.

Se la tua organizzazione utilizza le policy dei confini di accesso dell'entità (PAB), alle entità (come utenti o service account) potrebbe essere impedito di visualizzare ed eseguire i template forniti da Google. Per risolvere il problema, prova a seguire le indicazioni riportate in Accedi ai modelli forniti da Google con le policy dei limiti di accesso delle entità.

Problemi relativi all'avvio anticipato

Quando il processo di avvio del template non va a buon fine in una fase iniziale, i log dei template flessibili standard potrebbero non essere disponibili. Per esaminare i problemi di avvio, attiva il logging della porta seriale per la VM di avvio dei modelli.

Per abilitare il logging per i template Java, imposta l'opzione enableLauncherVmSerialPortLogging su true. Per abilitare il logging per i template 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 di Launcher.

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

La policy dell'organizzazione potrebbe impedirti di attivare il logging degli output della porta seriale.

Impossibile leggere il file del job

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

Failed to read the job file : gs://dataflow-staging-REGION-PROJECT_ID/staging/template_launches/TIMESTAMP/job_object...

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

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

Impossibile leggere il file dei risultati

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

Failed to read the result file : gs://BUCKET_NAME...

Questo errore si verifica quando il service account predefinito di Compute Engine non dispone di tutte le autorizzazioni necessarie per eseguire un template flessibile.

Per l'elenco delle autorizzazioni richieste, consulta Autorizzazioni per eseguire un template flessibile.

Questo errore può anche essere causato da:

Autorizzazione negata per la risorsa

Quando provi a eseguire un job da un template 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 il account di servizio utilizzato non dispone delle autorizzazioni per accedere alle risorse necessarie per eseguire un template flessibile.

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

Flag fornito, ma non definito

Quando provi a eseguire un template flessibile Go con l'opzione della pipeline worker_machine_type, la pipeline non va a buon fine e viene visualizzato il seguente errore:

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.

Impossibile recuperare il file jar del server dei job remoto

Se provi a eseguire un job da un template flessibile quando non hai una connessione a internet, il job potrebbe non riuscire con 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 il pacchetto Java Apache Beam da internet. Questo pacchetto è obbligatorio quando esegui un job multilingue utilizzando un template flessibile.

Per risolvere il problema, apporta una delle seguenti modifiche:

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

  • Includi il pacchetto Java Apache Beam nella directory locale in modo che il job possa accedervi localmente. Inserisci 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 template 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 un template flessibile 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 container.

Esaurimento delle risorse della VM di Launcher

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

Failed to start the VM, launcher-ID, used for launching because of status code: INTERNAL, reason: Unknown error in operation 'OPERATION_ID': [ZONE_RESOURCE_POOL_EXHAUSTED_WITH_DETAILS] 'The zone 'projects/PROJECT_ID/zones/ZONE_ID' does not have enough resources available to fulfill the request.

Il nome della VM launcher-ID rappresenta il nome della VM di avvio. La VM di avvio è responsabile della raccolta delle risorse del job, come il codice e l'immagine del template, prima di creare e inviare il grafico del job al servizio Dataflow per avviare il lavoro.

Se non specifichi il parametro launcherMachineType, Dataflow sceglie un tipo di macchina predefinito per la VM di avvio, in genere e2-standard-2. Questa scelta è indipendente dal worker machineType. Se questo tipo di macchina predefinito non è disponibile nella regione o nella zona del job, possono verificarsi errori di esaurimento delle risorse. Per utilizzare un tipo di macchina specifico, imposta launcherMachineType.

Per risolvere il problema, utilizza una delle seguenti strategie:

  • Aggiorna il tipo di macchina di avvio con un tipo di macchina diverso e riprova a eseguire il job.
  • Se imposti il parametro zone, rimuovilo in modo che Dataflow possa posizionare la VM di avvio in una zona con capacità.
  • Avvia il template flessibile da un'altra regione.

Ritardo del programma di avvio del template flessibile

Quando invii un job con un template flessibile, la richiesta del job viene inserita in una coda di Spanner. Il programma di avvio dei modelli preleva il job dalla coda di 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 quello in cui viene avviato.

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

I parametri del template non sono validi

Quando provi a utilizzare gcloud CLI per eseguire un job che utilizza un template 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 template forniti da Google non supportano le opzioni defaultSdkHarnessLog e defaultWorkerLog.

Per risolvere il problema, utilizza il metodo appropriato per il tipo di modello.

Template flessibili

Per i template flessibili, utilizza il flag --additional-pipeline-options per passare le opzioni della pipeline come stringa. Ad esempio, utilizzando il comando gcloud dataflow flex-template run:

gcloud dataflow flex-template run JOB_NAME \
--template-file-gcs-location=GCS_TEMPLATE_PATH \
--additional-pipeline-options=defaultSdkHarnessLogLevel=WARN,defaultWorkerLogLevel=WARN

Sostituisci i seguenti valori:

  • JOB_NAME: il nome del job Dataflow
  • GCS_TEMPLATE_PATH: il percorso Cloud Storage del file del template
Modelli classici

Per i modelli classici, la soluzione alternativa consiste nel copiare il file di specifica del modello in un bucket Cloud Storage e aggiungere 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 template, utilizza il seguente flag quando esegui il template.

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

I log dell'avvio di template flessibili mostrano una gravità errata

Quando l'avvio di un template flessibile personalizzato non riesce, nei file di log viene visualizzato il seguente messaggio con gravità ERROR:

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

La causa principale dell'errore di avvio viene solitamente visualizzata nei log prima di questo messaggio con gravità INFO. Sebbene questo livello di log possa essere errato, è previsto, perché l'utilità di avvio dei 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 di Launcher, configura il template in modo che generi i log in formato JSON anziché in testo normale. Questa configurazione consente al programma di avvio dei modelli di estrarre la gravità corretta del messaggio di 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 appender JSON personalizzata. Per saperne di più, consulta la configurazione di esempio di Logback e il codice di esempio dell'appender JSON su GitHub.

Questo problema interessa solo i log generati dall'esecutore di template flessibili quando viene avviata la pipeline. Quando l'avvio va a buon fine e la pipeline è in esecuzione, i log prodotti dai worker Dataflow hanno la gravità corretta.

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