Fehlerbehebung bei Flex-Vorlagen

Auf dieser Seite finden Sie Tipps und Strategien zur Fehlerbehebung, die nützlich sein könnten, wenn Sie flexible Dataflow-Vorlagen verwenden. Standardmäßig beträgt das Zeitlimit für den Start einer flexiblen Vorlage 12 Minuten. Dieser Startprozess umfasst das Abrufen des Container-Images der Vorlage und das Ausführen des Codes zum Erstellen des Jobdiagramms. Wenn der Start nicht innerhalb dieser 12 Minuten abgeschlossen ist, schlägt der Job mit dem Fehler „Zeitüberschreitung beim Abrufen der Ergebnisdatei“ fehl. Anhand dieser Informationen können Sie ein Zeitlimit für die Abfrage ermitteln, den Grund für das Zeitlimit ermitteln und das Problem beheben.

Zeitüberschreitungsfehler bei der Abfrage

Ihr Job gibt möglicherweise eine der folgenden Fehlermeldungen zurück:

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

Dieser Fehler kann folgende Ursachen haben:

  1. Das Basis-Docker-Image wurde überschrieben.
  2. Das Dienstkonto, mit dem SERVICE_ACCOUNT gefüllt wird, hat nicht alle erforderlichen Berechtigungen.
  3. Externe IP-Adressen sind deaktiviert und VMs können keine Verbindung zu der Gruppe von externen IP-Adressen herstellen, die von Google APIs und Diensten verwendet werden.
  4. Die Launcher-VM kann gcr.io nicht auflösen oder darauf zugreifen.
  5. Großes Container-Image für flexible Vorlagen.
  6. Das Programm, das die Grafik erstellt, braucht zu lange.
  7. Die Ausführung des Codes in der Launcher-VM dauert zu lange.
  8. Zeitweise Netzwerk- oder Cloud Storage-Fehler.
  9. Pipelineoptionen werden überschrieben.
  10. Python-Nutzer: Die Installation oder das Staging von Abhängigkeiten dauert zu lange.
  11. Ein vorübergehender Fehler ist aufgetreten.

Prüfen Sie zur Behebung dieses Problems zuerst die Joblogs auf Fehler und versuchen Sie es noch einmal.

Folgen Sie der Anleitung im Abschnitt Probleme beim frühen Start um das Logging für den seriellen Port zu aktivieren. Dadurch erhalten Sie möglicherweise zusätzliche Informationen.

Wenn das Problem durch diese Schritte nicht behoben wird, führen Sie die folgenden Schritte zur Fehlerbehebung aus.

Optional: Vorlagen ausführen, um das Problem weiter zu diagnostizieren

So können Sie weiter ermitteln, welche der oben genannten Ursachen diesen Fehler verursachen:

  1. Führen Sie die von Google bereitgestellte WordCount Vorlage aus. Geben Sie Parameter an, die für Ihren Anwendungsfall spezifisch sind, z. B. das Subnetz aus einem freigegebene VPC-Projekt, die private IP-Adresse für Worker-VMs und das Dataflow-Worker-Dienstkonto, das Sie verwenden möchten. Weitere Informationen zum Angeben dieser Parameter finden Sie in der gcloud Referenz und der API Referenz.

    Wenn Sie diesen Job erfolgreich abschließen können, sind Netzwerk, IAM-Berechtigungen und privater Google-Zugriff wahrscheinlich richtig konfiguriert.

  2. Führen Sie die Kurzanleitung Pipeline mit dem Job Builder ausführen durch, um den Job als flexible Vorlage auszuführen. Wenn der Job vor dem Starten der Worker-VM fehlschlägt, greifen Sie auf die Launcher-VM zu und versuchen Sie, ein Docker-Image mit einem Befehl herunterzuladen, der dem folgenden ähnelt:

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

    Wenn dieser Befehl fehlschlägt, liegt möglicherweise ein Netzwerkproblem beim Herunterladen von Images vor. Wenden Sie sich in diesem Fall an Ihr internes Netzwerkteam.

  3. Führen Sie eine von Google bereitgestellte flexible Vorlage aus und prüfen Sie das Ergebnis. Wenn der Job der von Google bereitgestellten Vorlage erfolgreich abgeschlossen wird, liegt das Problem wahrscheinlich an Ihren spezifischen benutzerdefinierten Vorlagencode-Dateien. In diesem Fall müssen Sie die Fehlerbehebung für Ihren spezifischen Code fortsetzen, um das Problem zu beheben.

