Batcharbeitslasten überwachen und Fehler beheben

In diesem Dokument werden die Tools und Dateien beschrieben, mit denen Sie Serverless for Apache Spark Batcharbeitslasten beobachten und Fehler beheben können.

Fehlerbehebung bei Arbeitslasten über die Google Cloud Console

Wenn ein Batchjob fehlschlägt oder eine schlechte Leistung aufweist, sollten Sie als ersten Schritt die Seite Batchdetails über die Seite Batches in der Google Cloud Console öffnen.

Tab „Zusammenfassung“: Ihre zentrale Anlaufstelle für die Fehlerbehebung

Auf dem Tab Zusammenfassung , der standardmäßig ausgewählt ist, wenn die Seite Batchdetails geöffnet wird, werden wichtige Messwerte und gefilterte Logs angezeigt, mit denen Sie schnell eine erste Bewertung des Batchzustands vornehmen können. Nach dieser ersten Bewertung können Sie eine detailliertere Analyse mit spezialisierteren Tools durchführen, die auf der Seite Batchdetails verfügbar sind, z. B. die Spark-UI, der Log-Explorer und Gemini Cloud Assist.

Wichtige Batchmesswerte

Der Tab Zusammenfassung auf der Seite Batchdetails enthält Diagramme mit wichtigen Messwerten für Batcharbeitslasten. Die Messwertdiagramme werden nach Abschluss des Vorgangs gefüllt und bieten eine visuelle Darstellung potenzieller Probleme wie Ressourcen konflikte, Datenverzerrungen oder Arbeitsspeicherdruck.

Dashboard mit Batchmesswerten

Tabelle mit Messwerten

In der folgenden Tabelle sind die Messwerte für Spark-Arbeitslasten aufgeführt, die in der Google Cloud Console auf der Seite Batchdetails angezeigt werden. Außerdem wird beschrieben, wie Messwerte Einblicke in den Status und die Leistung von Arbeitslasten geben können.

