Hinweise zu gängigen Fehlern

Auf dieser Seite werden einige gängige Fehler beschrieben, die beim Ausführen eines Dataflow-Jobs auftreten können. Außerdem finden Sie verschiedene Vorschläge zum Umgang mit diesen Fehlern.

Fehler aufgrund fehlender Ressourcen:

Meldungen zu Jobs:

Fehler beim Senden von Jobs:

Worker-Logs:

Eingabe- und Ausgabefehler:

Fehler beim Starten von Workern:

Protokolle:

Empfehlungen

Fehler aufgrund fehlender Ressourcen

Fehler bei einem aufgebrauchten Ressourcenpool beheben

Wenn Sie eine Google Cloud-Ressource erstellen, wird möglicherweise ein Fehler für einen aufgebrauchten Ressourcenpool angezeigt. Dieser Fehler weist auf eine vorübergehende Überlastung einer bestimmten Ressource in einer bestimmten Zone hin. Das Nachrichtenformat ist:

ERROR: ZONE_RESOURCE_POOL_EXHAUSTED

Um das Problem zu beheben, können Sie entweder eine Weile warten oder dieselbe Ressource in einer anderen Zone erstellen. Als Best Practice empfehlen wir, dass Sie Ihre Ressourcen auf mehrere Zonen und Regionen verteilen, um Ausfälle abzufangen.

Meldungen zu Jobs

The job failed because a work item failed 4 times.

Wenn ein einzelner Vorgang dazu führt, dass der Worker-Code viermal fehlschlägt, weil er eine Ausnahme auslöst oder abstürzt, schlägt der Job in Dataflow mit der Meldung a work item failed 4 times fehl. Sie können diesen Fehlerschwellenwert nicht konfigurieren. Weitere Informationen finden Sie unter Pipelinefehler- und Ausnahmebehandlung.

Suchen Sie in den Cloud Monitoring-Logs des Jobs nach den vier einzelnen Fehlern. Suchen Sie in den Worker-Logs, in denen Ausnahmen oder Fehler aufgeführt sind, nach Logeinträgen der Stufe Fehler oder Schwerwiegend. Sie sollten mindestens vier dieser Ausnahmen oder Fehler finden.

Codierungsfehler, IOExceptions oder unerwartetes Verhalten im Nutzercode

Die Apache Beam SDKs und die Dataflow-Worker sind von gängigen Komponenten von Drittanbietern abhängig. Diese importieren zusätzliche Abhängigkeiten. Versionskollisionen können im Dienst zu unerwarteten Verhaltensweisen führen. Wenn Sie eines dieser Pakete in Ihrem Code verwenden, beachten Sie, dass einige Bibliotheken nicht aufwärtskompatibel sind. Möglicherweise müssen Sie die aufgelisteten Versionen verwenden, die bei der Ausführung aktuell sind. Unter SDK- und Worker-Abhängigkeiten finden Sie eine Liste der Abhängigkeiten und ihrer erforderlichen Versionen.

Jobs, die früher ausgeführt werden konnten, erzeugen jetzt den Fehler Staged package...is inaccessible

  • Achten Sie darauf, dass der für das Staging verwendete Cloud Storage-Bucket keine TTL-Einstellungen enthält, die zum Löschen bereitgestellter Pakete führen.
  • Prüfen Sie, ob das Controller-Dienstkonto Ihres Dataflow-Projekts berechtigt ist, auf den für das Staging verwendeten Cloud Storage-Bucket zuzugreifen. Lücken in der Berechtigung können durch einen der folgenden Gründe bedingt sein:

    • Der für das Staging verwendete Cloud Storage-Bucket ist in einem anderen Projekt vorhanden.
    • Der für das Staging verwendete Cloud-Storage-Bucket wurde von detallierten Zugriffsberechtigungen zu einem einheitlichen Zugriff auf Bucket-Ebene migriert. Aufgrund der Inkonsistenzen zwischen IAM- und ACL-Richtlinien werden bei der Migration des Staging-Buckets auf einheitlichen Bucket-Level-Zugriff ACLs für Cloud-Storage-Ressourcen deaktiviert, was die Berechtigungen des Controller-Dienstkontos Ihres Dataflow-Projekts für den Staging-Bucket einschließt.

Weitere Informationen finden Sie unter Auf Cloud Storage-Buckets in Google Cloud-Projekten zugreifen.

Zeitüberschreitung bei flexiblen Vorlagen

Ihr flexibler Vorlagenjob gibt möglicherweise die folgende Fehlermeldung zurück:

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

Das kann folgende Gründe haben:

  1. Das Basis-Docker-Image wurde überschrieben.
  2. Das Dienstkonto, mit dem ${service_account_email} gefüllt wird, hat nicht alle erforderlichen Berechtigungen.
  3. Das Programm, das die Grafik erstellt, braucht zu lange.
  4. (Nur Python) Es gibt ein Problem mit der requirements.txt-Datei.
  5. Ein vorübergehender Fehler ist aufgetreten.

Im Folgenden sind einige zusätzliche Schritte zur Fehlerbehebung aufgeführt, die über das Prüfen von Joblogs und das Wiederholen bei vorübergehenden Fehlern hinausgehen.

Docker-Einstiegspunkt prüfen

Dieser Schritt ist für diejenigen vorgesehen, die 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

Sie sollten Folgendes sehen:

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.

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:

  • Prüfen Sie in den Joblogs, ob die Ausführung eines Vorgangs sehr lange dauert. Ein Beispiel wäre eine Anfrage für eine externe Ressource.
  • Achten Sie darauf, dass das Beenden des Programms nicht von Threads blockiert wird. Einige Clients können eigene Threads erstellen. Wenn diese Clients nicht heruntergefahren werden, wartet das Programm dauerhaft darauf, dass diese Threads verbunden werden.