Docker-Einstiegspunkt prüfen

Führen Sie diesen Schritt aus, wenn Sie eine Vorlage aus einem benutzerdefinierten Docker-Image ausführen, anstatt eine der bereitgestellten Vorlagen zu verwenden.

Suchen Sie mit dem folgenden Befehl nach dem Containereinstiegspunkt:

docker inspect $TEMPLATE_IMAGE

Die folgende Ausgabe wird erwartet:

Java

/opt/google/dataflow/java_template_launcher

Python

/opt/google/dataflow/python_template_launcher

Wenn Sie eine andere Ausgabe erhalten, wird der Einstiegspunkt Ihres Docker-Containers überschrieben. Stellen Sie $TEMPLATE_IMAGE wieder auf die Standardeinstellung her.

Dienstkontoberechtigungen prüfen

Prüfen Sie, ob das in der Nachricht erwähnte Dienstkonto die folgenden Berechtigungen hat:

  • Es muss den Cloud Storage-Pfad lesen und schreiben können, mit dem ${file_path} in der Nachricht gefüllt wird.
  • Es muss das Docker-Image lesen können, mit dem ${image_url} in der Nachricht gefüllt wird.

Privaten Google-Zugriff konfigurieren

Wenn externe IP-Adressen deaktiviert sind, müssen Sie Compute Engine-VMs erlauben, eine Verbindung zu der Gruppe von externen IP-Adressen herzustellen, die von Google APIs und Diensten verwendet werden. Aktivieren Sie den privaten Google-Zugriff in dem Subnetz, das von der Netzwerkschnittstelle der VM verwendet wird.

Weitere Konfigurationsdetails finden Sie unter Privaten Google-Zugriff konfigurieren.

Wenn einer Compute Engine-VM eine externe IP-Adresse fehlt, die der Netzwerkschnittstelle zugewiesen ist, kann sie standardmäßig nur Pakete an andere interne IP-Adressen senden.

Zugriffsprobleme mit GCR.io

Launcher-VMs für flexible Vorlagen benötigen Zugriff auf gcr.io, um einen Logging-Agent Container (gcr.io/dataflow-templates-base/template-launcher-logger-distroless) abzurufen. Dieser Agent ist für das Streamen von Launcher-Logs an Cloud Logging verantwortlich. Wenn die Launcher-VM gcr.io nicht auflösen oder keine Verbindung dazu herstellen kann, reagiert der Startprozess möglicherweise nicht mehr, was zu einer Zeitüberschreitung bei der Abfrage führt.

Dieses Problem kann auch auftreten, wenn Ihr benutzerdefiniertes Vorlagen-Image in Artifact Registry gespeichert ist, da der Logging-Agent immer von gcr.io abgerufen wird.

So diagnostizieren und beheben Sie dieses Problem:

  1. Logging für den seriellen Port aktivieren: Folgen Sie der Anleitung im Abschnitt Probleme beim frühen Start. Wenn der cloud-init-Prozess hängen bleibt oder Fehler im Zusammenhang mit gcr-wait-online.service auftreten, liegt wahrscheinlich ein DNS- oder Netzwerkproblem vor.

  2. SSH-Verbindung zur Launcher-VM herstellen: Verwenden Sie den Befehl gcloud compute ssh, um eine Verbindung zur Launcher-VM herzustellen, während sie noch ausgeführt wird:

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

    Ersetzen Sie JOB_ID durch die ID Ihres Dataflow-Jobs.

  3. DNS-Auflösung prüfen: Führen Sie die folgenden Befehle in der Launcher- VM aus:

    curl -I https://gcr.io

    Wenn der Befehl mit dem "Could not resolve host" Fehler fehlschlägt, fehlt in Ihrer DNS-Konfiguration ein Eintrag für gcr.io.

  4. Auf hängende Startdienste prüfen: Untersuchen Sie das cloud-init Ausgabeprotokoll:

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

    Suchen Sie nach Nachrichten, die darauf hinweisen, dass der Prozess auf das Netzwerk oder auf den Zugriff auf gcr.io wartet.

Achten Sie außerdem darauf, dass die DNS-Einstellungen Ihrer VPC die Auflösung von gcr.io zulassen. In einigen privaten Netzwerkkonfigurationen müssen Sie möglicherweise einen bestimmten DNS AEintrag für gcr.iohinzufügen, der auf die IP-Bereiche der eingeschränkten Google APIs oder privaten Google APIs verweist.