Messwert	Was wird angezeigt?
Messwerte auf Executor-Ebene
Verhältnis von JVM-GC-Zeit zu Laufzeit	Dieser Messwert zeigt das Verhältnis der JVM-GC-Zeit (Garbage Collection) zur Laufzeit pro Executor. Hohe Verhältnisse können auf Speicherlecks in Aufgaben hinweisen, die auf bestimmten Executors ausgeführt werden, oder auf ineffiziente Datenstrukturen, die zu einer hohen Objektfluktuation führen können.
Auf Laufwerk übergebene Byte	Dieser Messwert zeigt die Gesamtzahl der auf Laufwerk übertragenen Byte über verschiedene Executors hinweg. Wenn ein Executor eine hohe Anzahl an auf Laufwerk übertragenen Byte aufweist, kann dies auf eine Datenverzerrung hindeuten. Wenn der Messwert im Laufe der Zeit steigt, kann dies darauf hindeuten, dass es Phasen mit Arbeitsspeicherdruck oder Speicherlecks gibt.
Gelesene und geschriebene Byte	Dieser Messwert zeigt die geschriebenen im Vergleich zu den gelesenen Byte pro Executor. Große Abweichungen bei den gelesenen oder geschriebenen Byte können auf Szenarien hindeuten, in denen replizierte Joins zu einer Datenverstärkung auf bestimmten Executors führen.
Gelesene und geschriebene Einträge	Dieser Messwert zeigt die gelesenen und geschriebenen Einträge pro Executor. Eine hohe Anzahl gelesener Einträge bei einer niedrigen Anzahl geschriebener Einträge kann auf einen Engpass in der Verarbeitungslogik auf bestimmten Executors hindeuten, was dazu führt, dass Einträge während des Wartens gelesen werden. Executors, die bei Lese- und Schreibvorgängen konstant hinterherhinken, können auf Ressourcenkonflikte auf diesen Knoten oder auf ineffizienten Executor-spezifischen Code hindeuten.
Verhältnis von Shuffle-Schreibzeit zu Laufzeit	Der Messwert zeigt die Zeit, die der Executor in der Shuffle-Laufzeit verbracht hat, im Vergleich zur Gesamtlaufzeit. Wenn dieser Wert für einige Executors hoch ist, kann dies auf eine Datenverzerrung oder eine ineffiziente Datenserialisierung hindeuten. Sie können Phasen mit langen Shuffle-Schreibzeiten in der Spark-UI identifizieren. Suchen Sie nach Ausreißeraufgaben in diesen Phasen, die mehr als die durchschnittliche Zeit für den Abschluss benötigen. Prüfen Sie, ob die Executors mit hohen Shuffle-Schreibzeiten auch eine hohe Laufwerks-E/A-Aktivität aufweisen. Eine effizientere Serialisierung und zusätzliche Partitionierungsschritte können helfen. Sehr große Schreibvorgänge im Vergleich zu Lesevorgängen können auf eine unbeabsichtigte Datenduplizierung aufgrund ineffizienter Joins oder falscher Transformationen hindeuten.
Messwerte auf Anwendungsebene
Phasenfortschritt	Dieser Messwert zeigt die Anzahl der Phasen in den Status „Fehlgeschlagen“, „Warten“ und „Wird ausgeführt“. Eine große Anzahl fehlgeschlagener oder wartender Phasen kann auf eine Datenverzerrung hindeuten. Prüfen Sie die Datenpartitionen und beheben Sie den Grund für den Phasenausfall auf dem Tab Phasen in der Spark-UI.
Batch-Spark-Executors	Dieser Messwert zeigt die Anzahl der Executors, die möglicherweise erforderlich sind, im Vergleich zur Anzahl der ausgeführten Executors. Eine große Differenz zwischen erforderlichen und ausgeführten Executors kann auf Probleme mit dem Autoscaling hindeuten.
Messwerte auf VM-Ebene
Verwendeter Arbeitsspeicher	Dieser Messwert zeigt den Prozentsatz des verwendeten VM-Arbeitsspeichers. Wenn der Prozentsatz für den Master hoch ist, kann dies darauf hindeuten, dass der Treiber unter Arbeitsspeicherdruck steht. Bei anderen VM-Knoten kann ein hoher Prozentsatz darauf hindeuten, dass die Executors nicht mehr genügend Arbeitsspeicher haben, was zu einer hohen Anzahl an auf Laufwerk übertragenen Byte und einer langsameren Laufzeit der Arbeitslast führen kann. Analysieren Sie die Executors mit der Spark-UI, um nach einer hohen GC-Zeit und einer hohen Anzahl an Aufgabenfehlern zu suchen. Beheben Sie außerdem Fehler im Spark-Code für das Caching großer Datasets und die unnötige Übertragung von Variablen.

Jobprotokolle

Die Seite Batchdetails enthält den Abschnitt Jobprotokolle , in dem Warnungen und Fehler aus den Jobprotokollen (Batcharbeitslast) gefiltert werden. Mit dieser Funktion können Sie kritische Probleme schnell identifizieren, ohne umfangreiche Logdateien manuell analysieren zu müssen. Sie können im Drop-down-Menü eine Schweregrad für das Log auswählen (z. B. Error) und einen Filter hinzufügen, um die Ergebnisse einzugrenzen. Wenn Sie eine detailliertere Analyse durchführen möchten, klicken Sie auf das Symbol Im Log-Explorer ansehen , um die ausgewählten Batchprotokolle im Log-Explorer zu öffnen.

Batch-Logs in Cloud Logging ansehen — Batchprotokolle in Cloud Logging ansehen

Beispiel: Der Log-Explorer wird geöffnet, nachdem Sie in der Google Cloud Console auf der Seite Batchdetails im Auswahlfeld „Schweregrad“ die Option Errors ausgewählt haben.

Batch-Log-Explorer

Spark-UI

Die Spark-UI erfasst Details zur Apache Spark-Ausführung aus Serverless for Apache Spark Batcharbeitslasten. Für die Spark-UI-Funktion, die standardmäßig aktiviert ist, fallen keine Gebühren an.

Von der Spark-UI-Funktion erfasste Daten werden 90 Tage lang aufbewahrt. Mit dieser Weboberfläche können Sie Spark-Arbeitslasten beobachten und Fehler beheben, ohne einen Persistent History Servererstellen zu müssen.