Beachten Sie, dass diese Einschränkungen nicht für Pipelines gelten, die direkt (ohne Verwendung einer Vorlage) gestartet werden. Wenn die Pipeline also direkt funktioniert, aber als Vorlage fehlgeschlagen ist, könnte dies die Ursache sein.

(Nur Python) Apache Beam aus der Anforderungsdatei entfernen

Wenn Ihr Dockerfile eine requirements.txt mit apache-beam[gcp] enthält, sollten Sie sie aus der Datei entfernen und separat installieren. Beispiel:

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

Das Festlegen von Beam in der Anforderungsdatei führt bekanntermaßen zu langen Startzeiten und häufig zu einer Zeitüberschreitung.

Flex Template-Job in Python gerät in Warteschlange und überschreitet Zeitlimit

Wenn Sie einen Dataflow-Job mit Flex Template und Python ausführen, wird der Job möglicherweise für einen bestimmten Zeitraum in die Warteschlange gestellt und dann nicht ausgeführt. Eine Timeout in polling-Fehlermeldung wird angezeigt.

Der Fehler ist auf die Datei requirements.txt zurückzuführen, die zum Installieren der erforderlichen Abhängigkeiten verwendet wird. Wenn Sie einen Dataflow-Job starten, werden zuerst alle Abhängigkeiten bereitgestellt, damit die Dateien für die Worker-VMs zugänglich sind. Der Prozess umfasst das Herunterladen und Neukompilieren jeder direkten und indirekten Abhängigkeit in der Datei requirements.txt. Die Verarbeitung einiger Abhängigkeiten kann einige Minuten dauern, vor allem PyArrow. Dies ist eine indirekte Abhängigkeit, die von Apache Beam und den meisten Google Cloud-Clientbibliotheken verwendet wird.

Um das Problem zu umgehen, führen Sie die folgenden Schritte aus:

  1. Laden Sie die vorkompilierten Abhängigkeiten im Dockerfile in das Dataflow-Staging-Verzeichnis herunter.

  2. Setzen Sie die Umgebungsvariable PIP_NO_DEPS auf True.

    Die Einstellung verhindert, dass pip alle Abhängigkeiten noch einmal herunterlädt und neu kompiliert. Dadurch wird der Zeitüberschreitungsfehler verhindert.

Im folgenden Codebeispiel wird gezeigt, wie die Abhängigkeiten vorab heruntergeladen werden.

# Copyright 2020 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#    http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

FROM gcr.io/dataflow-templates-base/python3-template-launcher-base

ENV FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE="/template/requirements.txt"
ENV FLEX_TEMPLATE_PYTHON_PY_FILE="/template/streaming_beam.py"

COPY . /template