Großes Container-Image

Wenn Ihr Container-Image für flexible Vorlagen groß ist, kann das Abrufen und Starten der Vorlage das standardmäßige Zeitlimit von 12 Minuten überschreiten, was zu einem Jobfehler führt.

So können Sie das Problem beheben :

  • Optimieren Sie Ihr Image, um seine Größe zu reduzieren und den Abrufvorgang zu beschleunigen.
  • Verwenden Sie das Flag --launcher-machine-type, um einen Maschinentyp mit mehr CPU-Kernen auszuwählen. Dadurch wird das Image schneller abgerufen und der Start beschleunigt.
  • Verwenden Sie das Flag --launcher-vm-timeout-secs, um eine längere Zeitüberschreitungsdauer für die Launcher-VM anzugeben, sodass das standardmäßige Zeitlimit von 12 Minuten überschritten werden kann.

Prüfen, ob das Launcher-Programm nicht beendet werden kann

Das Programm, das die Pipeline erstellt, muss abgeschlossen sein, bevor die Pipeline gestartet werden kann. Der Abfragefehler könnte darauf hinweisen, dass es zu lange gedauert hat.

Sie können die Ursache im Code beispielsweise so ermitteln:

  • Achten Sie darauf, dass das Beenden des Programms nicht von Threads blockiert wird. Einige Clients erstellen möglicherweise ihre eigenen Threads. Wenn diese Clients nicht heruntergefahren werden, wartet das Programm für immer, bis diese Threads verbunden werden.
  • Verwenden Sie im Code, der Ihre Pipeline definiert, nicht waitUntilFinish (für Java) oder wait_until_finish (für Python). Diese Funktionen verhindern, dass das Programm beendet wird, wodurch die Pipeline nicht mit der flexiblen Vorlage gestartet werden kann.

Pipelines, die direkt gestartet werden und keine Vorlage verwenden, haben diese Einschränkungen nicht. Wenn die Pipeline also direkt (nicht als Vorlage) funktionierte, könnte die Verwendung einer Vorlage die Ursache sein. Wenn Sie das Problem in der Vorlage finden und die Vorlage beheben, kann das Problem möglicherweise behoben werden.

Lange Ausführungszeit des Codes in der Launcher-VM

Wenn die Ausführung des Codes in Ihrem Hauptprogramm zu lange dauert, kann es zu einer Zeitüberschreitung bei der flexiblen Vorlage kommen, bevor die Pipeline gestartet wird. Dies kann passieren, wenn der Code während der Initialisierung komplexe Berechnungen durchführt oder synchrone Aufrufe an externe Ressourcen vornimmt.

Prüfen Sie zur Diagnose dieses Problems die Joblogs auf Vorgänge, deren Abschluss lange dauert. Beispiele sind Anfragen an externe Ressourcen, große Datensuchen oder eine umfangreiche Initialisierungslogik, die Sie in die Ausführungsphase der Pipeline verschieben können.

Zeitweise Netzwerk- oder Cloud Storage-Fehler

Zeitweise Fehler vom Typ „Zeitüberschreitung beim Abrufen der Ergebnisdatei“ oder „Ergebnisdatei konnte nicht gelesen werden“ können aufgrund einer hohen Netzwerklatenz oder vorübergehender Probleme mit der Cloud Storage API auftreten. Chronische Netzwerküberlastung in Ihrer VPC, insbesondere im Pfad für den privater Google-Zugriff, führt häufig zu Latenzen von 400 bis 500 ms.

Ein Fehler vom Typ „Zeitüberschreitung beim Abrufen der Ergebnisdatei“ ist in der Regel ein langsamer Fehler, während ein Fehler vom Typ „Ergebnisdatei konnte nicht gelesen werden“ ein schneller Fehler ist. Beide weisen jedoch oft auf dasselbe zugrunde liegende Verbindungsproblem hin.