Erforderliche Berechtigungen und Rollen für Identity and Access Management

Die folgenden Berechtigungen sind erforderlich, um die Spark-UI-Funktion mit Batch Arbeitslasten zu verwenden.

Berechtigung zur Datenerfassung: dataproc.batches.sparkApplicationWrite. Diese Berechtigung muss dem Dienstkonto gewährt werden, das Batcharbeitslasten ausführt. Diese Berechtigung ist in der Dataproc Worker Rolle enthalten, die automatisch dem Compute Engine-Standarddienstkonto gewährt wird, das standardmäßig von Serverless for Apache Spark verwendet wird (siehe Serverless for Apache Spark-Dienstkonto). Wenn Sie jedoch ein benutzerdefiniertes Dienstkonto für Ihre Batcharbeitslast angeben, müssen Sie diesem Dienstkonto die dataproc.batches.sparkApplicationWrite Berechtigung hinzufügen (in der Regel, indem Sie dem Dienstkonto die Dataproc-Rolle Worker gewähren).
Berechtigung für den Zugriff auf die Spark-UI: dataproc.batches.sparkApplicationRead. Diese Berechtigung muss einem Nutzer gewährt werden, damit er in der Google Cloud Console auf die Spark-UI zugreifen kann. Diese Berechtigung ist in den Dataproc Viewer, Dataproc Editor und Dataproc Administrator Rollen enthalten. Wenn Sie die Spark-UI in der Google Cloud Console öffnen möchten, müssen Sie eine dieser Rollen haben oder eine benutzerdefinierte Rolle, die diese Berechtigung enthält.

Spark-UI öffnen

Die Seite „Spark-UI“ ist in der Google Cloud Console für Batcharbeitslasten verfügbar.

Rufen Sie die Seite Serverless for Apache Spark-interaktive Sitzungen auf.

Zu Dataproc-Batches
Klicken Sie auf eine Batch-ID , um die Seite Batchdetails zu öffnen.
Klicken Sie im Menü oben auf Spark-UI ansehen.

Die Schaltfläche Spark-UI ansehen ist in den folgenden Fällen deaktiviert:

Wenn eine erforderliche Berechtigung nicht gewährt wurde
Wenn Sie auf der Seite Batchdetails das Häkchen aus dem Kästchen Spark-UI aktivieren entfernen
Wenn Sie beim Senden einer Batcharbeitslast die spark.dataproc.appContext.enabled Property auf false setzen

Serverless for Apache Spark-Logs

Die Protokollierung ist in Serverless for Apache Spark standardmäßig aktiviert und Arbeitslastprotokolle bleiben nach Abschluss einer Arbeitslast erhalten. Serverless for Apache Spark erfasst Arbeitslastprotokolle in Cloud Logging. Sie können im Log-Explorer unter der Cloud Dataproc Batch Ressource auf Serverless for Apache Spark-Logs zugreifen.

Serverless for Apache Spark-Logs abfragen

Der Log-Explorer in der Google Cloud Console bietet einen Abfragebereich , mit dem Sie eine Abfrage erstellen können, um Batcharbeitslastprotokolle zu untersuchen. So erstellen Sie eine Abfrage, um Batcharbeitslast protokolle zu untersuchen:

Zum Log-Explorer
Ihr aktuelles Projekt ist ausgewählt. Sie können auf Bereich verfeinern Projekt klicken, um ein anderes Projekt auszuwählen.
Definieren Sie eine Abfrage für Batchprotokolle.
- Verwenden Sie Filtermenüs um nach einer Batcharbeitslast zu filtern.
  1. Wählen Sie unter Alle Ressourcen die Ressource Cloud Dataproc Batch aus.
    1. Wählen Sie im Bereich Ressource auswählen den STANDORT des Batches und dann die BATCH-ID aus. Diese Batchparameter sind in der Console auf der Dataproc-Seite Batches aufgeführt. Google Cloud
    2. Klicken Sie auf Übernehmen.
    3. Geben Sie unter Lognamen auswählen im Feld Lognamen suchen dataproc.googleapis.com ein, um die abzufragenden Logtypen zu beschränken. Wählen Sie einen oder mehrere der aufgeführten Logdateinamen aus.