# We could get rid of installing libffi-dev and git, or we could leave them.
RUN apt-get update \
    && apt-get install -y libffi-dev git \
    && rm -rf /var/lib/apt/lists/* \
    # Upgrade pip and install the requirements.
    && pip install --no-cache-dir --upgrade pip \
    && pip install --no-cache-dir -r $FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE \
    # Download the requirements to speed up launching the Dataflow job.
    && pip download --no-cache-dir --dest /tmp/dataflow-requirements-cache -r $FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE

# Since we already downloaded all the dependencies, there's no need to rebuild everything.
ENV PIP_NO_DEPS=True

Fehler beim Senden von Jobs

413 Request Entity Too Large/The size of serialized JSON representation of the pipeline exceeds the allowable limit

Wenn beim Senden eines Jobs ein Fehler bezüglich der JSON-Nutzlast auftritt, bedeutet dies, dass die JSON-Darstellung der Pipeline die maximale Anfragegröße von 20 MB überschreitet. Diese Fehler können als eine der folgenden Meldungen im Console- bzw. Terminalfenster dargestellt werden:

  • 413 Request Entity Too Large
  • "Die Größe der serialisierten JSON-Darstellung der Pipeline überschreitet die zulässige Grenze"
  • "Es konnte kein Workflowjob erstellt werden: ungültige JSON-Nutzlast erhalten"
  • "Es konnte kein Workflowjob erstellt werden: Anfragenutzlast überschreitet die zulässige Grenze"

Die Größe Ihres Jobs ist mit der JSON-Darstellung der Pipeline verbunden. Eine größere Pipeline führt zu einer größeren Anfrage. Dataflow hat derzeit eine Begrenzung von 20 MB für Anfragen.

Führen Sie die Pipeline zum Schätzen der Größe der JSON-Anfrage mit der folgenden Option aus:

Java

--dataflowJobFile=< path to output file >

Python

--dataflow_job_file=< path to output file >

Mit diesem Befehl wird eine JSON-Darstellung des Jobs in eine Datei geschrieben. Die Größe der serialisierten Datei kann gut anhand der Größe der Anfrage geschätzt werden. Aufgrund von zusätzlichen Informationen in der Anfrage ist die tatsächliche Datei geringfügig größer.

Bestimmte Bedingungen in der Pipeline können bewirken, dass die JSON-Darstellung die Grenze überschreitet. Zu den häufigsten Bedingungen zählen:

  • Eine Create-Transformation, die eine große Menge an im Speicher befindlichen Daten enthält
  • Eine große DoFn-Instanz, die für die Übertragung an Remote-Worker serialisiert ist
  • Ein DoFn als anonyme innere Klasseninstanz, die (möglicherweise unbeabsichtigt) große Datenmengen zur Serialisierung abruft

Damit diese Bedingungen vermieden werden, sollten Sie Ihre Pipeline neu strukturieren.

The job graph is too large. Please try again with a smaller job graph, or split your job into two or more smaller jobs.

Die Grafikgröße Ihres Jobs darf 10 MB nicht überschreiten. Bestimmte Bedingungen in der Pipeline können dazu führen, dass die Jobgrafik das Limit überschreitet. Zu den häufigsten Bedingungen zählen:

  • Eine Create-Transformation, die eine große Menge an im Speicher befindlichen Daten enthält
  • Eine große DoFn-Instanz, die für die Übertragung an Remote-Worker serialisiert ist
  • Ein DoFn als anonyme innere Klasseninstanz, die (möglicherweise unbeabsichtigt) große Datenmengen zur Serialisierung abruft

Damit diese Bedingungen vermieden werden, sollten Sie Ihre Pipeline neu strukturieren.

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

Java

Dieser Fehler kann auftreten, wenn Sie Daten aus einer sehr großen Anzahl von Dateien über TextIO, AvroIO oder eine andere dateibasierte Quelle auslesen. Das jeweilige Limit hängt von den Details der Quelle ab (ein eingebettetes Schema in AvroIO.Read erlaubt z. B. weniger Dateien), liegt allerdings bei einer Größenordnung von Zehntausenden Dateien in einer Pipeline.

Dieser Fehler kann auch auftreten, wenn Sie eine benutzerdefinierte Datenquelle für Ihre Pipeline erstellt haben und die Methode splitIntoBundles Ihrer Quelle eine Liste von Objekten des Typs BoundedSource geliefert hat, die in serialisierter Form mehr als 20 MB beansprucht.

Das zulässige Limit für die Gesamtgröße der BoundedSource-Objekte, die vom splitIntoBundles()-Vorgang Ihrer benutzerdefinierten Quelle erzeugt wurden, ist 20 MB. Diese Einschränkung können Sie umgehen. Ändern Sie die benutzerdefinierte abgeleitete BoundedSource-Klasse so, dass die Gesamtgröße der generierten BoundedSource-Objekte unter dem Limit von 20 MB liegt. Ihre Quelle könnte beispielsweise anfänglich weniger Aufteilungen erzeugen und auf den dynamischen Work-Ausgleich zurückgreifen, um weitere Eingaben nach Bedarf aufzuteilen.

"SDK-Pipelineoptionen oder Staging-Dateiliste überschreiten die Größenbeschränkung. Achten Sie darauf, dass ihre Länge jeweils unter 256.000 Byte und insgesamt unter 512.000 Byte liegt."

Die Pipeline konnte nicht gestartet werden, da die Metadatenlimits von Google Compute Engine überschritten wurden. Diese Limits können nicht geändert werden. Dataflow verwendet Compute Engine-Metadaten für Pipelineoptionen. Das Limit ist in den Beschränkungen für benutzerdefinierte Metadaten in Compute Engine dokumentiert.

Zu viele JAR-Dateien für das Staging können dazu führen, dass die JSON-Darstellung das Limit überschreitet.

Wie finde ich die vollständige Pipelineoption und ihre Länge? Führen Sie die Pipeline zum Schätzen der Größe der JSON-Anfrage mit der folgenden Option aus:

Java

--dataflowJobFile=< path to output file >

Python

--dataflow_job_file=< path to output file >

Die Größe der oben aufgeführten Ausgabedatei muss kleiner als 256.000 Byte sein. Die 512.000 Byte in der Fehlermeldung beziehen sich auf die Gesamtgröße der obigen Ausgabedatei und der benutzerdefinierten Metadatenoptionen für die Compute Engine-VM-Instanz. Eine grobe Schätzung der benutzerdefinierten Metadatenoption für eine VM-Instanz kann anhand der Ausführung von Dataflow-Jobs im Projekt ermittelt werden. Wählen Sie einen beliebigen Dataflow-Job aus, führen Sie eine VM-Instanz aus und rufen Sie dann die Detailseite der Compute Engine VM-Instanz auf, um den Abschnitt mit den benutzerdefinierten Metadaten zu prüfen. Die Gesamtlänge der benutzerdefinierten Metadaten und der obigen Datei sollte weniger als 512.000 Byte betragen. Eine genaue Schätzung für den fehlgeschlagenen Job ist nicht möglich, da die VMs für diesen Job nicht hochgefahren wurden.

Wenn Ihre JAR-Liste die Grenze von 256.000 Byte erreicht, prüfen Sie sie und reduzieren Sie alle unnötigen JAR-Dateien. Wenn sie danach immer noch zu groß ist, führen Sie den Dataflow-Job mit einer Uber-JAR-Datei aus.

Der Abschnitt zu Cloud Functions-Funktionen in der Dokumentation enthält ein Beispiel zum Erstellen und Verwenden von Uber-JAR-Dateien.

Startup of the worker pool in zone $ZONE failed to bring up any of the desired $N 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.

Dieser Fehler hat zwei mögliche Ursachen:

  • Möglicherweise haben Sie eines der Compute Engine-Kontingente überschritten, auf das sich die Dataflow-Worker-Erstellung stützt.
  • Ihre Organisation verfügt über Einschränkungen, die einen bestimmten Aspekt der VM-Instanzerstellung verbieten, z. B. das verwendete Konto oder die ausgewählte Zone.

So beheben Sie das Problem:

Prüfen Sie das VM-Instanzlog

  1. Rufen Sie Cloud Logging Viewer auf.
  2. Wählen Sie in der Drop-down-Liste Geprüfte Ressource die Option VM-Instanz aus.
  3. Wählen Sie in der Drop-down-Liste Alle Logs die Option compute.googleapis.com/activity_log aus.
  4. Prüfen Sie das Log nach Einträgen im Zusammenhang mit dem Fehler bei der VM-Instanzerstellung.

Verwendung von Compute Engine-Kontingenten prüfen

  1. Führen Sie in der Befehlszeile Ihres lokalen Computers oder in Cloud Shell den folgenden Befehl aus, um die Compute Engine-Ressourcennutzung im Vergleich zu Dataflow-Kontingenten für die ausgewählte Zone anzeigen zu lassen:

    gcloud compute regions describe [REGION]

  2. Prüfen Sie die Ergebnisse für die folgenden Ressourcen, um festzustellen, ob sie das Kontingent überschreiten:

    • CPUS
    • DISKS_TOTAL_GB
    • IN_USE_ADDRESSES
    • INSTANCE_GROUPS
    • INSTANCE_GROUP_MANAGERS
    • INSTANCES
  3. Fordern Sie bei Bedarf eine Kontingentänderung an.

Einschränkungen der Organisationsrichtlinien prüfen

  1. Zur Seite "Organisationsrichtlinien"
  2. Prüfen Sie die Einschränkungen für alle, die das Erstellen von VM-Instanzen entweder für das von Ihnen verwendete Konto (standardmäßig das Dataflow-Dienstkonto) oder für die ausgewählte Zone einschränken könnten.

Worker-Logs

„Die Verarbeitung ist in Schritt <Schritt-ID> mindestens <Zeitraum> lang ohne Ausgabe oder Abschluss im Status „Fertig“ im <Stacktrace> hängen geblieben / der Vorgang dauert an“

Wenn Dataflow mehr Zeit für die Ausführung einer DoFn benötigt als in <time_interval> (Zeitraum) angegeben, ohne ein Ergebnis zu liefern, wird diese Meldung angezeigt.

Dieser Fehler hat zwei mögliche Ursachen:

  • Ihr DoFn-Code ist einfach nur langsam oder wartet auf den Abschluss eines langsamen externen Vorgangs.
  • Ihr DoFn-Code ist möglicherweise hängen geblieben, blockiert oder ungewöhnlich lange mit der Verarbeitung beschäftigt.

Erweitern Sie den Logeintrag Cloud Monitoring, um festzustellen, in welchem Fall dies der Fall ist, um einen Stacktrace anzuzeigen. Suchen Sie nach Nachrichten, die darauf hinweisen, dass der DoFn-Code nicht funktioniert oder anderweitige Probleme damit aufgetreten sind. Wenn keine vorhanden sind, liegt das Problem möglicherweise an der Ausführungsgeschwindigkeit des DoFn-Codes. Sie können die Leistung des Codes mit Cloud Profiler oder einem anderen Tool untersuchen.

Sie können die Ursache Ihres hängen gebliebenen Codes weiter untersuchen, wenn Ihre Pipeline auf der Java-VM erstellt wurde (entweder mit Java oder Scala). Führen Sie dazu folgende Schritte aus, um einen vollständigen Thread-Dump der gesamten JVM (nicht nur des hängen gebliebenen Threads) zu erstellen:

  1. Notieren Sie sich den Worker-Namen aus dem Logeintrag.
  2. Suchen Sie im Compute Engine-Bereich der Cloud Console nach der Compute Engine-Instanz mit dem notierten Worker-Namen.
  3. Stellen Sie eine SSH-Verbindung zu der Instanz mit diesem Namen her.
  4. Führen Sie diesen Befehl aus:

    curl http://localhost:8081/threadz
    

Ausnahmen "Shuffle-Schlüssel zu groß"

Wenn Ausnahmen auftreten, die darauf hinweisen, dass der Shuffle-Schlüssel zu groß ist, bedeutet dies, dass der an einen bestimmten (Co-)GroupByKey ausgegebene serielle Schlüssel nach Anwendung des entsprechenden Coders zu groß ist. Dataflow hat ein Limit für serialisierte Shuffle-Schlüssel. Sie können die Größe der Schlüssel reduzieren oder platzsparendere Codierer verwenden.

KeyCommitTooLargeException

In Streaming-Szenarien kann dies dadurch verursacht werden, dass eine sehr große Datenmenge gruppiert wird, ohne eine Combine-Transformation zu verwenden, oder dass eine große Datenmenge aus einem einzigen Eingabeelement erzeugt wird. Die folgenden Strategien können die Ausnahme verringern:

  • Achten Sie darauf, dass die Verarbeitung eines einzelnen Elements nicht zu Ausgängen oder Zustandsänderungen führen kann, die den Grenzwert überschreiten.
  • Wenn mehrere Elemente durch einen Schlüssel gruppiert wurden, können Sie den Schlüsselbereich erhöhen, um die pro Schlüssel gruppierten Elemente zu reduzieren.
  • Wenn Elemente für einen Schlüssel innerhalb kurzer Zeit mit hoher Frequenz ausgegeben werden, können für diesen Schlüssel möglicherweise mehrere GB an Ereignissen verursacht werden. Schreiben Sie die Pipeline um, um Schlüssel wie diesen zu erkennen und nur eine Ausgabe auszugeben, die angibt, dass der Schlüssel in diesem Fenster häufig vorhanden war.
  • Verwenden Sie sublineare Speicherplatz-Combine-Transformationen für komplexe und verknüpfte Vorgänge. Verwenden Sie keinen Combiner, wenn der Speicherplatz nicht reduziert wird. So ist z. B. Combiner für Strings, der nur Strings aneinanderhängt, schlechter, als wenn Sie keinen Combiner verwenden.

RPC-Zeitüberschreitungsausnahmen, DEADLINE_EXCEEDED-Ausnahmen oder Server Unresponsive-Fehler

Wenn bei der Ausführung Ihres Jobs RPC-Zeitüberschreitungen, DEADLINE_EXCEEDED-Ausnahmen oder Fehler vom Typ Server Unresponsive auftreten, deutet dies meist auf eines der beiden folgenden Probleme hin:

  • Im VPC-Netzwerk, das für den Job genutzt wird, fehlt möglicherweise eine Firewallregel. Die Firewallregel muss den gesamten TCP-Traffic zwischen VMs in dem VPC-Netzwerk ermöglichen, das Sie in den Pipelineoptionen angegeben haben. Weitere Einzelheiten finden Sie unter Netzwerk und Subnetzwerk angeben.

  • Ihr Job ist an das Zufallsprinzip gebunden. Hier können Sie sich für eine der folgenden Vorgehensweisen oder eine Kombination daraus entscheiden:

    Java

    • Wenn der Job nicht das dienstbasierte Shuffle verwendet, gehen Sie zur Verwendung des dienstbasierten Dataflow Shuffle über, indem Sie --experiments=shuffle_mode=service festlegen. Weitere Informationen und die Verfügbarkeit finden Sie unter Dataflow Shuffle.
    • Fügen Sie weitere Worker hinzu. Legen Sie einen höheren Wert für --numWorkers fest, wenn Sie die Pipeline ausführen.
    • Erhöhen Sie die Größe des angehängten Laufwerks für Worker. Legen Sie einen höheren Wert für --diskSizeGb fest, wenn Sie die Pipeline ausführen.
    • Nutzen Sie einen SSD-gestützten nichtflüchtigen Speicher. Legen Sie --workerDiskType="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd" fest, wenn Sie die Pipeline ausführen.

    Python

    • Wenn der Job nicht das dienstbasierte Shuffle verwendet, gehen Sie zur Verwendung des dienstbasierten Dataflow Shuffle über, indem Sie --experiments=shuffle_mode=service festlegen. Weitere Informationen und die Verfügbarkeit finden Sie unter Dataflow Shuffle.
    • Fügen Sie weitere Worker hinzu. Legen Sie einen höheren Wert für --num_workers fest, wenn Sie die Pipeline ausführen.
    • Erhöhen Sie die Größe des angehängten Laufwerks für Worker. Legen Sie einen höheren Wert für --disk_size_gb fest, wenn Sie die Pipeline ausführen.
    • Nutzen Sie einen SSD-gestützten nichtflüchtigen Speicher. Legen Sie --worker_disk_type="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd" fest, wenn Sie die Pipeline ausführen.

Ein Aufruf vom Java-Worker-Harness an eine Python-DoFn schlug mit dem Fehler <Fehlermeldung> fehl

Wenn eine in Python implementierte DoFn fehlschlägt und eine Ausnahme auslöst, wird eine entsprechende Fehlermeldung angezeigt.

Erweitern Sie den Cloud Monitoring-Fehlerlogeintrag und sehen Sie sich die Fehlermeldung und das Traceback an. Dort erfahren Sie, welcher Code fehlgeschlagen ist, sodass Sie ihn gegebenenfalls korrigieren können. Wenn Sie einen Programmfehler in Apache Beam oder Dataflow vermuten, melden Sie diesen Programmfehler.

Kein Speicherplatz mehr auf dem Gerät

Wenn für den Job kein Speicherplatz mehr verfügbar ist, werden in Worker-Logs möglicherweise Fehler vom Typ No space left on device angezeigt.

Wenn ein Job große Abhängigkeiten zur Laufzeit herunterlädt, große benutzerdefinierte Container verwendet oder viele temporäre Daten auf ein lokales Laufwerk schreibt, kann der freie Speicherplatz im nichtflüchtigen Speicher des Workers irgendwann erschöpft sein.

Wenn Sie Dataflow Shuffle verwenden, legt Dataflow eine niedrigere Standardlaufwerkgröße fest. Daher können Jobs, die von einem worker-basierten Shuffle verschoben werden, ebenfalls diesen Fehler verzeichnen.

Es ist auch möglich, dass das Worker-Bootlaufwerk voll ist, wenn es mehr als 50 Einträge pro Sekunde loggt.

Wenn Sie Laufwerkressourcen aufrufen möchten, die einem einzelnen Worker zugeordnet sind, suchen Sie nach VM-Instanzdetails für Worker-VMs, die mit Ihrem Job verknüpft sind. Ein Teil des Speicherplatzes wird vom Betriebssystem, von Binärdateien, Logs und Containern belegt.

Wenn Sie den Speicherplatz für nichtflüchtige Speicher oder das Bootlaufwerk erhöhen möchten, passen Sie die Pipelineoption für die Laufwerkgröße an.

Mit Cloud Monitoring können Sie die Speicherplatznutzung auf den Worker-VM-Instanzen verfolgen. Eine Anleitung zum Einrichten finden Sie unter Worker-VM-Messwerte vom Monitoring-Agent empfangen.

Sie können auch nach Problemen mit dem Speicherplatz des Startlaufwerks suchen. Rufen Sie dazu die Ausgabe des seriellen Ports auf den Worker-VM-Instanzen auf und suchen Sie nach Nachrichten wie "Fehler beim Öffnen des Systemjournals: Kein Speicherplatz auf dem Gerät". Wenn Sie eine große Anzahl von Worker-VM-Instanzen haben, können Sie ein Skript erstellen, um gcloud compute instances get-serial-port-output auf allen Instanzen gleichzeitig auszuführen und stattdessen die Ausgabe davon zu prüfen.

Weitere Informationen finden Sie unter Ressourcen für nichtflüchtigen Speicher.

EOFError: Marshal-Daten zu kurz

Dieser Fehler tritt manchmal auf, wenn nicht genügend Speicherplatz auf den Python-Pipeline-Workern vorhanden ist. Weitere Informationen finden Sie unter Kein Speicherplatz mehr auf dem Gerät.

Warnungen vom Typ Bad request in Shuffler-Logs

Während der Ausführung eines Dataflow-Jobs werden in Cloud Monitoring-Logs möglicherweise verschiedene Warnungen ähnlich den folgenden angezeigt:

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

Warnungen vom Typ "Fehlerhafte Anfrage" werden angezeigt, wenn die Informationen zum Worker-Status aufgrund von Verarbeitungsverzögerungen veraltet oder nicht synchron sind. Oft wird der Dataflow-Job trotz dieser Warnungen vom Typ "Fehlerhafte Anfrage" erfolgreich ausgeführt. Ignorieren Sie in diesem Fall einfach die Warnungen.

Ein heißer Schlüssel <Name-des-heißen-Schlüssels> wurde erkannt in...

Diese Fehler identifizieren einen "heißen" Schlüssel in Ihren Daten. Ein "heißer" Schlüssel ist ein Schlüssel mit so vielen Elementen, dass es sich negativ auf die Pipeline-Leistung auswirkt. Diese Schlüssel begrenzen die Möglichkeit von Dataflow, Elemente parallel zu verarbeiten, was die Ausführungszeit erhöht.

Verwenden Sie die Pipelineoption für den heißen Schlüssel, um das Vorhandensein eines "heißen" Schlüssels zu protokollieren.

Prüfen Sie, ob Ihre Daten gleichmäßig verteilt sind. Wenn ein Schlüssel unverhältnismäßig viele Werte enthält, sollten Sie die folgenden Vorgehensweisen berücksichtigen:

Python-Pipeline für benutzerdefinierte Container schlägt fehl mit SystemError: unknown opcode

Wenn unmittelbar nach der Jobübermittlung ein unerwarteter Python-Fehler SystemError: unknown opcode auftritt und der Stacktrace apache_beam/internal/pickler.py enthält, prüfen Sie, ob die lokal verwendete Python-Version mit der Version im Container-Image hinsichtlich Haupt- und Nebenversion übereinstimmt. Ein Unterschied in der Patchversion, z. B. 3.6.7 im Vergleich zu 3.6.8, verursacht keine Kompatibilitätsprobleme, aber ein Unterschied in der Nebenversion, z. B. 3.6.8 im Vergleich zu 3.8.2, kann zu Pipelinefehlern führen.

Eingabe- und Ausgabefehler

Die E/A-Messwertdiagramme verwenden kanonische Fehlercodes. Wenn diese Fehlercodes in Ihren Quellen und Senken bestehen bleiben, finden Sie in der folgenden Liste mögliche Ursachen und Maßnahmen, die Sie ergreifen können.

  • RESOURCE_EXHAUSTED. Das Projekt hat möglicherweise das Ressourcenkontingent für den von der Quelle oder Senke verwendeten Dienst aufgebraucht.

    Wenn der Fehler gelegentlich auftritt oder die Anfragen pro Sekunde eine hohe Anzahl von Anfragen darstellt, kann dies darauf hindeuten, dass Sie ein Kontingent für API-Ratenbegrenzungen erreicht haben und um das Kontingent zu erhöhen.

  • DEADLINE_EXCEEDED. Bei der Quelle oder Senke kam es während des Lesens oder Schreibens eines großen Datenbatches möglicherweise zu einer Zeitüberschreitung. Prüfen Sie das Latenzdiagramm und die Worker-Logs. Wenn der Fehler weiterhin auftritt, wenden Sie sich an den Support.

  • INVALID_ARGUMENT. Parameter, die für die Quelle oder Senke angegeben sind, sind möglicherweise fehlerhaft (z. B. ein Pub/Sub-Thema). Prüfen Sie die Konfiguration der Quelle oder Senke und die Worker-Logs.

  • FAILED_PRECONDITION. Prüfen Sie die Konfiguration der Quelle oder Senke und die Worker-Logs. Dies könnte auch auf einen Programmfehler hinweisen.

  • OUT_OF_RANGE. Prüfen Sie, ob die von der Quelle oder Senke verwendete Ressource vorhanden ist (z. B. ein Pub/Sub-Thema oder -Abo).

  • UNAUTHENTICATED. Prüfen Sie, ob das Dataflow-Dienstkonto für den jeweiligen Dienst über Identity and Access Management-Berechtigungen verfügt und dass für das Projekt relevante APIs aktiviert sind.

  • PERMISSION_DENIED. Prüfen Sie, ob das Dataflow-Dienstkonto für den jeweiligen Dienst über Identity and Access Management-Berechtigungen verfügt und dass für das Projekt relevante APIs aktiviert sind.

  • NOT_FOUND. Prüfen Sie, ob die von der Quelle oder Senke verwendeten Entitäten vorhanden sind (z. B. ein Pub/Sub-Thema oder -Abo).

  • ABORTED. Der Dienst verarbeitet die Quelle möglicherweise nicht ordnungsgemäß oder Senken versuchen, Daten zu lesen oder zu schreiben. Wenn der Fehler weiterhin auftritt, wenden Sie sich an den Support.

  • ALREADY_EXISTS. E/A versucht möglicherweise, eine bereits vorhandene Entität zu erstellen (z. B. ein Pub/Sub-Thema oder -Abo). Wenn der Fehler weiterhin auftritt, wenden Sie sich an den Support.

  • CANCELLED. Dies kann auftreten, wenn ein Dataflow-Worker heruntergefahren wird oder die Quell- oder Senkenlogik absichtlich Versuche zum Lesen oder Schreiben von Daten abbricht.

  • DATALOSS. Gibt an, dass ein nicht behebbarer Datenverlust oder eine Datenbeschädigung aufgetreten ist. Sie können ein neues Dataset für Ihre Quellen erstellen und den Dataflow-Job noch einmal ausführen.

    Unter Umständen sind für den zugrunde liegenden Google Cloud-Dienst Sicherungs- und Wiederherstellungsanweisungen verfügbar.

  • UNKNOWN. Der Dienst ist möglicherweise nicht verfügbar. Weitere Informationen finden Sie im Cloud-Status-Dashboard.

  • INTERNAL. Der Dienst ist möglicherweise nicht verfügbar. Weitere Informationen finden Sie im Cloud-Status-Dashboard.

  • UNAVAILABLE. Der Dienst ist möglicherweise nicht verfügbar. Weitere Informationen finden Sie im Cloud-Status-Dashboard.

  • UNIMPLEMENTED. Die Quelle oder Senke hat versucht, den Dienst auf ungültige Weise zu verwenden. Ihre Pipeline ist möglicherweise falsch konfiguriert. Wenn der Fehler weiterhin auftritt, wenden Sie sich an den Support.

Fehler beim Starten von Workern

Fehler in den Logtypen dataflow.googleapis.com/worker-startup, dataflow.googleapis.com/harness-startup und dataflow.googleapis.com/kubelet weisen auf Konfigurationsprobleme mit einem Job hin. Sie können auch auf Bedingungen hindeuten, durch die verhindert wird, dass der normale Logging-Pfad funktioniert.

„NoClassDefFound“-Fehler

Diese Fehler können auch das Format Unable to initialize main class [...] haben. Die Fehler NoClassDefFound geben an, dass die JAR-Dateien, die in den Dataflow-Dienst hochgeladen werden, nicht die erforderlichen Klassen zum Ausführen von Dataflow enthalten. Dies tritt meist dann auf, wenn die --filesToStage PipelineOption überschrieben wird und einige erforderliche JAR- oder Klassendateien ausgelassen werden.

Image-Pull-Anfrage ist mit einem Fehler fehlgeschlagen

Dieser Fehler gibt an, dass ein Worker nicht gestartet werden konnte, da er kein Docker-Container-Image abrufen konnte. Dies kann passieren, wenn die benutzerdefinierte SDK-Container-Image-URL falsch ist oder der Worker über keine Anmeldedaten oder Netzwerkzugriff auf das Remote-Image verfügt.

Wenn Sie ein benutzerdefiniertes Container-Image für Ihren Job verwenden, prüfen Sie, ob die Image-URL korrekt ist, ein gültiges Tag oder einen Digest enthält und ob die Dataflow-Worker auf das Image zugreifen können.

Prüfen Sie, ob öffentliche Images lokal abgerufen werden können. Führen Sie dazu docker pull $image auf einem nicht authentifizierten Computer aus.

Für private Images und private Worker müssen weitere Aspekte berücksichtigt werden.

  • Dataflow unterstützt nur private Container-Images, die auf Container Registry gehostet sind. Wenn Sie das Container-Image mit Container Registry hosten, hat das standardmäßige Google Cloud-Dienstkonto Zugriff auf Images im selben Projekt. Wenn Sie Images in einem anderen Projekt verwenden als dem, mit dem Ihr Google Cloud-Job ausgeführt wird, müssen Sie die Zugriffssteuerung für das Google Cloud-Standarddienstkonto konfigurieren.
  • Sorgen Sie bei Verwendung einer freigegebenen Virtual Private Cloud (VPC) dafür, dass die Worker auf den benutzerdefinierten Container-Repository-Host zugreifen können.
  • Stellen Sie mit ssh eine Verbindung zu einer ausgeführten Job-Worker-VM her und führen Sie docker pull $image aus, um zu prüfen, ob der Worker richtig konfiguriert ist.

Wenn Worker aufgrund eines Fehlers mehrmals hintereinander fehlschlagen und für einen Job keine Arbeit gestartet wurde, kann der Job mit einem Fehler wie Job appears to be stuck. ... fehlschlagen. Wenn Sie den Zugriff auf das Image entfernt haben, während der Job ausgeführt wird, entweder durch Entfernen des Images selbst oder durch Widerrufen der Anmeldedaten des Dataflow-Worker-Dienstkontos oder Internetzugriffs auf Images, protokolliert Dataflow nur Fehler und führt keine Aktionen aus, um den Job fehlschlagen zu lassen. Dataflow vermeidet außerdem lang andauernde Streaming-Pipelines, um einen Verlust des Pipelinestatus zu vermeiden.

Weitere mögliche Fehler können durch Kontingentprobleme oder Ausfälle des Repositorys verursacht werden. Wenn Probleme beim Überschreiten des Docker Hub-Kontingents zum Abrufen öffentlicher Images oder allgemeine Drittanbieter-Repository-Ausfälle auftreten, sollten Sie eventuell Container Registry als Image-Repository verwenden.

Fehler beim Synchronisieren des Pods ... „StartContainer“ konnte nicht ausgeführt werden

Dieser Fehler gibt an, dass ein Docker-Container des Workers nicht gestartet werden konnte. Dies geschieht normalerweise, wenn einer der Container beim Start ständig abstürzt.

Wenn der Container abstürzt, suchen Sie nach einer Fehlermeldung, die den Fehler in den Worker-Start-, Harness-Start- oder Docker-Logs beschreibt. Ein häufiger Grund für den Startabsturz von Python-Jobs sind pip-Installationsfehler (pip install failed with error...) aufgrund von Abhängigkeitsproblemen. Dazu können inkompatible angegebene Abhängigkeiten oder Netzwerkprobleme gehören, die bewirken, dass bestimmte Repositories nicht erreichbar sind. Das im Container installierte Apache Beam Python SDK muss mit dem SDK übereinstimmen, das zum Starten des Jobs verwendet wird.

Dieser Fehler kann auch auftreten, wenn das Container-Image während eines lang andauernden Jobs nicht abgerufen werden kann. Weitere Informationen finden Sie unter Image-Pull-Anfrage ist mit einem Fehler fehlgeschlagen.

„Die Java-Laufzeitumgebung hat einen schwerwiegenden Fehler erkannt“

Dies deutet darauf hin, dass die Pipeline Java Native Interface (JNI) verwendet, um Nicht-Java-Code auszuführen, und dass ein Fehler in diesem Code oder den JNI-Bindungen vorliegt.

Logs

Ich sehe keine Logs

Wenn Sie keine Logs für Ihre Jobs sehen, entfernen Sie alle Ausschlussfilter, die resource.type="dataflow_step" enthalten, aus allen Ihren Cloud Logging-Log Router-Senken.

Zum "Log Router"

Weitere Informationen zum Entfernen von Logausschlüssen finden Sie im Leitfaden Ausschlüsse entfernen.

Empfehlungen

Hohe Kontingentnutzung für Streaming Engine-Übertragungen

Bei Jobs, die Streaming Engine nutzen, gibt es ein regionales Limit für die Übertragung von Daten von und an Streaming Engine. Es ist wichtig, das Limit nicht zu überschreiten, da sonst Jobleistung beeinträchtigt werden kann. Wenn Sie die Menge der übertragenen Byte reduzieren, sinken außerdem die in Rechnung gestellten Kosten.

Informationen zum Aufrufen des Limits Ihres Projekts finden Sie in der Anleitung unter Kontingente und Limits. Sehen Sie sich diesen Link zum Metrics Explorer an, um die aktuelle Nutzung Ihrer Jobs aufzurufen. Wählen Sie gegebenenfalls das Projekt aus, in dem der Job ausgeführt wird. Ersetzen Sie REGION durch die Region, die Sie interessiert, und klicken Sie auf "Abfrage ausführen".

Vorschläge zur Reduzierung der Nutzung:

  • Reduzieren Sie die Datenmenge, die von GroupByKey- und Combine-Transformationen verarbeitet wird. Hierzu können Sie die Anzahl der übergebenen Elemente reduzieren oder unnötige Felder weglassen.
  • Codieren Sie Daten effizienter, um Speicherplatz zu sparen. In einigen Fällen kann sich dadurch die CPU-Auslastung des Workers erhöhen.

    • Bei benutzerdefinierten Datentypen kann der Standard-Coder ineffizient sein (SerializableCoder in Java, PickleCoder in Python). Versuchen Sie, einen effizienteren Standard-Coder für den benutzerdefinierten Typ oder eine PCollection mit einem Schema auszuwählen.

      Eine ausführlichere Erläuterung zu Codern und deren Angabe finden Sie im Kapitel zur Datencodierung in der Beam-Programmieranleitung. Weitere Informationen zu PCollections mit Schemas finden Sie im Kapitel zu Schemas.

    • Bei großen Elementen kann eine Komprimierung hilfreich sein.

  • Reduzieren Sie Lesevorgänge für großen Status. Beispiel: Eine Pipeline mit einem ausreichend großen BagState muss ihn bei jedem Abruf von Streaming Engine übertragen.

    • Reduzieren Sie die Größe des Status.
    • Versuchen Sie, die Häufigkeit der Statusabrufe zu reduzieren.
    • Der Status ist mit einem bestimmten Schlüssel und Fenster verknüpft. Die Verwendung eines nicht globalen Windowing kann zur Begrenzung der Statusgröße verwendet werden.

    Weitere Informationen zum Status finden Sie im Kapitel zu Status und Timern in der Beam-Programmieranleitung.

Autoscaling: „maxNumWorkers“ könnte erhöht werden

Dataflow hat festgestellt, dass ein Job die maximale Anzahl zulässiger Worker (maxNumWorkers oder max_num_workers) verwendet und dass er möglicherweise mehr Worker nutzt, wenn dieser Höchstwert erhöht wurde. Diese Empfehlung wird beispielsweise für einen Job ausgegeben, bei dem maxNumWorkers auf 50 gesetzt ist und 50 Worker mit einer durchschnittlichen CPU-Auslastung von über 80 % verwendet werden.

In der Regel erhöht eine Erhöhung von maxNumWorkers den Pipelinedurchsatz: Eine Batchpipeline könnte in kürzerer Zeit abgeschlossen werden und eine Streaming-Pipeline könnte größere Datenspitzen verarbeiten und mehr Elemente pro Sekunde verarbeiten. Dies kann jedoch zu höheren Kosten führen (siehe Preise für Worker-Ressourcen). Weitere Informationen zur Funktionsweise des Autoscaling-Algorithmus und zu seiner Konfiguration finden Sie im Autoscaling-Leitfaden.

Vorschläge:

  • Versuchen Sie, die Pipelineoption maxNumWorkers zu erhöhen oder zu entfernen. Ohne die Option verwendet Dataflow die im Autoscaling-Leitfaden aufgeführten Standardeinstellungen.
  • Sie brauchen nichts zu tun, wenn die Pipelineleistung ausreichend ist.
    • Prüfen Sie bei Batchpipelines, ob die Gesamtlaufzeit Ihren Anforderungen entspricht.
    • Prüfen Sie bei Streaming-Pipelines auf der Jobseite auf dem Tab "Jobmesswerte" das Diagramm zur Datenaktualität. Achten Sie darauf, dass er nicht kontinuierlich erhöht wird und dass die Werte innerhalb akzeptabler Grenzen liegen.

Hohes Fan-Out erkannt

Dataflow hat festgestellt, dass ein Job eine oder mehrere Transformationen mit einem "Hohes Fan-Out" umfasst. Dies tritt auf, wenn ein ParDo mit einem hohen Verhältnis von Ausgabe-zu-Eingabe-Elementen mit einem nachfolgenden ParDo zusammengeführt wird. In diesem Fall werden erstes und zweites ParDo sequenziell ausgeführt. Dadurch werden alle Ausgabeelemente einer bestimmten Eingabe demselben Worker aufgezwungen, wodurch die Parallelität reduziert und die Leistung verlangsamt wird.

Vorschläge:

  • Fügen Sie einen GroupByKey ein und heben Sie die Gruppierung nach dem ersten ParDo auf. Der Dataflow-Dienst führt keine ParDo-Vorgänge über eine Zusammenfassung hinweg aus.
  • Übergeben Sie die Zwischen-PCollection als Nebeneingabe an ein anderes ParDo. Nebeneingaben werden vom Dataflow-Dienst immer erfasst.
  • Fügen Sie einen Reshuffle-Schritt ein. Die Umverteilung verhindert eine Zusammenführung, erstellt Prüfpunkte für die Daten und konfiguriert die Windowing-Strategie so, dass keine Daten gelöscht werden. Dataflow unterstützt Reshuffle, obwohl es in der Apache Beam-Dokumentation als verworfen markiert ist. Beachten Sie, dass das Umwandeln von Daten die Kosten für die Ausführung der Pipeline erhöhen kann.