So diagnostizieren Sie diese zeitweise auftretenden Fehler:

  1. Netzwerklatenz prüfen: Überwachen Sie die Netzwerklatenz in Ihrer VPC. Eine anhaltend hohe Latenz kann zu Zeitüberschreitungen führen, wenn die Launcher-VM versucht, die Job-Ergebnisdatei in Cloud Storage zu schreiben oder daraus zu lesen.

  2. Cloud Storage API-Messwerte überwachen:

    1. Rufen Sie in der Google Cloud Console das Dashboard APIs und Dienste auf.

      Zu „Aktivierte APIs und Dienste“

    2. Filtern Sie nach der Cloud Storage API und wählen Sie sie aus.

    3. Prüfen Sie die Diagramme für Traffic (gesendete und empfangene Byte) und Fehlerrate.

    4. Suchen Sie nach Spitzen bei 5xx-Fehlern (z. B. 503-Fehlern), die mit dem genauen Zeitpunkt der Jobfehler übereinstimmen.

Wenn Sie Spitzen bei Fehlern oder eine hohe Latenz feststellen, untersuchen Sie die Netzwerkleistung Ihrer VPC oder wenden Sie sich an denCloud-Kundensupport , um Hilfe bei potenziellen Dienstunterbrechungen zu erhalten.

Prüfen, ob erforderliche Pipelineoptionen unterdrückt werden

Bei Verwendung von Flex-Vorlagen haben Sie die Möglichkeit, einige Pipelineoptionen bei der Pipelineinitialisierung zu konfigurieren. Es können aber nicht alle Pipelineoptionen geändert werden. Weitere Informationen finden Sie im Abschnitt Jobdatei konnte nicht gelesen werden in diesem Dokument.

Python-Nutzer: Abhängigkeitsverwaltung

Wenn Sie einen Python-Job für flexible Vorlagen ausführen, der zusätzliche Abhängigkeiten in einer requirements.txt-Datei bereitstellt, kann der Job möglicherweise nicht gestartet werden. Dieser Fehler tritt auf, wenn das Herunterladen oder Installieren der in der Datei „requirements“ angegebenen Abhängigkeiten länger dauert als die für den Start der Flexible Vorlage zugewiesene Zeit.

Um die Leistung Ihres Jobs zu optimieren, verpacken Sie die Abhängigkeiten beim Erstellen der Vorlage vorab, damit sie beim Start der Vorlage nicht heruntergeladen oder installiert werden müssen. Weitere Informationen finden Sie im Abschnitt Paketabhängigkeiten für Python unter "Flexible Vorlagen konfigurieren."

Fehler beim Starten von Jobs

Der folgende Abschnitt enthält häufige Fehler beim Starten von Jobs sowie Schritte zur Behebung dieser Fehler.

Probleme beim frühen Start

Wenn der Start der Vorlage in einem frühen Stadium fehlschlägt, sind möglicherweise keine regulären Flex-Vorlagenlogs verfügbar. Zum Untersuchen von Startproblemen aktivieren Sie das Logging für den seriellen Port für die Vorlagen-Launcher-VM.

Legen Sie für die Option enableLauncherVmSerialPortLogging den Wert true fest, um das Logging für Java-Vorlagen zu aktivieren. Zum Aktivieren des Loggings für Python- und Go-Vorlagen legen Sie für die Option enable_launcher_vm_serial_port_logging den Wert true fest. In der Google Cloud Console wird der Parameter unter Optionale Parameter als Logging des seriellen Ports für die Launcher-VM aktivieren aufgeführt.

Sie können die Logs für die Ausgabe des seriellen Ports der Vorlagen-Launcher-VM in Cloud Logging ansehen. Verwenden Sie die Abfrage resource.type="gce_instance" "launcher-number", um die Logs für eine bestimmte Launcher-VM zu ermitteln. Dabei beginnt number mit dem aktuellen Datum im Format YYYMMDD.

Ihre Organisationsrichtlinie lässt das Logging der Ausgabe des seriellen Ports möglicherweise nicht zu.

Jobdatei konnte nicht gelesen werden

Wenn Sie versuchen, einen Job aus einer flexiblen Vorlage auszuführen, schlägt der Job möglicherweise mit dem folgenden Fehler fehl:

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

Dieser Fehler tritt auf, wenn die erforderlichen Pipelineinitialisierungsoptionen überschrieben werden. Bei Verwendung von Flex-Vorlagen haben Sie die Möglichkeit, einige Pipelineoptionen bei der Pipelineinitialisierung zu konfigurieren. Es können aber nicht alle Pipelineoptionen geändert werden. Wenn die von der Flex-Vorlage erforderlichen Befehlszeilenargumente überschrieben werden, kann es sein, dass der Job die vom Vorlagen-Launcher übergebenen Pipelineoptionen ignoriert, überschreibt oder verwirft. Der Job wird möglicherweise nicht gestartet, oder es wird ein Job gestartet, der die Flex-Vorlage nicht verwendet.