- Verwenden Sie den Abfrageeditor, um nach VM-spezifischen Logs zu filtern.
  1. Geben Sie den Ressourcentyp und den VM-Ressourcennamen wie im folgenden Beispiel an:
```
resource.type="cloud_dataproc_batch"
labels."dataproc.googleapis.com/resource_name"="gdpic-srvls-batch-BATCH_UUID-VM_SUFFIX"
```
    Hinweise:
    - BATCH_UUID: Die Batch-UUID ist in derConsole auf der Seite „Batchdetails“ aufgeführt, die geöffnet wird, wenn Sie auf der Seite Batches auf die Batch-ID klicken. Google Cloud
    In den Batchprotokollen ist die Batch-UUID auch im VM-Ressourcennamen aufgeführt. Hier ein Beispiel aus einem Batch-Treiberprotokoll:
Klicken Sie auf Abfrage ausführen.

Serverless for Apache Spark-Logtypen und Beispielabfragen

In der folgenden Liste werden verschiedene Serverless for Apache Spark-Logtypen beschrieben und für jeden Logtyp werden Beispielabfragen für den Log-Explorer bereitgestellt.

dataproc.googleapis.com/output: Diese Logdatei enthält die Ausgabe der Batcharbeitslast. Serverless for Apache Spark streamt die Batchausgabe in den Namespace output, und legt den Dateinamen auf JOB_ID.driver.log fest.

Beispielabfrage für den Log-Explorer für Ausgabeprotokolle:
```
resource.type="cloud_dataproc_batch"
resource.labels.location="REGION"
resource.labels.batch_id="BATCH_ID"
logName="projects/PROJECT_ID/logs/dataproc.googleapis.com%2Foutput"
```
dataproc.googleapis.com/spark: Der spark Namespace aggregiert Spark Logs für Daemons und Executors, die auf Dataproc Cluster-Master- und Worker-VMs ausgeführt werden. Jeder Logeintrag enthält ein master, worker oder executor Label für die Komponente, um die Logquelle zu identifizieren:
- executor: Logs von Executors mit nutzerdefiniertem Code. In der Regel sind dies verteilte Logs.
- master: Logs vom Spark-Master des eigenständigen Ressourcenmanagers, die den Dataproc-Logs für Compute Engine YARN ResourceManager ähneln.
- worker: Logs vom Spark-Worker des eigenständigen Ressourcenmanagers, die den Dataproc-Logs für Compute Engine YARN NodeManager ähneln.
Beispielabfrage für den Log-Explorer für alle Logs im spark Namespace:
```
resource.type="cloud_dataproc_batch"
resource.labels.location="REGION"
resource.labels.batch_id="BATCH_ID"
logName="projects/PROJECT_ID/logs/dataproc.googleapis.com%2Fspark"
```
Beispielabfrage für den Log-Explorer für Logs der eigenständigen Spark-Komponente in dem spark Namespace:
```
resource.type="cloud_dataproc_batch"
resource.labels.location="REGION"
resource.labels.batch_id="BATCH_ID"
logName="projects/PROJECT_ID/logs/dataproc.googleapis.com%2Fspark"
jsonPayload.component="COMPONENT"
```

dataproc.googleapis.com/startup: Der Namespace startup enthält die Startprotokolle für den Batch (Cluster). Alle Logs von Initialisierungsskripts sind enthalten. Komponenten werden durch Labels identifiziert, z. B.:

startup-script[855]: ... activate-component-spark[3050]: ... enable spark-worker

Beispielabfrage für den Log-Explorer für Startprotokolle auf einer bestimmten VM:

resource.type="cloud_dataproc_batch"
resource.labels.location="REGION"
resource.labels.batch_id="BATCH_ID"
logName="projects/PROJECT_ID/logs/dataproc.googleapis.com%2Fstartup"
labels."dataproc.googleapis.com/resource_name"="gdpic-srvls-batch-BATCH_UUID-VM_SUFFIX"

dataproc.googleapis.com/agent: Der agent Namespace aggregiert Dataproc-Agent-Logs. Jeder Logeintrag enthält ein Label für den Dateinamen , das die Logquelle identifiziert.

Beispielabfrage für den Log-Explorer für Agent-Logs, die von einer bestimmten Worker-VM generiert wurden:
```
resource.type="cloud_dataproc_batch"
resource.labels.location="REGION"
resource.labels.batch_id="BATCH_ID"
logName="projects/PROJECT_ID/logs/dataproc.googleapis.com%2Fagent"
labels."dataproc.googleapis.com/resource_name"="gdpic-srvls-batch-BATCHUUID-wWORKER#"
```

dataproc.googleapis.com/autoscaler: Der autoscaler Namespace aggregiert Serverless for Apache Spark-Autoscaler-Logs.

Beispielabfrage für den Log-Explorer für Agent-Logs, die von einer bestimmten Worker-VM generiert wurden:

resource.type="cloud_dataproc_batch"
resource.labels.location="REGION"
resource.labels.batch_id="BATCH_ID"
logName="projects/PROJECT_ID/logs/dataproc.googleapis.com%2Fautoscaler"
labels."dataproc.googleapis.com/resource_name"="gdpic-srvls-batch-BATCHUUID-wWORKER#"

Weitere Informationen finden Sie unter Dataproc-Logs.

Informationen zu Serverless for Apache Spark-Audit-Logs finden Sie unter Dataproc-Audit-Logging.

Arbeitslastmesswerte

Serverless for Apache Spark bietet Batch- und Spark-Messwerte, die Sie in der Google Cloud Console im Metrics Explorer oder auf der Seite Batchdetails ansehen können.

Batchmesswerte

Die Messwerte für die Dataproc-Ressource batch geben Einblicke in Batchressourcen, wie die Anzahl der Batch-Executors. Batchmesswerte haben das Präfix dataproc.googleapis.com/batch.

Beispiel für Batch-Messwerte im Metrics Explorer

Spark-Messwerte

Standardmäßig aktiviert Serverless for Apache Spark die Erfassung von verfügbaren Spark-Metriken, es sei denn, Sie verwenden Eigenschaften zur Erfassung von Spark-Metriken , um die Erfassung eines oder mehrerer Spark-Metriken zu deaktivieren oder zu überschreiben.

Verfügbare Spark-Messwerte umfassen Spark-Treiber- und Executor-Messwerte sowie Systemmesswerte. Verfügbare Spark-Messwerte haben das Präfix custom.googleapis.com/.

Beispiel für den Spark-Messwert im Metrics Explorer

Messwertbenachrichtigungen einrichten

Sie können Dataproc-Messwertbenachrichtigungen erstellen , um über Probleme mit Arbeitslasten informiert zu werden.

Diagramme erstellen

Sie können Diagramme erstellen, die Arbeitslastmesswerte visualisieren, indem Sie in der Google Cloud Console den Metrics Explorer verwenden. Sie können beispielsweise ein Diagramm erstellen, um disk:bytes_used anzuzeigen, und dann nach batch_id filtern.

Cloud Monitoring

Monitoring verwendet Arbeitslastmetadaten und -messwerte, um Einblicke in den Zustand und die Leistung von Serverless for Apache Spark-Arbeitslasten zu geben. Zu den Arbeitslastmesswerten gehören Spark-Messwerte, Batchmesswerte und Vorgangsmesswerte.

Sie können Cloud Monitoring in der Google Cloud Console verwenden, um Messwerte zu untersuchen, Diagramme hinzuzufügen, Dashboards zu erstellen und Benachrichtigungen zu erstellen.

Dashboards erstellen

Sie können ein Dashboard erstellen, um Arbeitslasten anhand von Messwerten aus mehreren Projekten und verschiedenen Google Cloud Produkten zu beobachten. Weitere Informationen finden Sie unter Benutzerdefinierte Dashboards erstellen und verwalten.

Persistent History Server