Ändern Sie zur Vermeidung dieses Problems während der Pipelineinitialisierung die folgenden Pipelineoptionen im Nutzercode oder in der metadata.json-Datei nicht:

Java

  • runner
  • project
  • jobName
  • templateLocation
  • region

Python

  • runner
  • project
  • job_name
  • template_location
  • region

Go

  • runner
  • project
  • job_name
  • template_location
  • region

Ergebnisdatei konnte nicht gelesen werden

Wenn Sie versuchen, einen Job aus einer flexiblen Vorlage auszuführen, schlägt der Job möglicherweise mit dem folgenden Fehler fehl:

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

Dieser Fehler tritt auf, wenn das Compute Engine-Standarddienst konto nicht alle Berechtigungen hat, die zum Ausführen einer flexiblen Vorlage erforderlich sind.

Eine Liste der erforderlichen Berechtigungen finden Sie unter Berechtigungen zum Ausführen einer flexiblen Vorlage.

Dieser Fehler kann auch durch zeitweise Netzwerklatenz oder Probleme mit der Cloud Storage API verursacht werden. Weitere Informationen finden Sie unter Zeitweise Netzwerk- oder Cloud Storage Fehler.

Berechtigung für Ressource verweigert

Wenn Sie versuchen, einen Job aus einer flexiblen Vorlage auszuführen, schlägt der Job möglicherweise mit dem folgenden Fehler fehl:

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

Dieser Fehler tritt auf, wenn das verwendete Dienstkonto nicht berechtigt ist, auf erforderliche Ressourcen zum Ausführen einer Flex-Vorlage zuzugreifen.

Prüfen Sie, ob das Dienstkonto die erforderlichen Berechtigungen hat, um dieses Problem zu vermeiden. Passen Sie die Dienstkontoberechtigungen nach Bedarf an.

Flag angegeben, aber nicht definiert

Wenn Sie versuchen, eine flexible Go-Vorlage mit der Pipelineoption worker_machine_type auszuführen, schlägt die Pipeline mit dem folgenden Fehler fehl:

flag provided but not defined: -machine_type

Dieser Fehler wird durch ein bekanntes Problem in den Apache Beam Go SDK-Versionen 2.47.0 und früher verursacht. Führen Sie zur Behebung dieses Problems ein Upgrade auf Apache Beam Go Version 2.48.0 oder höher durch.

JAR-Datei des Remote-Jobservers konnte nicht abgerufen werden

Wenn Sie versuchen, einen Job aus einer Flex-Vorlage auszuführen, ohne mit dem Internet verbunden zu sein, schlägt der Job möglicherweise mit der folgenden Fehlermeldung fehl:

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

Dieser Fehler tritt auf, weil die VM das Apache Beam-Java-Paket nicht aus dem Internet herunterladen kann. Dieses Paket ist erforderlich, wenn Sie einen mehrsprachigen Job mit einer flexiblen Vorlage ausführen.

Nehmen Sie eine der folgenden Änderungen vor, um dieses Problem zu beheben:

  • Internetverbindung herstellen Wenn eine Internetverbindung besteht, kann Ihr Job auf die erforderliche Datei zugreifen.

  • Fügen Sie das Apache Beam Java-Paket in Ihr lokales Verzeichnis ein, damit Ihr Job lokal darauf zugreifen kann. Erstellen Sie die Datei /root/.apache_beam/cache/jars/ im folgenden Verzeichnis: Beispiel: /root/.apache_beam/cache/jars/beam-sdks-java-io-expansion-service-SDK_VERSION.jar

Dateisystem konnte nicht über den angegebenen Pfad abgerufen werden

Wenn Sie versuchen, einen Job aus einer flexiblen Vorlage auszuführen, schlägt der Job möglicherweise mit dem folgenden Fehler fehl:

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

Dieser Fehler tritt auf, wenn für den Job ein Container-Image der Flex-Vorlage verwendet wird und das Container-Image keine Java-Installation enthält.

Fügen Sie Ihrem Dockerfile die folgende Zeile hinzu, um dieses Problem zu beheben:

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

Mit diesem Befehl wird Java in Ihrer Containerumgebung installiert.

Ressourcenmangel bei der Launcher-VM