Serverless for Apache Spark erstellt die Compute-Ressourcen, die zum Ausführen einer Arbeitslast erforderlich sind, führt die Arbeitslast auf diesen Ressourcen aus und löscht die Ressourcen dann, wenn die Arbeitslast beendet ist. Arbeitslastmesswerte und -ereignisse bleiben nach Abschluss einer Arbeitslast nicht erhalten. Sie können jedoch einen Persistent History Server (PHS) verwenden, um den Anwendungsverlauf der Arbeitslast (Ereignis protokolle) in Cloud Storage aufzubewahren.

So verwenden Sie einen PHS mit einer Batcharbeitslast:

Erstellen Sie einen Dataproc Persistent History Server (PHS).

Hinweis: Die Seite Spark-UI in der Google Cloud Konsole erfasst und zeigt Details zur Ausführung von Spark-Arbeitslasten an, mit denen Sie Ihre Arbeitslasten beobachten und Fehler beheben können, ohne einen PHS Cluster erstellen zu müssen.
Geben Sie beim Senden einer Arbeitslast Ihren PHS an.
Verwenden Sie das Component Gateway um eine Verbindung zum PHS herzustellen und Anwendungsdetails, Planungsphasen, Details auf Aufgabenebene sowie Informationen zur Umgebung und zu Executors anzusehen.

Automatische Abstimmung

Automatische Abstimmung für Serverless for Apache Spark aktivieren: Sie können die automatische Abstimmung für Serverless for Apache Spark aktivieren, wenn Sie jede wiederkehrende Spark-Batcharbeitslast über die Google Cloud Console, die gcloud CLI oder die Dataproc API senden.

Console

Führen Sie die folgenden Schritte aus, um die automatische Abstimmung für jede wiederkehrende Spark-Batcharbeitslast zu aktivieren:

Rufen Sie in der Google Cloud Console die Dataproc-Seite Batches auf.

Zu Dataproc-Batches
Klicken Sie auf Erstellen, um eine Batcharbeitslast zu erstellen.
Geben Sie im Abschnitt Container den Namen der Kohorte ein, der den Batch als Teil einer Reihe wiederkehrender Arbeitslasten identifiziert. Die von Gemini unterstützte Analyse wird auf die zweite und alle nachfolgenden Arbeitslasten angewendet, die mit diesem Kohortennamen gesendet werden. Geben Sie beispielsweise TPCH-Query1 als Kohortennamen für eine geplante Arbeitslast an, die täglich eine TPC-H-Abfrage ausführt.
Füllen Sie die anderen Abschnitte der Seite Batch erstellen nach Bedarf aus und klicken Sie dann auf Senden. Weitere Informationen finden Sie unter Batcharbeitslast senden.

gcloud

Führen Sie den folgenden gcloud CLI gcloud dataproc batches submit Befehl lokal in einem Terminalfenster oder in Cloud Shell aus, um die automatische Abstimmung für jede wiederkehrende Spark-Batcharbeitslast zu aktivieren:

gcloud dataproc batches submit COMMAND \
    --region=REGION \
    --cohort=COHORT \
    other arguments ...

Ersetzen Sie Folgendes:

COMMAND: Der Typ der Spark-Arbeitslast, z. B. Spark, PySpark, Spark-Sql, oder Spark-R.
REGION: die Region , in der Ihre Arbeitslast ausgeführt wird.
COHORT: Der Kohortenname, der identifiziert den Batch als Teil einer Reihe wiederkehrender Arbeitslasten. Die von Gemini unterstützte Analyse wird auf die zweite und alle nachfolgenden Arbeitslasten angewendet, die mit diesem Kohortennamen gesendet werden. Geben Sie beispielsweise TPCH Query 1 als Kohortennamen für eine geplante Arbeitslast an, die täglich eine TPC-H-Abfrage ausführt.

API

Fügen Sie in einer batches.create Anfrage den RuntimeConfig.cohort Namen ein, um die automatische Abstimmung für jede wiederkehrende Spark Batcharbeitslast zu aktivieren. Die automatische Abstimmung wird auf die zweite und alle nachfolgenden Arbeitslasten angewendet, die mit diesem Kohortennamen gesendet werden. Geben Sie beispielsweise TPCH-Query1 als Kohortennamen für eine geplante Arbeitslast an, die täglich eine TPC-H-Abfrage ausführt.

Beispiel:

...
runtimeConfig:
  cohort: TPCH-Query1
...