Wenn Sie versuchen, einen Job aus einer flexiblen Vorlage auszuführen, schlägt der Job möglicherweise mit dem folgenden Fehler fehl:

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.

Der VM-Name launcher-ID steht für den Namen der Launcher-VM. Die Launcher-VM ist dafür verantwortlich, Jobressourcen wie den Vorlagencode und das Image zu erfassen, bevor das Jobdiagramm erstellt und an den Dataflow-Dienst gesendet wird, um die Arbeit zu starten.

Wenn Sie den Parameter launcherMachineType nicht angeben, wählt Dataflow einen Standardmaschinentyp für die Launcher-VM aus. Diese Auswahl ist unabhängig vom machineType des Workers. Fehler aufgrund von Ressourcenmangel können auftreten, wenn dieser Standardmaschinentyp in der Region oder Zone des Jobs nicht verfügbar ist.

Verwenden Sie eine der folgenden Strategien, um dieses Problem zu beheben:

Verzögerung beim Flex-Vorlagen-Launcher

Wenn Sie einen Job für flexible Vorlagen senden, wird die Jobanfrage in eine Spanner-Warteschlange gestellt. Der Vorlagen-Launcher ruft den Job aus der Spanner-Warteschlange ab und führt dann die Vorlage aus. Falls Spanner einen Nachrichtenrückstand hat, kann es zwischen dem Senden und dem Start des Jobs zu einer erheblichen Verzögerung kommen.

Um dieses Problem zu umgehen, starten Sie Ihre flexible Vorlage aus einer anderen Region.

Die Vorlagenparameter sind ungültig

Wenn Sie versuchen, mit der gcloud CLI einen Job auszuführen, der eine von Google bereitgestellte Vorlage, verwendet, tritt der folgende Fehler auf:

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

Dieser Fehler tritt auf, weil einige von Google bereitgestellten Vorlagen die Optionen defaultSdkHarnessLog und defaultWorkerLog nicht unterstützen.

Kopieren Sie als Behelfslösung die Vorlagenspezifikationsdatei in einen Cloud Storage-Bucket. Fügen Sie der Datei die folgenden zusätzlichen Parameter hinzu.

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

Nachdem Sie diese Änderung an der Vorlagendatei vorgenommen haben, führen Sie die Vorlage mit dem folgenden Befehl aus.

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

Ersetzen Sie die folgenden Werte:

  • BUCKET_NAME: der Name Ihres Cloud Storage-Buckets
  • FILENAME: durch den Name Ihrer Vorlagenspezifikationsdatei

Flexible Vorlage-Launcher-Logs zeigen den falschen Schweregrad an

Wenn die Ausführung einer benutzerdefinierten flexiblen Vorlage fehlschlägt, wird in den Logdateien die folgende Meldung mit dem Schweregrad ERROR angezeigt:

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

Die Ursache für den Startfehler wird in den Logs in der Regel vor dieser Meldung mit dem Schweregrad INFO angezeigt. Obwohl diese Logebene möglicherweise falsch ist, ist sie zu erwarten, da mit dem Launcher für flexible Vorlagen keine Schweregraddetails aus den von der Apache Beam-Anwendung generierten Lognachrichten extrahiert werden können.

Wenn Sie den korrekten Schweregrad für jede Nachricht im Launcher-Protokoll sehen möchten, konfigurieren Sie Ihre Vorlage so, dass Protokolle im JSON-Format statt im Klartext generiert werden. Mit dieser Konfiguration kann der Vorlagen-Launcher den korrekten Schweregrad der Logeinträge extrahieren. Verwenden Sie die folgende Nachrichtenstruktur:

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

In Java können Sie den Logback-Logger mit einer benutzerdefinierten JSON-Appender -Implementierung verwenden. Weitere Informationen finden Sie in der Logback-Beispielkonfiguration und im JSON-Appender-Beispielcode in GitHub.

Dieses Problem betrifft nur die Logs, die vom Launcher für flexible Vorlagen beim Starten der Pipeline generiert werden. Wenn der Start erfolgreich war und die Pipeline ausgeführt wird, haben die von Dataflow-Workern erstellten Logs den korrekten Schweregrad.

Bei von Google bereitgestellten Vorlagen wird beim Starten des Jobs der korrekte Schweregrad angezeigt, da diese von Google bereitgestellten Vorlagen diesen JSON-Logging-Ansatz verwenden.