Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Überwachung von AWS Glue-Spark-Aufträgen
**Topics**
+ [Spark-Metriken verfügbar in AWS Glue Studio](#console-jobs-details-metrics-spark)
+ [Überwachen von Aufgaben über die Apache-Spark-Webbenutzeroberfläche](monitor-spark-ui.md)
+ [Überwachung mit Einblicken in die AWS Glue Auftragsausführung](monitor-job-insights.md)
+ [Überwachung mit Amazon CloudWatch](monitor-cloudwatch.md)
+ [Auftragsüberwachung und Debugging](monitor-profile-glue-job-cloudwatch-metrics.md)
## Spark-Metriken verfügbar in AWS Glue Studio
Die Registerkarte **Metrics (Metriken)** zeigt Metriken, die erfasst werden, wenn ein Auftrag ausgeführt wird und das Profiling aktiviert ist. Die folgenden Diagramme werden in Spark-Aufträgen angezeigt:
+ ETL-Datenbewegung
+ Speicherprofil: Treiber und Executors
Wählen Sie **View additional metrics (Weitere Metriken anzeigen)**, um die folgenden Graphen anzuzeigen:
+ ETL-Datenbewegung
+ Speicherprofil: Treiber und Executors
+ Datenmischung über Executors hinweg
+ CPU-Auslastung: Treiber und Executors
+ Auftragsausführung: Aktive Executors, Abgeschlossen Phasen und maximal benötigte Executors
Die Daten für diese Diagramme werden in CloudWatch Metriken übertragen, wenn der Job für die Erfassung von Metriken konfiguriert ist. Weitere Informationen über das Aktivieren von Metriken und die Interpretation der Graphen finden Sie unter [Auftragsüberwachung und Debugging](monitor-profile-glue-job-cloudwatch-metrics.md).
**Example Der Graph für die ETL-Datenbewegung**
Der Graph für die ETL-Datenbewegung zeigt die folgenden Metriken:
+ Die Anzahl der von allen Executors von Amazon S3 gelesenen Bytes – [`glue.ALL.s3.filesystem.read_bytes`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.read_bytes)
+ Die Anzahl der von allen Executors in Amazon S3 geschriebenen Bytes – [`glue.ALL.s3.filesystem.write_bytes`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.write_bytes)
![\[Der Graph für die ETL-Datenbewegung auf der Registerkarte Metrics (Metriken) der AWS Glue-Konsole.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/job_detailed_etl.png)
**Example Der Graph für das Speicherprofil**
Der Graph für das Speicherprofil zeigt die folgenden Metriken:
+ Der vom JVM-Heap für diesen Treiber (Skalierung: 0-1) verwendete Speicheranteil – vom Treiber, einem durch *executorId* identifizierten Executor oder allen Executors –
+ [`glue.driver.jvm.heap.usage`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.jvm.heap.usage)
+ [`glue.executorId.jvm.heap.usage`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.executorId.jvm.heap.usage)
+ [`glue.ALL.jvm.heap.usage`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.usage)
![\[Der Graph für das Speicherprofil auf der Registerkarte Metrics (Metriken) der AWS Glue-Konsole.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/job_detailed_mem.png)
**Example Der Graph für die Datenmischung über Executors hinweg**
Der Graph für das Mischen der Daten über alle Executors hinweg zeigt die folgenden Metriken:
+ Die Zahl der von allen Executors gelesenen Bytes, um ihre Daten zu mischen - [`glue.driver.aggregate.shuffleLocalBytesRead`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.shuffleLocalBytesRead)
+ Die Zahl der von allen Executors geschriebenen Bytes, um ihre Daten zu mischen - [`glue.driver.aggregate.shuffleBytesWritten`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.shuffleBytesWritten)
![\[Der Graph für die Datenmischung über Executors hinweg auf der Registerkarte Metrics (Metriken) der AWS Glue-Konsole.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/job_detailed_data.png)
**Example Der Graph für die CPU-Auslastung**
Der Graph für die CPU-Auslastung zeigt die folgenden Metriken:
+ Der vom Treiber verwendete Anteil der CPU-Systemauslastung (Skalierung: 0-1) – vom Treiber, einem durch *executorId* identifizierten Executor oder allen Executors –
+ [`glue.driver.system.cpuSystemLoad`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.system.cpuSystemLoad)
+ [`glue.executorId.system.cpuSystemLoad`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.executorId.system.cpuSystemLoad)
+ [`glue.ALL.system.cpuSystemLoad`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.system.cpuSystemLoad)
![\[Der Graph für die CPU-Auslastung auf der Registerkarte Metrics (Metriken) der AWS Glue-Konsole.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/job_detailed_cpu.png)
**Example Der Graph für die Auftragsausführung**
Der Graph für die Auftragsausführung zeigt die folgenden Metriken:
+ Die Anzahl der aktiven Executors - [`glue.driver.ExecutorAllocationManager.executors.numberAllExecutors`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberAllExecutors)
+ Die Anzahl der abgeschlossenen Phasen - [`glue.aggregate.numCompletedStages`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.numCompletedStages)
+ Die Anzahl maximal benötigter Executors - [`glue.driver.ExecutorAllocationManager.executors.numberMaxNeededExecutors`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberMaxNeededExecutors)
![\[Der Graph für die Auftragsausführung auf der Registerkarte Metrics (Metriken) der AWS Glue-Konsole.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/job_detailed_exec.png)
# Überwachen von Aufgaben über die Apache-Spark-Webbenutzeroberfläche
Sie können die Apache-Spark-Webbenutzeroberfläche zum Überwachen und Debuggen von AWS Glue-ETL-Aufträgen verwenden, die auf dem AWS Glue-Aufgabensystem ausgeführt werden, und von Spark-Anwendungen, die auf AWS Glue-Entwicklungsendpunkten ausgeführt werden. Sie können in der Spark-Benutzeroberfläche folgende Punkte für die einzelnen Aufgaben überprüfen:
+ Ereignis-Zeitplan der einzelnen Spark-Phasen
+ Ausgerichtetes azyklisches Diagramm (Directed Acyclic Graph, DAG) der Aufgabe
+ Physische und logische Pläne für SparkSQL-Abfragen
+ Zugrunde liegende Spark-Umgebungsvariablen für die einzelnen Aufgaben
Weitere Informationen zur Verwendung der Spark-Web-UI finden Sie unter [Web-UI](https://spark.apache.org/docs/3.3.0/web-ui.html) in der Spark-Dokumentation. Anleitungen dazu, wie Sie die Ergebnisse der Spark-Benutzeroberfläche interpretieren können, um die Leistung Ihres Jobs zu verbessern, finden Sie unter [Bewährte Methoden zur Leistungsoptimierung AWS Glue für Apache Spark-Jobs](https://docs.aws.amazon.com/prescriptive-guidance/latest/tuning-aws-glue-for-apache-spark/introduction.html) in AWS Prescriptive Guidance.
Sie können die Spark-Benutzeroberfläche in der AWS Glue Konsole sehen. Dies ist verfügbar, wenn ein AWS Glue Job auf Versionen AWS Glue 3.0 oder höher ausgeführt wird, wobei die Logs im Standardformat (und nicht im Legacy-Format) generiert werden, was der Standard für neuere Jobs ist. Wenn Sie über Protokolldateien mit mehr als 0,5 GB verfügen, können Sie die Unterstützung für fortlaufende Protokolle für Auftragsausführungen in Versionen AWS Glue 4.0 oder höher aktivieren, um die Archivierung, Analyse und Problembehandlung von Protokollen zu vereinfachen.
Sie können die Spark-Benutzeroberfläche mithilfe der AWS Glue Konsole oder der AWS Command Line Interface (AWS CLI) aktivieren. Wenn Sie die Spark-Benutzeroberfläche aktivieren, können AWS Glue-ETL-Aufträge und Spark-Anwendungen in AWS Glue-Entwicklungsendpunkten Spark-Ereignisprotokolle an einem Speicherort sichern, den Sie in Amazon Simple Storage Service (Amazon S3) angeben. Die so in Amazon S3 gesicherten Ereignisprotokolle können in der Spark-Benutzeroberfläche in Echtzeit während der Auftragsausführung und nach Abschluss des Auftrags verwendet werden. Die Protokolle verbleiben zwar in Amazon S3, können aber über die Spark-Benutzeroberfläche in der AWS Glue Konsole angezeigt werden.
## Berechtigungen
Um die Spark-Benutzeroberfläche in der AWS Glue Konsole zu verwenden, können Sie alle einzelnen Dienste verwenden `UseGlueStudio` oder hinzufügen APIs. Alle APIs sind erforderlich, um die Spark-Benutzeroberfläche vollständig nutzen zu können. Benutzer können jedoch auf die Funktionen von SparkUI zugreifen, indem sie den Dienst APIs zu ihrer IAM-Berechtigung hinzufügen, um einen detaillierten Zugriff zu erhalten.
`RequestLogParsing` ist am wichtigsten, weil damit das Parsen von Protokollen möglich ist. Die restlichen Daten APIs dienen zum Lesen der jeweiligen analysierten Daten. `GetStages` bietet beispielsweise Zugriff auf die Daten zu allen Phasen eines Spark-Auftrags.
Die Liste der APIs zugewiesenen Spark-UI-Dienste finden `UseGlueStudio` Sie weiter unten in der Beispielrichtlinie. Die folgende Richtlinie gewährt nur Zugriff auf die Verwendung der Features der Spark-Benutzeroberfläche. Informationen zum Hinzufügen weiterer Berechtigungen wie Amazon S3 und IAM finden Sie unter [Erstellen benutzerdefinierter IAM-Richtlinien für](https://docs.aws.amazon.com/glue/latest/dg/getting-started-min-privs.html#getting-started-all-gs-privs.html). AWS Glue Studio
Die Liste der APIs zugewiesenen Spark-UI-Services finden Sie weiter unten in der Beispielrichtlinie. `UseGlueStudio` Wenn Sie eine Spark-Benutzeroberfläche-Service-API verwenden, verwenden Sie den folgenden Namespace: `glue:`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowGlueStudioSparkUI",
"Effect": "Allow",
"Action": [
"glue:RequestLogParsing",
"glue:GetLogParsingStatus",
"glue:GetEnvironment",
"glue:GetJobs",
"glue:GetJob",
"glue:GetStage",
"glue:GetStages",
"glue:GetStageFiles",
"glue:BatchGetStageFiles",
"glue:GetStageAttempt",
"glue:GetStageAttemptTaskList",
"glue:GetStageAttemptTaskSummary",
"glue:GetExecutors",
"glue:GetExecutorsThreads",
"glue:GetStorage",
"glue:GetStorageUnit",
"glue:GetQueries",
"glue:GetQuery"
],
"Resource": [
"*"
]
}
]
}
```
------
## Einschränkungen
+ Die Spark-Benutzeroberfläche in der AWS Glue Konsole ist für Jobausführungen, die vor dem 20. November 2023 stattfanden, nicht verfügbar, da sie im alten Protokollformat vorliegen.
+ Die Spark-Benutzeroberfläche in der AWS Glue Konsole unterstützt fortlaufende Logs für AWS Glue 4.0, wie sie beispielsweise standardmäßig bei Streaming-Jobs generiert werden. Die maximale Summe aller generierten Ereignisdateien für fortlaufende Protokolle beträgt 2 GB. Für AWS Glue Jobs ohne Unterstützung für Rolling-Logs beträgt die maximale Größe der Protokollereignisdatei, die für SparkUI unterstützt wird, 0,5 GB.
+ Die Serverless-Spark-Benutzeroberfläche ist nicht für Spark-Ereignisprotokolle verfügbar, die in einem Amazon-S3-Bucket gespeichert sind und auf die nur Ihre VPC zugreifen kann.
## Beispiel: Web-UI von Apache Spark
In diesem Beispiel wird veranschaulicht, wie Sie die Spark-Benutzeroberfläche verwenden, um Ihre Auftragsleistung nachzuvollziehen. Die Screenshots zeigen die Spark-Weboberfläche, wie sie von einem selbstverwalteten Spark History-Server bereitgestellt wird. Die Spark-Benutzeroberfläche in der AWS Glue Konsole bietet ähnliche Ansichten. Weitere Informationen zur Verwendung der Spark-Web-UI finden Sie unter [Web-UI](https://spark.apache.org/docs/3.3.0/web-ui.html) in der Spark-Dokumentation.
Im Folgenden finden Sie ein Beispiel für eine Spark-Anwendung, die aus zwei Datenquellen liest, eine Join-Transformation ausführt und diese im Parquet-Format zu Amazon S3 schreibt.
```
import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job
from pyspark.sql.functions import count, when, expr, col, sum, isnull
from pyspark.sql.functions import countDistinct
from awsglue.dynamicframe import DynamicFrame
args = getResolvedOptions(sys.argv, ['JOB_NAME'])
sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args['JOB_NAME'])
df_persons = spark.read.json("s3://awsglue-datasets/examples/us-legislators/all/persons.json")
df_memberships = spark.read.json("s3://awsglue-datasets/examples/us-legislators/all/memberships.json")
df_joined = df_persons.join(df_memberships, df_persons.id == df_memberships.person_id, 'fullouter')
df_joined.write.parquet("s3://aws-glue-demo-sparkui/output/")
job.commit()
```
Die folgende DAG-Visualisierung zeigt die verschiedenen Phasen in dieser Spark-Aufgabe.
![\[Screenshot der Spark-Benutzeroberfläche mit 2 abgeschlossenen Phasen für Aufgabe 0.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/spark-ui1.png)
Der folgende Ereigniszeitplan für eine Aufgabe zeigt Start, Ausführung und Beendigung verschiedener Spark-Executors.
![\[Screenshot der Spark-Benutzeroberfläche mit den abgeschlossenen, fehlgeschlagenen und aktiven Phasen verschiedener Spark-Executors.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/spark-ui2.png)
Der folgende Bildschirm zeigt die Details der SparkSQL-Abfragepläne:
+ Geparster logischer Plan
+ Analysierter logischer Plan
+ Optimierter logischer Plan
+ Physischer Plan für die Ausführung
![\[SparkSQL-Abfragepläne: geparster, analysierter und optimierter logischer Plan und physische Pläne für die Ausführung.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/spark-ui3.png)
**Topics**
+ [Berechtigungen](#monitor-spark-ui-limitations-permissions)
+ [Einschränkungen](#monitor-spark-ui-limitations)
+ [Beispiel: Web-UI von Apache Spark](#monitor-spark-ui-limitations-example)
+ [Aktivieren der Apache-Spark-Webbenutzeroberfläche für AWS Glue-Aufgaben](monitor-spark-ui-jobs.md)
+ [Starten des Spark History-Servers](monitor-spark-ui-history.md)
# Aktivieren der Apache-Spark-Webbenutzeroberfläche für AWS Glue-Aufgaben
Sie können die Apache-Spark-Webbenutzeroberfläche verwenden, um AWS Glue-ETL-Aufgaben zu überwachen und zu debuggen, die im AWS Glue-Aufgabensystem ausgeführt werden. Sie können die Spark-Benutzeroberfläche über die AWS Glue-Konsole oder die AWS Command Line Interface (AWS CLI) konfigurieren.
AWS Glue sichert die Spark-Ereignisprotokolle alle 30 Sekunden zu dem von Ihnen angegebenen Amazon-S3-Pfad.
**Topics**
+ [Konfigurieren der Spark-Benutzeroberfläche (Konsole)](#monitor-spark-ui-jobs-console)
+ [Konfigurieren der Spark-Benutzeroberfläche (AWS CLI)](#monitor-spark-ui-jobs-cli)
+ [Konfigurieren der Spark-Benutzeroberfläche für Sitzungen mit Notebooks](#monitor-spark-ui-sessions)
+ [Aktivieren fortlaufender Protokolle](#monitor-spark-ui-rolling-logs)
## Konfigurieren der Spark-Benutzeroberfläche (Konsole)
Gehen Sie wie folgt vor, um die Spark-Benutzeroberfläche über die AWS-Managementkonsole zu konfigurieren. Beim Erstellen eines AWS Glue Jobs ist die Spark-Benutzeroberfläche standardmäßig aktiviert.
**Die Spark-Benutzeroberfläche aktivieren, wenn Sie einen Auftrag erstellen oder bearbeiten**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS Glue Konsole unter [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).
1. Wählen Sie im Navigationsbereich die Option **Jobs (Aufträge)** aus.
1. Wählen **Auftrag hinzufügen** oder einen vorhandenen Auftrag aus.
1. Klicken Sie in den **Auftragsdetails** auf **Erweiterte Eigenschaften**.
1. Wählen Sie auf der Registerkarte **Spark-Benutzeroberfläche** die Option **Spark-UI-Protokolle in Amazon S3 schreiben** aus.
1. Geben Sie einen Amazon-S3-Pfad zum Speichern der Spark-Ereignisprotokolle für die Aufgabe an. Beachten Sie, dass die Verschlüsselung auch auf die Protokolldatei der Spark-Benutzeroberfläche angewendet wird, wenn Sie im Auftrag eine Sicherheitskonfiguration verwenden. Weitere Informationen finden Sie unter [Verschlüsselung von Daten, die geschrieben wurden von AWS Glue](encryption-security-configuration.md).
1. Gehen Sie unter **Konfiguration der Protokollierung und Überwachung in der Spark-Benutzeroberfläche** wie folgt vor:
+ Wählen Sie **Standard** aus, wenn Sie Protokolle zur Anzeige in der AWS Glue Konsole generieren.
+ Wenn Sie Protokolle zur Anzeige auf einem Spark History-Server generieren, wählen Sie **Legacy** aus.
+ Sie können auch beide Protokolltypen generieren.
## Konfigurieren der Spark-Benutzeroberfläche (AWS CLI)
Um Protokolle für die Anzeige mit der Spark-Benutzeroberfläche zu generieren, verwenden Sie in der AWS Glue Konsole die, AWS CLI um die folgenden Job-Parameter an AWS Glue Jobs zu übergeben. Weitere Informationen finden Sie unter [Verwenden von Auftragsparametern in AWS Glue-Jobs](aws-glue-programming-etl-glue-arguments.md).
```
'--enable-spark-ui': 'true',
'--spark-event-logs-path': 's3://s3-event-log-path'
```
Um Protokolle an ihre Legacy-Speicherorte zu verteilen, setzen Sie den Parameter `--enable-spark-ui-legacy-path` auf `"true"`. Wenn Sie keine Protokolle in den beiden Formaten generieren möchten, entfernen Sie den Parameter `--enable-spark-ui`.
## Konfigurieren der Spark-Benutzeroberfläche für Sitzungen mit Notebooks
**Warnung**
AWS Glue interaktive Sitzungen unterstützen derzeit keine Spark-Benutzeroberfläche in der Konsole. Konfigurieren Sie einen Spark History-Server.
Wenn Sie AWS Glue Notebooks verwenden, richten Sie die SparkUI-Konfiguration ein, bevor Sie die Sitzung starten. Verwenden Sie dazu das `%%configure`-Zellen-Magic:
```
%%configure { “--enable-spark-ui”: “true”, “--spark-event-logs-path”: “s3://path” }
```
## Aktivieren fortlaufender Protokolle
Die Aktivierung von SparkUI und das Rolling von Log-Ereignisdateien für AWS Glue Jobs bietet mehrere Vorteile:
+ Rolling Log Event Files — Wenn die rollierenden Log-Ereignisdateien aktiviert sind, werden separate Protokolldateien für jeden Schritt der Jobausführung AWS Glue generiert, sodass Probleme, die für eine bestimmte Phase oder Transformation spezifisch sind, leichter identifiziert und behoben werden können.
+ Bessere Protokollverwaltung – Ereignisdateien fortlaufender Protokolle helfen dabei, Protokolldateien effizienter zu verwalten. Anstatt eine einzige, potenziell große Protokolldatei zu haben, werden die Protokolle je nach den Phasen der Auftragsausführung in kleinere, besser verwaltbare Dateien aufgeteilt. Dies kann die Archivierung, Analyse und Problembehandlung von Protokollen vereinfachen.
+ Verbesserte Fehlertoleranz — Wenn ein AWS Glue Job fehlschlägt oder unterbrochen wird, können die Rolling-Log-Ereignisdateien wertvolle Informationen über die letzte erfolgreiche Phase liefern, sodass es einfacher ist, den Job an diesem Punkt fortzusetzen, anstatt von vorne zu beginnen.
+ Kostenoptimierung – Durch die Aktivierung von Ereignisdateien fortlaufender Protokolle können Sie die mit Protokolldateien verbundenen Speicherkosten verringern. Statt einer einzelnen, potenziell großen Protokolldatei werden kleinere, besser verwaltbare Protokolldateien gespeichert, was insbesondere bei lang andauernden oder komplexen Aufträgen kostengünstiger sein kann.
In einer neuen Umgebung können Benutzer fortlaufende Protokolle explizit wie folgt aktivieren:
```
'—conf': 'spark.eventLog.rolling.enabled=true'
```
oder
```
'—conf': 'spark.eventLog.rolling.enabled=true —conf
spark.eventLog.rolling.maxFileSize=128m'
```
Wenn fortlaufende Protokolle aktiviert sind, gibt `spark.eventLog.rolling.maxFileSize` die maximale Größe der Ereignisprotokolldatei an, bevor ein Roll-Over ausgeführt wird. Wenn der Standardwert für diesen optionalen Parameter nicht angegeben wird, wird der Standardwert 128 MB verwendet. Mindestens 10 MB.
Die maximale Summe aller generierten Ereignisdateien für fortlaufende Protokolle beträgt 2 GB. Für AWS Glue Jobs ohne Rolling-Log-Unterstützung beträgt die maximale Größe der Protokollereignisdatei, die für SparkUI unterstützt wird, 0,5 GB.
Sie können fortlaufende Protokolle für einen Streaming-Auftrag deaktivieren, indem Sie eine zusätzliche Konfiguration übergeben. Beachten Sie, dass die Pflege sehr großer Protokolldateien kostspielig sein kann.
Um fortlaufende Protokolle zu deaktivieren, stellen Sie die folgende Konfiguration bereit:
```
'--spark-ui-event-logs-path': 'true',
'--conf': 'spark.eventLog.rolling.enabled=false'
```
# Starten des Spark History-Servers
Mit einem Spark History-Server können Sie die Spark-Protokolle in Ihrer eigenen Infrastruktur visualisieren. Sie können dieselben Visualisierungen in der AWS Glue Konsole für AWS Glue Jobausführungen auf Versionen AWS Glue 4.0 oder höher sehen, wobei die Logs im Standardformat (und nicht im Legacy-Format) generiert wurden. Weitere Informationen finden Sie unter [Überwachen von Aufgaben über die Apache-Spark-Webbenutzeroberfläche](monitor-spark-ui.md).
Sie können den Spark-Verlaufsserver mithilfe einer AWS CloudFormation Vorlage starten, die den Server auf einer EC2-Instance hostet, oder lokal mit Docker starten.
**Topics**
+ [Den Spark-History-Server starten und die Spark-Benutzeroberfläche anzeigen mit AWS CloudFormation](#monitor-spark-ui-history-cfn)
+ [Starten des Spark History-Servers und Anzeigen der Spark-Benutzeroberfläche über Docker](#monitor-spark-ui-history-local)
## Den Spark-History-Server starten und die Spark-Benutzeroberfläche anzeigen mit AWS CloudFormation
Sie können eine AWS CloudFormation Vorlage verwenden, um den Apache Spark-History-Server zu starten und die Spark-Weboberfläche anzuzeigen. Diese Vorlagen sind Beispiele, die Sie entsprechend Ihren Anforderungen anpassen sollten.
**Um den Spark-Geschichtsserver zu starten und die Spark-Benutzeroberfläche anzuzeigen, verwenden Sie CloudFormation**
1. Wählen Sie eine der Schaltflächen **Launch Stack (Stack starten)** in der folgenden Tabelle aus. Dadurch wird der Stack auf der CloudFormation Konsole gestartet.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitor-spark-ui-history.html)
1. Wählen Sie auf der Seite **Specify template (Vorlage angeben)** die Option **Next (Weiter)** aus.
1. Geben Sie auf der Seite **Specify stack details (Stack-Details angeben)** den Wert für **Stack name (Stack-Name)** ein. Geben Sie zusätzliche Informationen unter **Parameter** ein.
1.
**Konfiguration der Spark-Benutzeroberfläche**
Geben Sie die folgenden Informationen ein:
+ **IP-Adressbereich** – Der IP-Adressbereich, der zum Anzeigen der Spark-Benutzeroberfläche verwendet werden kann. Wenn Sie den Zugriff in Bezug auf einen bestimmten IP-Adressbereich einschränken möchten, sollten Sie einen benutzerdefinierten Wert verwenden.
+ **History-Server-Port** – Der Port für die Spark-Benutzeroberfläche. Sie können den Standardwert verwenden.
+ **Ereignisprotokollverzeichnis** – Wählen Sie den Speicherort, an dem die Spark-Ereignisprotokolle gespeichert werden, aus den AWS Glue-Job- oder Entwicklungsendpunkten. Für das Pfadschema der Ereignisprotokolle müssen Sie **s3a://** verwenden.
+ **Spark-Package-Standort** – Sie können den Standardwert verwenden.
+ **Keystore-Pfad** — SSL/TLS Keystore-Pfad für HTTPS. Wenn Sie eine benutzerdefinierte Schlüsselspeicherdatei verwenden möchten, können Sie den S3-Pfad `s3://path_to_your_keystore_file` hier angeben. Wenn Sie diesen Parameter leer lassen, wird ein selbstsignierter, zertifikatbasierter Schlüsselspeicher generiert und verwendet.
+ **KeyStore-Passwort** – Geben Sie SSL/TLS-KeyStore-Passwort für HTTPS ein.
1.
**Konfigurieren der EC2-Instance**
Geben Sie die folgenden Informationen ein:
+ **Instance-Typ** – Der Typ der Amazon-EC2-Instance, der den Spark-History-Server hostet. Da diese Vorlage die Amazon-EC2-Instance in Ihrem Konto startet, werden Amazon-EC2-Kosten Ihrem Konto separat in Rechnung gestellt.
+ **Neueste AMI-ID** – Die AMI-ID von Amazon Linux 2 für die Spark-Verlaufsserver-Instance. Sie können den Standardwert verwenden.
+ **VPC ID** – Die Virtual Private Cloud (VPC)-ID für die Spark-History-Server-Instance. Sie können alle in Ihrem Konto VPCs verfügbaren Optionen verwenden. Die Verwendung einer Standard-VPC mit einer [Standard-Netzwerk-ACL](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#default-network-acl) wird nicht empfohlen. Weitere Informationen finden Sie unter [Default VPC and Default Subnets (Standard-VPC und Standard-Subnetze)](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html) und unter [Creating a VPC (Erstellen einer VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#Create-VPC) im *Amazon-VPC-Benutzerhandbuch*.
+ **Subnetz-ID** – Die ID für die Spark-Verlaufsserver-Instance. Sie können jedes Subnetz in Ihrer VPC verwenden. Sie müssen das Subnetz von Ihrem Client aus erreichen können. Wenn Sie über das Internet auf das Subnetz zugreifen möchten, müssen Sie ein öffentliches Subnetz mit dem Internet-Gateway in der Routing-Tabelle verwenden.
1. Wählen Sie **Weiter** aus.
1. Wählen Sie auf der Seite **Stack-Optionen konfigurieren** die Option **Weiter** aus, um anhand der aktuellen Benutzeranmeldedaten zu bestimmen, wie Ressourcen im Stack erstellt, geändert oder gelöscht werden CloudFormation können. Sie können im Abschnitt **Berechtigungen** auch eine Rolle angeben, die anstelle der aktuellen Benutzerberechtigungen verwendet werden soll, und dann **Weiter** wählen.
1. Überprüfen Sie die Vorlage auf der Seite **Review (Prüfen)**.
Wählen Sie **Ich bestätige, dass CloudFormation möglicherweise IAM-Ressourcen erstellt** werden, und wählen Sie dann **Stack erstellen** aus.
1. Warten Sie, bis der Stack erstellt wurde.
1. Öffnen Sie die Registerkarte **Outputs (Ausgaben)**.
1. Kopieren Sie die URL von **SparkUiPublicUrl**, wenn Sie ein öffentliches Subnetz verwenden.
1. Kopieren Sie die URL von **SparkUiPrivateUrl**, wenn Sie ein privates Subnetz verwenden.
1. Öffnen Sie einen Webbrowser und fügen Sie die URL ein. Auf diese Weise können Sie über HTTPS auf dem angegebenen Port auf den Server zugreifen. Ihr Browser erkennt möglicherweise nicht das Zertifikat des Servers. In diesem Fall müssen Sie den Schutz des Servers außer Kraft setzen und trotzdem fortfahren.
## Starten des Spark History-Servers und Anzeigen der Spark-Benutzeroberfläche über Docker
Wenn Sie den lokalen Zugriff bevorzugen (d. h., keine EC2-Instance für den Apache Spark History-Server verwenden möchten), können Sie auch Docker verwenden, um den Apache Spark History-Server zu starten und die Spark-Benutzeroberfläche lokal anzuzeigen. Diese Dockerfile ist ein Beispiel, das Sie entsprechend Ihren Anforderungen anpassen sollten.
**Voraussetzungen**
Informationen zum Installieren von Docker auf Ihrem Laptop finden Sie in der [Docker Engine-Community](https://docs.docker.com/install/).
**So starten Sie den Spark History-Server und zeigen die Spark-Benutzeroberfläche lokal über Docker an**
1. Laden Sie Dateien herunter von GitHub.
Laden Sie die Dockerfile und `pom.xml` aus den [ AWS Glue-Codebeispielen](https://github.com/aws-samples/aws-glue-samples/tree/master/utilities/Spark_UI/) herunter.
1. Bestimmen Sie, ob Sie Ihre Benutzeranmeldeinformationen oder Verbundbenutzeranmeldeinformationen für den Zugriff auf AWS verwenden möchten.
+ Um die aktuellen Benutzeranmeldedaten für den Zugriff zu verwenden AWS, rufen Sie die Werte ab, die für ` AWS_ACCESS_KEY_ID` und `AWS_SECRET_ACCESS_KEY` im `docker run` Befehl verwendet werden sollen. Weitere Informationen finden Sie unter [Verwalten der Zugriffsschlüssel für IAM-Benutzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html) im *-IAM-Benutzerhandbuch*.
+ Um SAML 2.0-Verbundbenutzer für den Zugriff zu verwenden AWS, rufen Sie die Werte für ` AWS_ACCESS_KEY_ID``AWS_SECRET_ACCESS_KEY`, und ab. ` AWS_SESSION_TOKEN` Weitere Informationen finden Sie unter [Anfordern von temporären Sicherheitsanmeldeinformationen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html)
1. Bestimmen Sie den Speicherort Ihres Ereignisprotokollverzeichnisses für die Verwendung im `docker run`-Befehl.
1. Erstellen Sie das Docker-Image mit den Dateien im lokalen Verzeichnis unter Verwendung des Namens` glue/sparkui`, und das Tag`latest`aus.
```
$ docker build -t glue/sparkui:latest .
```
1. Erstellen und starten Sie den Docker-Container.
Verwenden Sie in den folgenden Befehlen die zuvor in den Schritten 2 und 3 beschafften Werte.
1. Verwenden Sie einen Befehl wie den folgenden, um den Docker-Container mit Ihren Benutzeranmeldeinformationen zu erstellen
```
docker run -itd -e SPARK_HISTORY_OPTS="$SPARK_HISTORY_OPTS -Dspark.history.fs.logDirectory=s3a://path_to_eventlog
-Dspark.hadoop.fs.s3a.access.key=AWS_ACCESS_KEY_ID -Dspark.hadoop.fs.s3a.secret.key=AWS_SECRET_ACCESS_KEY"
-p 18080:18080 glue/sparkui:latest "/opt/spark/bin/spark-class org.apache.spark.deploy.history.HistoryServer"
```
1. Um den Docker-Container mit temporären Anmeldeinformationen zu erstellen, verwenden Sie ` org.apache.hadoop.fs.s3a.TemporaryAWSCredentialsProvider` als Anbieter und geben Sie die in Schritt 2 beschafften Anmeldeinformationen an. Weitere Informationen finden Sie unter [Using Session Credentials with Temporary AWSCredentials Provider](https://hadoop.apache.org/docs/stable/hadoop-aws/tools/hadoop-aws/index.html#Using_Session_Credentials_with_TemporaryAWSCredentialsProvider) in der Dokumentation *Hadoop: Integration with Amazon Web Services*.
```
docker run -itd -e SPARK_HISTORY_OPTS="$SPARK_HISTORY_OPTS -Dspark.history.fs.logDirectory=s3a://path_to_eventlog
-Dspark.hadoop.fs.s3a.access.key=AWS_ACCESS_KEY_ID -Dspark.hadoop.fs.s3a.secret.key=AWS_SECRET_ACCESS_KEY
-Dspark.hadoop.fs.s3a.session.token=AWS_SESSION_TOKEN
-Dspark.hadoop.fs.s3a.aws.credentials.provider=org.apache.hadoop.fs.s3a.TemporaryAWSCredentialsProvider"
-p 18080:18080 glue/sparkui:latest "/opt/spark/bin/spark-class org.apache.spark.deploy.history.HistoryServer"
```
**Anmerkung**
Diese Konfigurationsparameter stammen aus dem [ Hadoop-AWS-Modul](https://hadoop.apache.org/docs/stable/hadoop-aws/tools/hadoop-aws/index.html). Sie müssen möglicherweise je nach Anwendungsfall eine spezielle Konfiguration vornehmen. Zum Beispiel: Benutzer in isolierten Regionen müssen den ` spark.hadoop.fs.s3a.endpoint` konfigurieren.
1. Öffnen Sie `http://localhost:18080` in Ihrem Browser, um die Spark-Benutzeroberfläche lokal anzuzeigen.
# Überwachung mit Einblicken in die AWS Glue Auftragsausführung
AWS Glue Job Run Insights ist eine Funktion AWS Glue , die das Debuggen und die Optimierung von Jobs für Ihre AWS Glue Jobs vereinfacht. AWS Glue bietet die [Spark-Benutzeroberfläche](https://docs.aws.amazon.com/glue/latest/dg/monitor-spark-ui.html) sowie [CloudWatch Protokolle und Metriken](https://docs.aws.amazon.com/glue/latest/dg/monitor-cloudwatch.html) für die Überwachung Ihrer AWS Glue Jobs. Mit dieser Funktion erhalten Sie folgende Informationen über die Ausführung Ihres AWS Glue Jobs:
+ Zeilennummer Ihres AWS Glue Job-Skripts, bei dem ein Fehler aufgetreten ist.
+ Spark-Aktion, die zuletzt im Spark-Abfrageplan kurz vor dem Fehler Ihres Auftrags ausgeführt wurde.
+ Spark-Ausnahmeereignisse im Zusammenhang mit dem Fehler, der in einem zeitgeordneten Protokollstream dargestellt wird.
+ Ursachenanalyse und empfohlene Maßnahmen (z. B. die Optimierung Ihres Skripts), um das Problem zu beheben.
+ Häufige Spark-Ereignisse (Protokollmeldungen in Bezug auf eine Spark-Aktion) mit einer empfohlenen Aktion, die die Ursache behandelt.
All diese Erkenntnisse stehen Ihnen mithilfe von zwei neuen Log-Streams in den CloudWatch Logs für Ihre AWS Glue Jobs zur Verfügung.
## Voraussetzungen
Die Funktion „Einblicke in die AWS Glue Auftragsausführung“ ist für die AWS Glue Versionen 2.0 und höher verfügbar. Sie können dem [Migrationsleitfaden](https://docs.aws.amazon.com/glue/latest/dg/migrating-version-30.html) für Ihre bestehenden Jobs folgen, um sie von älteren AWS Glue Versionen zu aktualisieren.
## Einblicke in die Jobausführung für einen AWS Glue ETL-Job aktivieren
Sie können Einblicke in die Jobausführung über AWS Glue Studio oder über die CLI aktivieren.
### AWS Glue Studio
Wenn Sie einen Job über erstellen AWS Glue Studio, können Sie die Einblicke in die Jobausführung auf der Registerkarte **Jobdetails** aktivieren oder deaktivieren. Überprüfen Sie, ob das Kontrollkästchen **Auftragserkenntnisse generieren** aktiviert ist.
![\[Aktivieren von Erkenntnissen in Auftragsausführungen in AWS Glue Studio.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-job-run-insights-1.png)
### Befehlszeile
Wenn Sie einen Auftrag über die CLI erstellen, können Sie eine Auftragsausführung mit einem einzigen neuen [Auftrags-Parameter](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-glue-arguments.html) starten: `--enable-job-insights = true`.
Standardmäßig werden die Protokoll-Streams der Auftragsausführungs-Erkenntnisse unter derselben Standardprotokollgruppe erstellt, die von [Kontinuierliche AWS Glue -Protokollierung](https://docs.aws.amazon.com/glue/latest/dg/monitor-continuous-logging.html), das heißt, `/aws-glue/jobs/logs-v2/` verwendet wird. Sie können benutzerdefinierte Protokollgruppennamen, Protokollfilter und Protokollgruppenkonfigurationen mit denselben Argumenten für die kontinuierliche Protokollierung einrichten. Weitere Informationen finden Sie unter [Kontinuierliche Protokollierung für AWS Glue Jobs aktivieren](https://docs.aws.amazon.com/glue/latest/dg/monitor-continuous-logging-enable.html).
## Beim Zugriff auf den Job Run Insights werden Streams protokolliert in CloudWatch
Wenn das Feature „Auftragsausführungs-Erkenntnisse“ aktiviert ist, werden möglicherweise zwei Protokoll-Streams erstellt, wenn eine Auftragsausführung fehlschlägt. Wenn ein Auftrag erfolgreich abgeschlossen ist, wird keiner der Streams generiert.
1. *Protokoll-Stream für Ausnahmeanalyse*: `-job-insights-rca-driver`. Dieser Stream bietet Folgendes:
+ Zeilennummer Ihres AWS Glue Job-Skripts, das den Fehler verursacht hat.
+ Spark-Aktion, die zuletzt im Spark-Abfrageplan (DAG) ausgeführt wurde.
+ Prägnante zeitgeordnete Ereignisse des Spark-Treibers und der Executors, die mit der Ausnahme zusammenhängen. Hier finden Sie Details wie vollständige Fehlermeldungen, die fehlgeschlagene Spark-Aufgabe und deren Executor-ID, die Ihnen helfen, sich bei Bedarf auf den Protokoll-Stream des jeweiligen Executors zu konzentrieren.
1. *Regelbasierter Erkenntnis-Stream*:
+ Ursachenanalyse und Empfehlungen zur Behebung der Fehler (z. B. Verwendung eines bestimmten Auftrags-Parameters zur Optimierung der Leistung).
+ Relevante Spark-Ereignisse, die als Grundlage für die Ursachenanalyse und eine empfohlene Aktion dienen.
**Anmerkung**
Der erste Stream wird nur vorhanden sein, wenn Spark-Ausnahme-Ereignisse für eine fehlgeschlagene Auftragsausführung verfügbar sind und der zweite Stream wird nur vorhanden sein, wenn Erkenntnisse für die fehlgeschlagene Auftragsausführung verfügbar sind. Wenn Ihr Auftrag beispielsweise erfolgreich abgeschlossen ist, wird keiner der Streams generiert. Wenn Ihr Auftrag fehlschlägt, aber keine dienstdefinierte Regel vorhanden ist, die mit Ihrem Fehlerszenario übereinstimmen kann, wird nur der erste Stream generiert.
Wenn der Job aus erstellt wurde AWS Glue Studio, sind die Links zu den oben genannten Streams auch auf der Registerkarte Job-Rundetails (Job Run Insights) als „Präzise und konsolidierte Fehlerprotokolle“ und „Fehleranalyse und Anleitung“ verfügbar.
![\[Die Seite „Auftrags-Ausführungsdetails“ mit Links zu den Protokoll-Streams.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-job-run-insights-2.png)
## Beispiel für Einblicke in die AWS Glue Auftragsausführung
In diesem Abschnitt stellen wir Ihnen ein Beispiel vor, wie das Feature „Auftragsausführungs-Erkenntnisse“ Ihnen helfen kann, ein Problem in Ihrem fehlgeschlagenen Auftrag zu lösen. In diesem Beispiel hat ein Benutzer vergessen, das erforderliche Modul (Tensorflow) in einen AWS Glue Job zu importieren, um seine Daten zu analysieren und ein Modell für maschinelles Lernen zu erstellen.
```
import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job
from pyspark.sql.types import *
from pyspark.sql.functions import udf,col
args = getResolvedOptions(sys.argv, ['JOB_NAME'])
sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args['JOB_NAME'], args)
data_set_1 = [1, 2, 3, 4]
data_set_2 = [5, 6, 7, 8]
scoresDf = spark.createDataFrame(data_set_1, IntegerType())
def data_multiplier_func(factor, data_vector):
import tensorflow as tf
with tf.compat.v1.Session() as sess:
x1 = tf.constant(factor)
x2 = tf.constant(data_vector)
result = tf.multiply(x1, x2)
return sess.run(result).tolist()
data_multiplier_udf = udf(lambda x:data_multiplier_func(x, data_set_2), ArrayType(IntegerType(),False))
factoredDf = scoresDf.withColumn("final_value", data_multiplier_udf(col("value")))
print(factoredDf.collect())
```
Ohne das Feature „Auftragsausführungs-Erkenntnisse“ wird nur die folgende Nachricht angezeigt, die von Spark ausgelöst wird, da der Auftrag fehlschlägt:
`An error occurred while calling o111.collectToPython. Traceback (most recent call last):`
Die Nachricht ist mehrdeutig und schränkt Ihre Debugging-Erfahrung ein. In diesem Fall bietet Ihnen diese Funktion zusätzliche Einblicke in zwei CloudWatch Protokollstreams:
1. Der `job-insights-rca-driver`-Protokoll-Stream:
+ *Ausnahme-Ereignisse*: Dieser Protokoll-Stream bietet Ihnen die Spark-Ausnahmeereignisse im Zusammenhang mit dem Fehler, der vom Spark-Treiber und verschiedenen verteilten Workern gesammelt wurde. Diese Ereignisse helfen Ihnen, die zeitlich geordnete Ausbreitung der Ausnahme zu verstehen, wenn fehlerhafter Code auf Spark-Aufgaben, Executoren und Stages, die über die Worker verteilt sind, ausgeführt wird. AWS Glue
+ *Zeilennummern*: Dieser Protokoll-Stream identifiziert Zeile 21, die den Aufruf zum Importieren des fehlenden Python-Moduls gemacht hat, das den Fehler verursacht hat; Außerdem wird Zeile 24, der Aufruf von Spark Action `collect()`, als die zuletzt ausgeführte Zeile in Ihrem Skript identifiziert.
![\[Der Log-Stream. job-insights-rca-driver\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-job-run-insights-3.png)
1. Der `job-insights-rule-driver`-Protokoll-Stream:
+ *Grundursache und Empfehlung*: Neben der Zeilennummer und der zuletzt ausgeführten Zeilennummer für den Fehler in Ihrem Skript zeigt dieser Protokollstream die Ursachenanalyse und die Empfehlung für Sie, dem AWS Glue Dokument zu folgen und die erforderlichen Jobparameter einzurichten, um ein zusätzliches Python-Modul in Ihrem AWS Glue Job zu verwenden.
+ *Basis-Ereignis*: Dieser Protokoll-Stream zeigt auch das Spark-Ausnahmeereignis an, das mit der vom Service definierten Regel ausgewertet wurde, um die Ursache abzuleiten und eine Empfehlung abzugeben.
![\[Der job-insights-rule-driver Log-Stream.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-job-run-insights-4.png)
# Überwachung mit Amazon CloudWatch
Sie können die Überwachung AWS Glue mithilfe von Amazon durchführen CloudWatch, das Rohdaten sammelt und AWS Glue in lesbare near-real-time Messwerte umwandelt. Diese Statistiken werden für einen Zeitraum von zwei Wochen aufgezeichnet, damit Sie auf Verlaufsinformationen zugreifen können und einen besseren Überblick über die Performance der Webanwendung oder des Services erhalten. Standardmäßig werden AWS Glue Metrikdaten CloudWatch automatisch an gesendet. Weitere Informationen finden Sie unter [Was ist Amazon CloudWatch?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatch.html) im * CloudWatch Amazon-Benutzerhandbuch* und[AWS Glue Metriken](monitoring-awsglue-with-cloudwatch-metrics.md#awsglue-metrics).
**Kontinuierliche Protokollierung**
AWS Glue unterstützt außerdem die kontinuierliche Echtzeitprotokollierung für AWS Glue-Aufträge. Wenn die kontinuierliche Protokollierung für einen Job aktiviert ist, können Sie die Echtzeitprotokolle auf der AWS Glue Konsole oder im CloudWatch Konsolen-Dashboard einsehen. Weitere Informationen finden Sie unter [Protokollierung für AWS Glue Jobs](monitor-continuous-logging.md).
**Beobachtbarkeitsmetriken**
Wenn **Job-Observability-Metriken** aktiviert sind, werden zusätzliche Amazon CloudWatch Metriken generiert, wenn der Job ausgeführt wird. Nutzen Sie AWS Glue-Beobachtbarkeitsmetriken, um Einblicke in die Abläufe in AWS Glue zu erhalten. So können Sie die Sichtung und Analyse von Problemen verbessern.
**Topics**
+ [Überwachung AWS Glue anhand von CloudWatch Amazon-Metriken](monitoring-awsglue-with-cloudwatch-metrics.md)
+ [CloudWatch Amazon-Alarme in AWS Glue Jobprofilen einrichten](monitor-profile-glue-job-cloudwatch-alarms.md)
+ [Protokollierung für AWS Glue Jobs](monitor-continuous-logging.md)
+ [Überwachung mit AWS Glue-Beobachtbarkeitsmetriken](monitor-observability.md)
# Überwachung AWS Glue anhand von CloudWatch Amazon-Metriken
Sie können AWS Glue-Operationen mit dem AWS Glue-Auftrags-Profiler profilieren und überwachen. Es sammelt und verarbeitet Rohdaten von AWS Glue Jobs zu lesbaren, nahezu in Echtzeit gespeicherten Metriken, die in Amazon gespeichert sind CloudWatch. Diese Statistiken werden gespeichert und aggregiert, CloudWatch sodass Sie auf historische Informationen zugreifen können, um einen besseren Überblick über die Leistung Ihrer Anwendung zu erhalten.
**Anmerkung**
Es können zusätzliche Gebühren anfallen, wenn Sie Job-Metriken aktivieren und CloudWatch benutzerdefinierte Metriken erstellt werden. Weitere Informationen finden Sie unter [ CloudWatch Amazon-Preise](https://aws.amazon.com/cloudwatch/pricing/).
## AWS Glue-Metriken – Übersicht
Wenn Sie mit interagierenAWS Glue, sendet es Metriken an CloudWatch. Sie können diese Metriken über die AWS Glue Konsole (die bevorzugte Methode), das CloudWatch Konsolen-Dashboard oder die AWS Command Line Interface (AWS CLI) anzeigen.
**Anzeige von Metriken über das Dashboard der AWS Glue-Konsole**
Sie können zusammenfassende oder detaillierte Diagramme von Metriken für einen Auftrag oder detaillierte Diagramme für eine Auftragsausführung anzeigen.
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS Glue Konsole unter [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).
1. Wählen Sie im Navigationsbereich **Überwachung der Auftragsausführung** aus.
1. Wählen Sie unter **Auftragsausführungen** die Option **Aktionen**, um einen gerade ausgeführten Auftrag anzuhalten, einen Auftrag anzuzeigen oder ein Auftragslesezeichen zurückzuspulen.
1. Wählen Sie einen Auftrag aus und wählen Sie dann **Details zur Ausführung anzeigen**, um zusätzliche Informationen zur Auftragsausführung anzuzeigen.
**Um Metriken über das CloudWatch Konsolen-Dashboard anzuzeigen**
Metriken werden zunächst nach dem Service-Namespace und anschließend nach den verschiedenen Dimensionskombinationen in den einzelnen Namespaces gruppiert.
1. Öffnen Sie die CloudWatch Konsole unter [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Wählen Sie im Navigationsbereich **Metriken** aus.
1. Wählen Sie den Namespace **Glue** aus.
**Um Metriken mit dem anzuzeigen AWS CLI**
+ Geben Sie als Eingabeaufforderung den folgenden Befehl ein.
```
1. aws cloudwatch list-metrics --namespace Glue
```
AWS Gluemeldet Metriken CloudWatch alle 30 Sekunden, und die CloudWatch Metrik-Dashboards sind so konfiguriert, dass sie jede Minute angezeigt werden. Die AWS Glue-Metriken stellen Deltawerte gegenüber den zuvor gemeldeten Werten dar. Gegebenenfalls aggregieren (summieren) die Metrik-Dashboards die 30-Sekunden-Wertezu einem Wert für die gesamte vergangene Minute.
### AWS Glue Verhalten von Metriken für Spark-Jobs
AWS Glue-Metriken werden bei der Initialisierung eines `GlueContext` in einem Skript aktiviert und in der Regel nur am Ende einer Apache-Spark-Aufgabe aktualisiert. Sie stellen die aggregierten Werte in allen abgeschlossenen Spark-Aufgaben dar.
Bei den Spark-Metriken, die AWS Glue an weitergegeben CloudWatch werden, handelt es sich jedoch im Allgemeinen um absolute Werte, die den aktuellen Status zum Zeitpunkt der Meldung darstellen. AWS Gluemeldet sie CloudWatch alle 30 Sekunden, und die Metrik-Dashboards zeigen in der Regel den Durchschnitt der in der letzten Minute empfangenen Datenpunkte an.
Allen AWS Glue-Metriknamen wird eines der folgenden Präfixe vorangestellt:
+ `glue.driver.` – Metriken, deren Namen mit diesem Präfix beginnen, stellen entweder AWS Glue-Metriken dar, die von allen Executors beim Spark-Treiber aggregiert werden, oder Spark-Metriken, die dem Spark-Treiber entsprechen.
+ `glue.`*executorId*`.` – Die *executorId* ist die Nummer eines bestimmten Spark-Executor. Der Wert entspricht den Executors, die in den Protokollen aufgeführt sind.
+ `glue.ALL.` - Metriken, deren Namen mit diesem Präfix beginnen, aggregierte Werte aus allen Spark Executors.
## AWS Glue Metriken
AWS Glue erstellt und sendet CloudWatch alle 30 Sekunden die folgenden Metriken, und das AWS Glue Metrics-Dashboard meldet sie einmal pro Minute:
| Metrik | Description |
| --- | --- |
| `glue.driver.aggregate.bytesRead` | Die Anzahl der Bytes, die von allen abgeschlossenen Spark-Aufgaben von allen Datenquellen gelesen und in allen Executors ausgeführt werden. Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Anzahl). Gültige Statistiken: Summe Bei dieser Metrik handelt es sich um einen Deltawert gegenüber dem zuletzt gemeldeten Wert. Daher wird im AWS Glue Metrik-Dashboard eine SUM-Statistik für die Aggregation verwendet. Einheit: Byte Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Diese Metrik kann genauso verwendet werden wie die `glue.ALL.s3.filesystem.read_bytes`-Metrik mit dem Unterschied, dass diese Metrik am Ende einer Spark-Aufgabe aktualisiert wird und auch Nicht-S3-Datenquellen erfasst. |
| `glue.driver.aggregate.elapsedTime` | Die ETL verstrichene Zeit in Millisekunden (schließt die Bootstrap-Zeiten des Auftrags nicht ein). Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Anzahl). Gültige Statistiken: Summe Bei dieser Metrik handelt es sich um einen Deltawert gegenüber dem zuletzt gemeldeten Wert. Daher wird im AWS Glue Metrik-Dashboard eine SUM-Statistik für die Aggregation verwendet. Einheit: Millisekunden Kann verwendet werden, um zu ermitteln, wie lange eine Auftragsausführung im Durchschnitt dauert. Einige Möglichkeiten, die Daten zu verwenden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) |
| `glue.driver.aggregate.numCompletedStages` | Die Anzahl der abgeschlossenen Phasen im Auftrag. Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Anzahl). Gültige Statistiken: Summe Bei dieser Metrik handelt es sich um einen Deltawert gegenüber dem zuletzt gemeldeten Wert. Daher wird im AWS Glue Metrik-Dashboard eine SUM-Statistik für die Aggregation verwendet. Einheit: Anzahl Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Einige Möglichkeiten, die Daten zu verwenden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) |
| `glue.driver.aggregate.numCompletedTasks` | Die Anzahl der abgeschlossenen Aufgaben im Auftrag. Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Anzahl). Gültige Statistiken: Summe Bei dieser Metrik handelt es sich um einen Deltawert gegenüber dem zuletzt gemeldeten Wert. Daher wird im AWS Glue Metrik-Dashboard eine SUM-Statistik für die Aggregation verwendet. Einheit: Anzahl Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) |
| `glue.driver.aggregate.numFailedTasks` | Die Anzahl der fehlgeschlagenen Aufgaben. Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Anzahl). Gültige Statistiken: Summe Bei dieser Metrik handelt es sich um einen Deltawert gegenüber dem zuletzt gemeldeten Wert. Daher wird im AWS Glue Metrik-Dashboard eine SUM-Statistik für die Aggregation verwendet. Einheit: Anzahl Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Die Daten können verwendet werden, um Alarme für erhöhte Ausfälle einzustellen, die Anomalien in Daten, Clustern oder Skripten andeuten könnten. |
| `glue.driver.aggregate.numKilledTasks` | Anzahl der abgeschlossenen Aufgaben. Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Anzahl). Gültige Statistiken: Summe Bei dieser Metrik handelt es sich um einen Deltawert gegenüber dem zuletzt gemeldeten Wert. Daher wird im AWS Glue Metrik-Dashboard eine SUM-Statistik für die Aggregation verwendet. Einheit: Anzahl Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Einige Möglichkeiten, die Daten zu verwenden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) |
| `glue.driver.aggregate.recordsRead` | Die Anzahl der Datensätze, die von allen abgeschlossenen Spark-Aufgaben von allen Datenquellen gelesen und in allen Executors ausgeführt werden. Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Anzahl). Gültige Statistiken: Summe Bei dieser Metrik handelt es sich um einen Deltawert gegenüber dem zuletzt gemeldeten Wert. Daher wird im AWS Glue Metrik-Dashboard eine SUM-Statistik für die Aggregation verwendet. Einheit: Anzahl Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Diese Metrik kann genauso verwendet werden wie die `glue.ALL.s3.filesystem.read_bytes`-Metrik mit dem Unterschied, dass diese Metrik am Ende einer Spark-Aufgabe aktualisiert wird. |
| `glue.driver.aggregate.shuffleBytesWritten` | Die Anzahl der Byte, die seit dem letzten Bericht von allen Executoren geschrieben wurden, um Daten zwischen ihnen zu mischen (aggregiert vom AWS Glue Metrics Dashboard als die Anzahl der Bytes, die zu diesem Zweck in der letzten Minute geschrieben wurden). Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Anzahl). Gültige Statistiken: Summe Bei dieser Metrik handelt es sich um einen Deltawert gegenüber dem zuletzt gemeldeten Wert. Daher wird im AWS Glue Metrik-Dashboard eine SUM-Statistik für die Aggregation verwendet. Einheit: Byte Kann verwendet werden, um Folgendes zu überwachen: Datenmischung in Aufträgen (große Joins, GroupBy, Repartition, Coalesce). Einige Möglichkeiten, die Daten zu verwenden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) |
| `glue.driver.aggregate.shuffleLocalBytesRead` | Die Anzahl der Byte, die seit dem letzten Bericht von allen Executoren gelesen wurden, um Daten zwischen ihnen zu mischen (vom AWS Glue Metrics Dashboard als die Anzahl der zu diesem Zweck in der letzten Minute gelesenen Byte aggregiert). Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Anzahl). Gültige Statistiken: Summe Bei dieser Metrik handelt es sich um einen Deltawert gegenüber dem zuletzt gemeldeten Wert. Daher wird im AWS Glue Metrik-Dashboard eine SUM-Statistik für die Aggregation verwendet. Einheit: Byte Kann verwendet werden, um Folgendes zu überwachen: Datenmischung in Aufträgen (große Joins, GroupBy, Repartition, Coalesce). Einige Möglichkeiten, die Daten zu verwenden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) |
| `glue.driver.BlockManager.disk.diskSpaceUsed_MB` | Die Anzahl der Megabyte an Speicherplatz, die für alle Executoren verwendet werden. Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Gauge). Gültige Statistiken: Durchschnitt. Dies ist eine Spark-Metrik, die als absoluter Wert gemeldet wird. Einheit: Megabyte Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Einige Möglichkeiten, die Daten zu verwenden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) |
| `glue.driver.ExecutorAllocationManager.executors.numberAllExecutors` | Die Anzahl der aktiven Auftrags-Executors. Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Gauge). Gültige Statistiken: Durchschnitt. Dies ist eine Spark-Metrik, die als absoluter Wert gemeldet wird. Einheit: Anzahl Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Einige Möglichkeiten, die Daten zu verwenden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) |
| `glue.driver.ExecutorAllocationManager.executors.numberMaxNeededExecutors` | Die Anzahl der maximalen (aktiv ausgeführten und ausstehenden) Auftrags-Executors, die benötigt werden, um die aktuelle Last zu erfüllen. Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Gauge). Gültige Statistiken: Maximum. Dies ist eine Spark-Metrik, die als absoluter Wert gemeldet wird. Einheit: Anzahl Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Einige Möglichkeiten, die Daten zu verwenden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) |
| `glue.driver.jvm.heap.usage` `glue.`*executorId*`.jvm.heap.usage` `glue.ALL.jvm.heap.usage` | Den vom JVM-Heap für diesen Treiber (Skalierung: 0-1) verwendeten Speicheranteil – vom Treiber, einem durch executorId identifizierten Executor oder ALLE Executors. Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Gauge). Gültige Statistiken: Durchschnitt. Dies ist eine Spark-Metrik, die als absoluter Wert gemeldet wird. Einheit: Prozentsatz Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Einige Möglichkeiten, die Daten zu verwenden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) |
| `glue.driver.jvm.heap.used` `glue.`*executorId*`.jvm.heap.used` `glue.ALL.jvm.heap.used` | Die Anzahl der vom JVM-Heap verwendeten Speicherbytes für den Treiber, der durch *executorId* oder ALLE Executors identifiziert wurde. Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Gauge). Gültige Statistiken: Durchschnitt. Dies ist eine Spark-Metrik, die als absoluter Wert gemeldet wird. Einheit: Byte Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Einige Möglichkeiten, die Daten zu verwenden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) |
| `glue.driver.s3.filesystem.read_bytes` `glue.`*executorId*`.s3.filesystem.read_bytes` `glue.ALL.s3.filesystem.read_bytes` | Die Anzahl der Byte, die der Treiber, ein durch die *ExecutorID identifizierter Executor oder ALLE Executoren* seit dem letzten Bericht aus Amazon S3 gelesen haben (aggregiert vom AWS Glue Metrics Dashboard als Anzahl der in der letzten Minute gelesenen Byte). Gültige Dimensionen: `JobName`, `JobRunId` und `Type` (Messung). Gültige Statistiken: Summe Bei dieser Metrik handelt es sich um einen Deltawert gegenüber dem zuletzt gemeldeten Wert. Daher wird im AWS Glue Metrik-Dashboard eine SUM-Statistik für die Aggregation verwendet. Der Bereich unter der Kurve im AWS Glue Metrics Dashboard kann verwendet werden, um die von zwei verschiedenen Jobläufen gelesenen Bytes visuell zu vergleichen. Einheit: Byte. Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Die resultierenden Daten können verwendet werden für: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) |
| `glue.driver.s3.filesystem.write_bytes` `glue.`*executorId*`.s3.filesystem.write_bytes` `glue.ALL.s3.filesystem.write_bytes` | Die Anzahl der Byte, die der Treiber, ein durch die *ExecutorID identifizierter Executor oder ALLE Executoren* seit dem letzten Bericht in Amazon S3 geschrieben haben (aggregiert vom AWS Glue Metrics Dashboard als Anzahl der in der letzten Minute geschriebenen Byte). Gültige Dimensionen: `JobName`, `JobRunId` und `Type` (Messung). Gültige Statistiken: Summe Bei dieser Metrik handelt es sich um einen Deltawert gegenüber dem zuletzt gemeldeten Wert. Daher wird im AWS Glue Metrik-Dashboard eine SUM-Statistik für die Aggregation verwendet. Der Bereich unter der Kurve im AWS Glue Metrik-Dashboard kann verwendet werden, um die in zwei verschiedenen Jobläufen geschriebenen Bytes visuell zu vergleichen. Einheit: Byte Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Einige Möglichkeiten, die Daten zu verwenden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) |
| `glue.driver.streaming.numRecords` | Die Anzahl der Datensätze, die in einem Mikrobatch empfangen werden. Diese Metrik ist nur für AWS Glue Streaming-Jobs mit AWS Glue Version 2.0 und höher verfügbar. Gültige Dimensionen: `JobName` (der Name des AWS Glue Jobs), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Anzahl). Gültige Statistiken: Summe, Maximum, Minimum, Durchschnitt, Prozent Einheit: Anzahl Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) |
| `glue.driver.streaming.batchProcessingTimeInMs` | Die Zeit, die für die Verarbeitung der Batches in Millisekunden benötigt wird. Diese Metrik ist nur für AWS Glue Streaming-Jobs mit AWS Glue Version 2.0 und höher verfügbar. Gültige Dimensionen: `JobName` (der Name des AWS Glue Jobs), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Anzahl). Gültige Statistiken: Summe, Maximum, Minimum, Durchschnitt, Prozent Einheit: Anzahl Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) |
| `glue.driver.system.cpuSystemLoad` `glue.`*executorId*`.system.cpuSystemLoad` `glue.ALL.system.cpuSystemLoad` | Der vom Treiber verwendete Anteil der CPU-Systemauslastung (Skalierung: 0-1) – ein durch *executorId* identifizierter Executor oder ALLE Executors. Gültige Dimensionen: `JobName` (der Name des AWS Glue Jobs), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Gauge). Gültige Statistiken: Durchschnitt. Diese Metrik wird als absoluter Wert gemeldet. Einheit: Prozentsatz Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Einige Möglichkeiten, die Daten zu verwenden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) |
## AWS Glue Dimensionen für Metriken
AWS Glue Metriken verwenden den AWS Glue Namespace und stellen Metriken für die folgenden Dimensionen bereit:
| Dimension | Description |
| --- | --- |
| `JobName` | Diese Dimension filtert nach Metriken aller Jobausführungen eines bestimmten AWS Glue Jobs. |
| `JobRunId` | Diese Dimension filtert nach Metriken eines bestimmten AWS Glue Jobs, der von einer JobRun ID ausgeführt wird, oder`ALL`. |
| `Type` | Diese Dimension filtert nach Metriken entweder nach `count` (eine aggregierte Zahl) oder `gauge` (ein Wert zu einem bestimmten Zeitpunkt). |
Weitere Informationen finden Sie im [ CloudWatch Amazon-Benutzerhandbuch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/).
# CloudWatch Amazon-Alarme in AWS Glue Jobprofilen einrichten
AWS GlueMetriken sind auch bei Amazon verfügbar CloudWatch. Sie können Alarme zu jeder AWS Glue-Metrik für geplante Aufträge einrichten.
Einige häufige Szenarien für das Einrichten von Alarmen:
+ Aufträge, die nicht mehr über genügend Speicher verfügen (OOM): Richten Sie einen Alarm für den Fall ein, dass der Speicherverbrauch den normalen Durchschnitt für den Treiber oder einen Executor für einen AWS Glue-Auftrag überschreitet.
+ Wegfall von Executors: Richten Sie einen Alarm für den Fall ein, dass die Anzahl der Executors in einem AWS Glue-Auftrag für lange Zeit unter einen bestimmten Grenzwert fällt.
+ Datenbestand oder Wiederaufbereitung: Vergleichen Sie die Metriken einzelner Jobs in einem Workflow mithilfe eines CloudWatch mathematischen Ausdrucks. Sie können dann einen Alarm für den resultierenden Ausdruckswert auslösen (z. B. das Verhältnis der von einem Auftrag geschriebenen Bytes zu den von einem nachfolgenden Auftrag gelesenen Bytes).
Detaillierte Anweisungen zum Einstellen von Alarmen finden [Sie unter Einen CloudWatch Alarm erstellen oder bearbeiten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) im *[Amazon CloudWatch Events-Benutzerhandbuch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/)*.
Informationen zum Überwachen und Debuggen von Szenarien mit Hilfe von CloudWatch finden Sie unter[Auftragsüberwachung und Debugging](monitor-profile-glue-job-cloudwatch-metrics.md).
# Protokollierung für AWS Glue Jobs
In AWS Glue 5.0 verfügen alle Jobs über Funktionen zur Echtzeitprotokollierung. Darüber hinaus können Sie benutzerdefinierte Konfigurationsoptionen angeben, um das Protokollierungsverhalten anzupassen. Zu diesen Optionen gehören das Festlegen des Amazon CloudWatch Protokollgruppennamens, des Amazon CloudWatch Protokollstream-Präfixes (das der ID und driver/executor ID der AWS Glue Auftragsausführung vorangestellt wird) und des Protokollkonvertierungsmusters für Protokollnachrichten. Mit diesen Konfigurationen können Sie Protokolle in benutzerdefinierten Amazon CloudWatch -Protokollgruppen mit unterschiedlichen Ablaufrichtlinien zusammenfassen. Darüber hinaus können Sie die Protokolle effektiver analysieren, indem Sie benutzerdefinierte Protokollstream-Präfixe und Konvertierungsmuster verwenden. Dieser Grad der Anpassung ermöglicht es Ihnen, die Protokollverwaltung und -analyse gemäß Ihren spezifischen Anforderungen zu optimieren.
## Verhalten bei der Protokollierung in 5.0 AWS Glue
Standardmäßig werden Systemprotokolle, Spark-Daemon-Protokolle und AWS Glue Benutzer-Logger-Protokolle in Amazon CloudWatch die `/aws-glue/jobs/error` Protokollgruppe geschrieben. Andererseits werden die Benutzerprotokolle stdout (Standardausgabe) und stderr (Standardfehler) standardmäßig in die `/aws-glue/jobs/output`-Protokollgruppe geschrieben.
## Benutzerdefiniertes Protokollieren
Sie können die Standardpräfixe für Protokollgruppen und Protokollstreams mithilfe der folgenden Auftragsargumente anpassen:
+ `--custom-logGroup-prefix`: Ermöglicht es Ihnen, ein benutzerdefiniertes Präfix für die Protokollgruppen `/aws-glue/jobs/error` und `/aws-glue/jobs/output` anzugeben. Wenn Sie ein benutzerdefiniertes Präfix angeben, weisen die Namen der Protokollgruppen das folgende Format auf:
+ `/aws-glue/jobs/error` wird `/error` sein.
+ `/aws-glue/jobs/output ` wird `/output` sein.
+ `--custom-logStream-prefix`: Ermöglicht es Ihnen, ein benutzerdefiniertes Präfix für die Namen der Protokollstreams innerhalb der Protokollgruppen anzugeben. Wenn Sie ein benutzerdefiniertes Präfix angeben, weisen die Namen der Protokollstreams das folgende Format auf:
+ `jobrunid-driver` wird `-driver` sein.
+ `jobrunid-executorNum` wird `-executorNum` sein.
Validierungsregeln und Einschränkungen für benutzerdefinierte Präfixe:
+ Der Name des Protokollstreams muss insgesamt zwischen 1 und 512 Zeichen lang sein.
+ Das benutzerdefinierte Präfix selbst ist auf 400 Zeichen beschränkt.
+ Das benutzerdefinierte Präfix muss dem regulären Ausdrucksmuster „[^:\$1]\$1“ entsprechen (zulässige Sonderzeichen sind „\$1“, „-“ und „/“).
## Protokollieren von anwendungsspezifischen Meldungen mit dem benutzerdefinierten Skript-Logger
Sie können den AWS Glue Logger verwenden, um alle anwendungsspezifischen Meldungen im Skript zu protokollieren, die in Echtzeit an den Treiberprotokollstream gesendet werden.
Das folgende Beispiel zeigt ein Python-Skript.
```
from awsglue.context import GlueContext
from pyspark.context import SparkContext
sc = SparkContext()
glueContext = GlueContext(sc)
logger = glueContext.get_logger()
logger.info("info message")
logger.warn("warn message")
logger.error("error message")
```
Das folgende Beispiel zeigt ein Scala-Skript.
```
import com.amazonaws.services.glue.log.GlueLogger
object GlueApp {
def main(sysArgs: Array[String]) {
val logger = new GlueLogger
logger.info("info message")
logger.warn("warn message")
logger.error("error message")
}
}
```
## Aktivieren des Fortschrittsbalkens zum Anzeigen des Auftragsfortschritts
AWS Glue bietet unter dem `JOB_RUN_ID-progress-bar` Protokollstream eine Fortschrittsleiste in Echtzeit, mit der der Status der AWS Glue Auftragsausführung überprüft werden kann. Derzeit unterstützt er nur Aufträge, die `glueContext` initialisieren. Wenn Sie einen reinen Spark-Job ohne Initialisierung ausführen`glueContext`, wird der AWS Glue Fortschrittsbalken nicht angezeigt.
Der Fortschrittsbalken wird alle 5 Sekunden aktualisiert.
```
Stage Number (Stage Name): > (numCompletedTasks + numActiveTasks) / totalNumOfTasksInThisStage]
```
## Sicherheitskonfiguration mit Protokollierung Amazon CloudWatch
Wenn eine Sicherheitskonfiguration für Amazon CloudWatch Protokolle aktiviert ist, werden Protokollgruppen mit bestimmten Benennungsmustern AWS Glue erstellt, die den Namen der Sicherheitskonfiguration enthalten.
### Benennung von Protokollgruppen mit Sicherheitskonfiguration
Die Standard- und benutzerdefinierten Protokollgruppen lauten wie folgt:
+ **Standard-Fehlerprotokollgruppe:** `/aws-glue/jobs/Security-Configuration-Name-role/glue-job-role/error`
+ **Standard-Ausgabeprotokollgruppe:** `/aws-glue/jobs/Security-Configuration-Name-role/glue-job-role/output`
+ **Benutzerdefinierte Fehlerprotokollgruppe (AWS Glue 5.0):** `custom-log-group-prefix/Security-Configuration-Name-role/glue-job-role/error`
+ **Benutzerdefinierte Ausgabeloggruppe (AWS Glue 5.0):** `custom-log-group-prefix/Security-Configuration-Name-role/glue-job-role/output`
### Erforderliche IAM-Berechtigungen
Sie müssen Ihren IAM-Rollenberechtigungen `logs:AssociateKmsKey`-Berichtigungen hinzufügen, wenn Sie eine Sicherheitskonfiguration mit Amazon CloudWatch Logs aktivieren. Wenn diese Berechtigung nicht enthalten ist, wird die fortlaufende Protokollierung deaktiviert.
Um die Verschlüsselung für die Amazon CloudWatch Logs zu konfigurieren, folgen Sie außerdem den Anweisungen unter [Log Data in Amazon CloudWatch Logs Using verschlüsseln AWS Key Management Service](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html) im Amazon Amazon CloudWatch Logs-Benutzerhandbuch.
### Zusätzliche Informationen
Weitere Informationen zum Erstellen von Sicherheitskonfigurationen finden Sie unter [Sicherheitskonfigurationen auf der AWS Glue Konsole verwalten](https://docs.aws.amazon.com/glue/latest/dg/console-security-configurations.html).
**Topics**
+ [Verhalten bei der Protokollierung in 5.0 AWS Glue](#monitor-logging-behavior-glue-50)
+ [Benutzerdefiniertes Protokollieren](#monitor-logging-custom)
+ [Protokollieren von anwendungsspezifischen Meldungen mit dem benutzerdefinierten Skript-Logger](#monitor-logging-script)
+ [Aktivieren des Fortschrittsbalkens zum Anzeigen des Auftragsfortschritts](#monitor-logging-progress)
+ [Sicherheitskonfiguration mit Protokollierung Amazon CloudWatch](#monitor-security-config-logging)
+ [Kontinuierliche Protokollierung für Jobs der AWS Glue Version 4.0 und früher aktivieren](monitor-continuous-logging-enable.md)
+ [Protokolle für AWS Glue Jobs anzeigen](monitor-continuous-logging-view.md)
# Kontinuierliche Protokollierung für Jobs der AWS Glue Version 4.0 und früher aktivieren
**Anmerkung**
In AWS Glue 4.0 und früheren Versionen war die kontinuierliche Protokollierung eine verfügbare Funktion. Mit der Einführung von AWS Glue 5.0 können jedoch alle Jobs in Echtzeit protokolliert werden. Weitere Informationen zu den Protokollierungsfunktionen und Konfigurationsoptionen in AWS Glue 5.0 finden Sie unter [Protokollierung für AWS Glue Jobs](https://docs.aws.amazon.com/glue/latest/dg/monitor-continuous-logging.html).
Sie können die kontinuierliche Protokollierung über die AWS Glue Konsole oder über AWS Command Line Interface (AWS CLI) aktivieren.
Sie können die kontinuierliche Protokollierung aktivieren, wenn Sie einen neuen Auftrag erstellen oder einen vorhandenen Auftrag bearbeiten bzw. über die AWS CLI aktivieren.
Sie können auch benutzerdefinierte Konfigurationsoptionen wie den Namen der Amazon CloudWatch Protokollgruppe, das CloudWatch Protokollstream-Präfix vor der driver/executor ID der AWS Glue Auftragsausführung und das Protokollkonvertierungsmuster für Protokollnachrichten angeben. Diese Konfigurationen helfen Ihnen dabei, aggregierte Protokolle in benutzerdefinierten CloudWatch Protokollgruppen mit unterschiedlichen Ablaufrichtlinien einzurichten und sie mit benutzerdefinierten Logstream-Präfixen und Konvertierungsmustern weiter zu analysieren.
**Topics**
+ [Mit dem AWS-Managementkonsole](#monitor-continuous-logging-enable-console)
+ [Protokollieren von anwendungsspezifischen Meldungen mit dem benutzerdefinierten Skript-Logger](#monitor-continuous-logging-script)
+ [Aktivieren des Fortschrittsbalkens zum Anzeigen des Auftragsfortschritts](#monitor-continuous-logging-progress)
+ [Sicherheitskonfiguration mit kontinuierlicher Protokollierung](#monitor-logging-encrypt-log-data)
## Mit dem AWS-Managementkonsole
Gehen Sie wie folgt vor, um mithilfe der Konsole die kontinuierliche Protokollierung beim Erstellen oder Bearbeiten eines AWS Glue Jobs zu aktivieren.
**Um einen neuen AWS Glue Job mit kontinuierlicher Protokollierung zu erstellen**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS Glue Konsole unter [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).
1. Wählen Sie im Navigationsbereich die Option **ETL-Aufträge** aus.
1. Wählen Sie **Visual ETL**.
1. Erweitern Sie auf der Registerkarte **Auftragsdetails** den Abschnitt **Erweiterte Eigenschaften**.
1. Wählen Sie unter **Kontinuierliche Protokollierung** die Option **Anmeldungen aktivieren** aus CloudWatch.
**Um die kontinuierliche Protokollierung für einen vorhandenen AWS Glue Job zu aktivieren**
1. Öffnen Sie die AWS Glue Konsole unter [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).
1. Wählen Sie im Navigationsbereich die Option **Jobs (Aufträge)** aus.
1. Wählen Sie einen Auftrag in der Liste **Jobs (Aufträge)** aus.
1. Wählen Sie **Action (Aktion)**, **Edit job (Auftrag bearbeiten)** aus.
1. Erweitern Sie auf der Registerkarte **Auftragsdetails** den Abschnitt **Erweiterte Eigenschaften**.
1. Wählen Sie unter **Kontinuierliche Protokollierung** die Option Anmeldung **aktivieren** aus CloudWatch.
### Verwenden des AWS CLI
Um die kontinuierliche Protokollierung zu aktivieren, übergeben Sie Jobparameter an einen AWS Glue Job. Übergeben Sie die folgenden speziellen Job-Parameter, die anderen AWS Glue Job-Parametern ähneln. Weitere Informationen finden Sie unter [Verwenden von Auftragsparametern in AWS Glue-Jobs](aws-glue-programming-etl-glue-arguments.md).
```
'--enable-continuous-cloudwatch-log': 'true'
```
Sie können einen benutzerdefinierten CloudWatch Amazon-Protokollgruppennamen angeben. Sofern nicht angegeben, lautet der Standardname der Protokollgruppe `/aws-glue/jobs/logs-v2`.
```
'--continuous-log-logGroup': 'custom_log_group_name'
```
Sie können ein benutzerdefiniertes CloudWatch Amazon-Logstream-Präfix angeben. Sofern nicht angegeben, ist das standardmäßige Logstream-Präfix die Auftragsausführungs-ID.
```
'--continuous-log-logStreamPrefix': 'custom_log_stream_prefix'
```
Sie können ein benutzerdefiniertes Konvertierungsmuster für die kontinuierliche Protokollierung angeben. Sofern nicht angegeben, ist das Standardkonvertierungsmuster `%d{yy/MM/dd HH:mm:ss} %p %c{1}: %m%n`. Beachten Sie, dass das Konvertierungsmuster nur für Treiberprotokolle und Executor-Protokolle gilt. Dies wirkt sich nicht auf die AWS Glue -Fortschrittsleiste aus.
```
'--continuous-log-conversionPattern': 'custom_log_conversion_pattern'
```
## Protokollieren von anwendungsspezifischen Meldungen mit dem benutzerdefinierten Skript-Logger
Sie können den AWS Glue Logger verwenden, um alle anwendungsspezifischen Meldungen im Skript zu protokollieren, die in Echtzeit an den Treiberprotokollstream gesendet werden.
Das folgende Beispiel zeigt ein Python-Skript.
```
from awsglue.context import GlueContext
from pyspark.context import SparkContext
sc = SparkContext()
glueContext = GlueContext(sc)
logger = glueContext.get_logger()
logger.info("info message")
logger.warn("warn message")
logger.error("error message")
```
Das folgende Beispiel zeigt ein Scala-Skript.
```
import com.amazonaws.services.glue.log.GlueLogger
object GlueApp {
def main(sysArgs: Array[String]) {
val logger = new GlueLogger
logger.info("info message")
logger.warn("warn message")
logger.error("error message")
}
}
```
## Aktivieren des Fortschrittsbalkens zum Anzeigen des Auftragsfortschritts
AWS Glue bietet unter dem `JOB_RUN_ID-progress-bar` Protokollstream eine Fortschrittsleiste in Echtzeit, mit der der Status der AWS Glue Auftragsausführung überprüft werden kann. Derzeit unterstützt er nur Aufträge, die `glueContext` initialisieren. Wenn Sie einen reinen Spark-Job ohne Initialisierung ausführen`glueContext`, wird der AWS Glue Fortschrittsbalken nicht angezeigt.
Der Fortschrittsbalken wird alle 5 Sekunden aktualisiert.
```
Stage Number (Stage Name): > (numCompletedTasks + numActiveTasks) / totalNumOfTasksInThisStage]
```
## Sicherheitskonfiguration mit kontinuierlicher Protokollierung
Wenn eine Sicherheitskonfiguration für CloudWatch Protokolle aktiviert ist, AWS Glue wird eine Protokollgruppe mit dem folgenden Namen für fortlaufende Protokolle erstellt:
```
-
```
Die Standard- und benutzerdefinierten Protokollgruppen lauten wie folgt:
+ Die standardmäßige fortlaufende Protokollgruppe lautet `/aws-glue/jobs/error-`
+ Die benutzerdefinierte fortlaufende Protokollgruppe lautet `-`
Sie `logs:AssociateKmsKey` müssen Ihrer IAM-Rollenberechtigungen hinzufügen, wenn Sie eine Sicherheitskonfiguration mit CloudWatch Protokollen aktivieren. Wenn diese Berechtigung nicht enthalten ist, wird die fortlaufende Protokollierung deaktiviert. Um die Verschlüsselung für die CloudWatch Logs zu konfigurieren, folgen Sie außerdem den Anweisungen unter [Log Data in CloudWatch Logs Using verschlüsseln AWS Key Management Service](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html) im *Amazon CloudWatch Logs-Benutzerhandbuch*.
Weitere Informationen zum Erstellen einer Sicherheitskonfiguration finden Sie hier: [Verwalten von Sicherheitskonfigurationen in der AWS Glue-Konsole](console-security-configurations.md).
**Anmerkung**
Es können zusätzliche Gebühren anfallen, wenn Sie die Protokollierung aktivieren und zusätzliche CloudWatch Protokollereignisse erstellt werden. Weitere Informationen finden Sie unter [ CloudWatch Amazon-Preise](https://aws.amazon.com/cloudwatch/pricing/).
# Protokolle für AWS Glue Jobs anzeigen
Sie können Echtzeitprotokolle über die AWS Glue Konsole oder die CloudWatch Amazon-Konsole anzeigen.
**Um Echtzeitprotokolle über das AWS Glue Konsolen-Dashboard anzuzeigen**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS Glue Konsole unter [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).
1. Wählen Sie im Navigationsbereich die Option **Jobs (Aufträge)** aus.
1. Fügen Sie einen Auftrag hinzu oder starten Sie einen vorhandenen Auftrag. Wählen Sie **Action (Aktion)**, **Run job (Auftrag ausführen)** aus.
Wenn Sie einen Auftrag starten, navigieren Sie zu einer Seite mit Informationen über den laufenden Auftrag:
+ Die Registerkarte **Logs (Protokolle)** zeigt die älteren aggregierten Anwendungsprotokolle an.
+ Die Registerkarte **Protokolle** zeigt einen Echtzeit-Fortschrittsbalken an, wenn der Auftrag ausgeführt wird und `glueContext` initialisiert ist.
+ Die Registerkarte **Protokolle** enthält auch die **Treiberprotokolle**, in denen Apache Spark-Treiberprotokolle in Echtzeit erfasst werden, und Anwendungsprotokolle aus dem Skript, die mit dem AWS Glue Anwendungslogger protokolliert wurden, während der Job ausgeführt wird.
1. Für ältere Aufträge können Sie auch die Echtzeitprotokolle unter **Job History (Auftragsverlauf)** anzeigen, indem Sie **Jobs (Aufträge)** auswählen. Mit dieser Aktion gelangen Sie zu der CloudWatch Konsole, auf der alle Protokollstreams für Spark-Treiber, Executor und Fortschrittsbalken für diese Jobausführung angezeigt werden.
**Um Echtzeitprotokolle über das CloudWatch Konsolen-Dashboard anzuzeigen**
1. Öffnen Sie die CloudWatch Konsole unter [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Wählen Sie im Navigationsbereich **Log (Protokoll)** aus.
1. Wählen Sie die **Protokollgruppe /aws-glue/jobs/error/**aus.
1. Fügen Sie die Auftragsausführung-ID in das Feld **Filter** ein.
Sie können die Treiberprotokolle, die Executor-Protokolle und den Fortschrittsbalken anzeigen (wenn der **Standard filter (Standardfilter)** verwendet wird).
# Überwachung mit AWS Glue-Beobachtbarkeitsmetriken
**Anmerkung**
AWS Glue-Beobachtbarkeitsmetriken sind bei AWS Glue 4.0 und späteren Versionen verfügbar.
Nutzen Sie AWS Glue-Beobachtbarkeitsmetriken, um Einblicke in die Abläufe in AWS Glue für Apache Spark zu erhalten. So können Sie die Sichtung und Analyse von Problemen verbessern. Beobachtbarkeitsmetriken werden über Amazon CloudWatch -Dashboards visualisiert und können verwendet werden, um die Ursache von Fehlern zu analysieren und Leistungsengpässe zu diagnostizieren. Sie können den Zeitaufwand für das Debuggen von Problemen reduzieren, sodass Sie sich darauf konzentrieren können, Probleme schneller und effektiver zu lösen.
AWS GlueObservability bietet Amazon CloudWatch Metriken, die in die folgenden vier Gruppen unterteilt sind:
+ **Zuverlässigkeit (d. h. Fehlerklassen)** – Identifizieren Sie ganz einfach die häufigsten Fehlerursachen in einem bestimmten Zeitraum, die Sie möglicherweise beheben möchten.
+ **Leistung (d. h. Schiefe)** – Identifizieren Sie Leistungsengpässe und wenden Sie Optimierungsmethoden an. Wenn Sie beispielsweise Leistungseinbußen aufgrund von Auftragsschiefe feststellen, können Sie die adaptive Abfrageausführung von Spark aktivieren und den Schwellenwert für schiefe Verknüpfungen anpassen.
+ **Durchsatz (d. h. pro source/sink Durchsatz)** — Überwachen Sie Trends bei Lese- und Schreibvorgängen von Daten. Sie können auch Amazon CloudWatch Alarme für Anomalien konfigurieren.
+ **Ressourcenauslastung (d. h. Mitarbeiter, Speicher- und Festplattennutzung)** – Lokalisieren Sie Aufträge mit geringer Kapazitätsauslastung auf effiziente Weise. Für diese Aufträge kann es sinnvoll sein, AWS Glue Auto Scaling zu aktivieren.
## Erste Schritte mit AWS Glue-Beobachtbarkeitsmetriken
**Anmerkung**
Die neuen Metriken sind standardmäßig in der AWS Glue Studio-Konsole aktiviert.
**So konfigurieren Sie Beobachtbarkeitsmetriken in AWS Glue Studio:**
1. Melden Sie sich bei der AWS Glue-Konsole an und wählen Sie im Konsolenmenü die Option **ETL-Aufträge** aus.
1. Klicken Sie im Bereich **Ihre Aufträge** auf den Namen des gewünschten Auftrags.
1. Wählen Sie die Registerkarte **Job details (Auftragsdetails)** aus.
1. Scrollen Sie nach unten, wählen Sie **Erweiterte Eigenschaften** und dann **Metriken zur Auftragsbeobachtbarkeit** aus.
![\[Der Screenshot zeigt die Registerkarte „Erweiterte Eigenschaften“ in den Auftragsdetails. Die Option „Metriken zur Auftragsbeobachtbarkeit“ ist hervorgehoben.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/job-details-observability-metrics.png)
**Um AWS Glue Observability-Metriken zu aktivieren, verwenden Sie: AWS CLI**
+ Fügen Sie der `--default-arguments`-Zuordnung in der JSON-Eingabedatei den folgenden Schlüsselwert hinzu:
```
--enable-observability-metrics, true
```
## Verwenden der AWS Glue-Beobachtbarkeit
Da die AWS Glue Observability-Metriken über bereitgestellt werden Amazon CloudWatch, können Sie die Amazon CloudWatch Konsole, das SDK oder die API verwenden AWS CLI, um die Datenpunkte der Observability-Metriken abzufragen. Ein Anwendungsbeispiel für die Verwendung von AWS Glue-Beobachtbarkeitsmetriken finden Sie unter [Verwenden von Glue-Beobachtbarkeit für die Überwachung der Ressourcennutzung zur Kostensenkung](https://aws.amazon.com/blogs/big-data/enhance-monitoring-and-debugging-for-aws-glue-jobs-using-new-job-observability-metrics/).
### Observability in der Konsole verwenden AWS Glue Amazon CloudWatch
**Um Metriken in der Amazon CloudWatch Konsole abzufragen und zu visualisieren:**
1. Öffnen Sie die Amazon CloudWatch Konsole und wählen Sie **Alle Metriken** aus.
1. Wählen Sie unter „Benutzerdefinierte Namespaces“ **AWS Glue** aus.
1. Wählen Sie **„Metriken zur Auftragsbeobachtbarkeit“, „Beobachtbarkeitsmetriken pro Quelle“ oder „Beobachtbarkeitsmetriken pro Senke“** aus.
1. Suchen Sie nach dem gewünschten Metrik- und Auftragsnamen sowie der Auftragsausführungs-ID und wählen Sie sie aus.
1. Konfigurieren Sie auf der Registerkarte **Grafische Metriken** Ihre bevorzugte Statistik, den Zeitraum und andere Optionen.
![\[Der Screenshot zeigt die Amazon CloudWatch Konsole und das Metrikdiagramm.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/cloudwatch-console-metrics.png)
**Um eine Observability-Metrik abzufragen, verwenden Sie AWS CLI:**
1. Erstellen Sie eine JSON-Datei mit einer Metrikdefinition und ersetzen Sie `your-Glue-job-name` und `your-Glue-job-run-id` mit Ihren Werten.
```
$ cat multiplequeries.json
[
{
"Id": "avgWorkerUtil_0",
"MetricStat": {
"Metric": {
"Namespace": "Glue",
"MetricName": "glue.driver.workerUtilization",
"Dimensions": [
{
"Name": "JobName",
"Value": ""
},
{
"Name": "JobRunId",
"Value": ""
},
{
"Name": "Type",
"Value": "gauge"
},
{
"Name": "ObservabilityGroup",
"Value": "resource_utilization"
}
]
},
"Period": 1800,
"Stat": "Minimum",
"Unit": "None"
}
},
{
"Id": "avgWorkerUtil_1",
"MetricStat": {
"Metric": {
"Namespace": "Glue",
"MetricName": "glue.driver.workerUtilization",
"Dimensions": [
{
"Name": "JobName",
"Value": ""
},
{
"Name": "JobRunId",
"Value": ""
},
{
"Name": "Type",
"Value": "gauge"
},
{
"Name": "ObservabilityGroup",
"Value": "resource_utilization"
}
]
},
"Period": 1800,
"Stat": "Minimum",
"Unit": "None"
}
}
]
```
1. Führen Sie den Befehl `get-metric-data` aus:
```
$ aws cloudwatch get-metric-data --metric-data-queries file: //multiplequeries.json \
--start-time '2023-10-28T18: 20' \
--end-time '2023-10-28T19: 10' \
--region us-east-1
{
"MetricDataResults": [
{
"Id": "avgWorkerUtil_0",
"Label": "",
"Timestamps": [
"2023-10-28T18:20:00+00:00"
],
"Values": [
0.06718750000000001
],
"StatusCode": "Complete"
},
{
"Id": "avgWorkerUtil_1",
"Label": "",
"Timestamps": [
"2023-10-28T18:50:00+00:00"
],
"Values": [
0.5959183673469387
],
"StatusCode": "Complete"
}
],
"Messages": []
}
```
## Beobachtbarkeitsmetriken
AWS GlueObservability erstellt Profile und sendet die folgenden Metriken Amazon CloudWatch alle 30 Sekunden. Einige dieser Metriken können auf der Seite „AWS Glue StudioJob Runs Monitoring“ angezeigt werden.
| Metrik | Description | Kategorie |
| --- | --- | --- |
| glue.driver.skewness.stage | Metrikkategorie: job\$1performance Ausführungsschiefe von Spark-Phasen: Diese Metrik gibt an, wie lange die maximale Aufgabendauer in einer bestimmten Phase im Vergleich zur mittleren Aufgabendauer in dieser Phase ist. Diese Metrik erfasst Abweichungen bei der Ausführung, die durch schiefe Eingabedaten oder durch eine Transformation (z. B. schiefe Verknüpfung) verursacht werden. Die Werte dieser Metrik fallen in den Bereich [0, unendlich[, wobei 0 bedeutet, dass der Unterschied zwischen der maximalen und der mittleren Ausführungszeit von Aufgaben in der Phase weniger beträgt als ein bestimmter Phasenabweichungsfaktor. Der Standardschiefefaktor von Phasen ist „5“ und kann mit dieser Spark-Konfiguration überschrieben werden: spark.metrics.conf.driver.source.glue.jobPerformance.skewnessFactor Ein Wert von 1 für die Phasenabweichung bedeutet, dass der Unterschied das Doppelte des Abweichungsfaktors der Phase beträgt. Der Wert für die Phasenschiefe wird alle 30 Sekunden aktualisiert, um die aktuelle Schiefe widerzuspiegeln. Der Wert am Ende der Phase spiegelt die finale Schiefe der Phase wider. Diese Metrik auf Stufenebene wird verwendet, um die Metrik auf Auftragsebene `glue.driver.skewness.job` zu berechnen. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID oder ALL), Typ (Gauge) und ObservabilityGroup (job\$1performance) Gültige Statistiken: Durchschnitt, Maximum, Minimum, Prozent Einheit: Anzahl | job\$1performance |
| glue.driver.skewness.job | Metrikkategorie: job\$1performance Die Auftragsschiefe ist das Maximum der gewichteten Schiefe aller Phasen. Die Schiefe der Phase (glue.driver.skewness.stage) wird mit der Dauer der Phase gewichtet. Auf diese Weise soll der Ausnahmefall vermieden werden, bei dem eine stark schiefe Phase im Vergleich zu anderen Phasen tatsächlich nur für eine sehr kurze Zeit ausgeführt wird (und ihre Abweichung daher für die gesamte Auftragsleistung nicht signifikant ist und es sich nicht lohnt, diese Abweichung zu beheben). Diese Metrik wird nach Abschluss jeder Phase aktualisiert, sodass der letzte Wert die tatsächliche Gesamtabweichung des Auftrags widerspiegelt. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID oder ALL), Typ (Gauge) und ObservabilityGroup (job\$1performance) Gültige Statistiken: Durchschnitt, Maximum, Minimum, Prozent Einheit: Anzahl | job\$1performance |
| glue.succeed.ALL | Metrikkategorie: Fehler Gesamtzahl der erfolgreichen Auftragsausführungen, für ein vollständiges Bild der Fehlerkategorien Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID oder ALL), Typ (Anzahl) und ObservabilityGroup (Fehler) Gültige Statistiken: SUM Einheit: Anzahl | error |
| glue.error.ALL | Metrikkategorie: Fehler Gesamtzahl der Fehler bei Auftragsausführungen, für ein vollständiges Bild der Fehlerkategorien Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID oder ALL), Typ (Anzahl) und ObservabilityGroup (Fehler) Gültige Statistiken: SUM Einheit: Anzahl | error |
| glue.error.[Fehlerkategorie] | Metrikkategorie: Fehler Dabei handelt es sich um eine Reihe von Metriken, die nur aktualisiert werden, wenn eine Auftragsausführung fehlschlägt. Die Fehlerkategorisierung hilft bei der Analyse und dem Debugging. Wenn eine Auftragsausführung fehlschlägt, wird der Fehler, der dazu geführt hat, kategorisiert und die entsprechende Metrik für die Fehlerkategorie wird auf 1 gesetzt. Dies hilft bei der Durchführung von Fehleranalysen im Zeitverlauf sowie bei der Fehleranalyse für alle Jobs, um die häufigsten Fehlerkategorien zu identifizieren und sie zu beheben. AWS Glue hat 28 Fehlerkategorien, darunter OUT\$1OF\$1MEMORY (Treiber und Executor), PERMISSION, SYNTAX und THROTTLING. Weitere Fehlerkategorien sind unter anderem COMPILATION, LAUNCH und TIMEOUT. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID oder ALL), Typ (Anzahl) und ObservabilityGroup (Fehler) Gültige Statistiken: SUM Einheit: Anzahl | error |
| glue.driver.workerUtilization | Metrikkategorie: resource\$1utilization Der Prozentsatz der zugewiesenen Arbeitskräfte, die tatsächlich eingesetzt werden. Wenn nicht gut, kann Auto Scaling helfen. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt, Maximum, Minimum, Prozent Einheit: Prozentsatz | resource\$1utilization |
| glue.driver.memory.heap.[verfügbar \$1 belegt] | Metrikkategorie: resource\$1utilization Der verfügbare/belegte Heap-Speicher des Treibers während der Auftragsausführung. Dies hilft, Trends bei der Speichernutzung zu verstehen, insbesondere im Zeitverlauf, wodurch potenzielle Ausfälle vermieden werden. Außerdem können Ausfälle im Zusammenhang mit Speicher behoben werden. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Byte | resource\$1utilization |
| glue.driver.memory.heap.used.percentage | Metrikkategorie: resource\$1utilization Der belegte Heap-Speicher des Treibers während der Auftragsausführung (in %). Dies hilft, Trends bei der Speichernutzung zu verstehen, insbesondere im Zeitverlauf, wodurch potenzielle Ausfälle vermieden werden. Außerdem können Ausfälle im Zusammenhang mit Speicher behoben werden. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Prozentsatz | resource\$1utilization |
| glue.driver.memory.non-heap.[verfügbar \$1 belegt] | Metrikkategorie: resource\$1utilization Der verfügbare/belegte Non-Heap-Speicher des Treibers während der Auftragsausführung. Dies hilft, Trends bei der Speichernutzung zu verstehen, insbesondere im Zeitverlauf, wodurch potenzielle Ausfälle vermieden werden. Außerdem können Ausfälle im Zusammenhang mit Speicher behoben werden. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Byte | resource\$1utilization |
| glue.driver.memory.non-heap.used.percentage | Metrikkategorie: resource\$1utilization Der belegte Non-Heap-Speicher des Treibers während der Auftragsausführung (in %). Dies hilft, Trends bei der Speichernutzung zu verstehen, insbesondere im Zeitverlauf, wodurch potenzielle Ausfälle vermieden werden. Außerdem können Ausfälle im Zusammenhang mit Speicher behoben werden. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Prozentsatz | resource\$1utilization |
| glue.driver.memory.total.[verfügbar \$1 belegt] | Metrikkategorie: resource\$1utilization Der verfügbare/belegte Gesamtspeicher des Treibers während der Auftragsausführung. Dies hilft, Trends bei der Speichernutzung zu verstehen, insbesondere im Zeitverlauf, wodurch potenzielle Ausfälle vermieden werden. Außerdem können Ausfälle im Zusammenhang mit Speicher behoben werden. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Byte | resource\$1utilization |
| glue.driver.memory.total.used.percentage | Metrikkategorie: resource\$1utilization Der belegte Gesamtspeicher des Treibers während der Auftragsausführung (in %). Dies hilft, Trends bei der Speichernutzung zu verstehen, insbesondere im Zeitverlauf, wodurch potenzielle Ausfälle vermieden werden. Außerdem können Ausfälle im Zusammenhang mit Speicher behoben werden. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Prozentsatz | resource\$1utilization |
| glue.ALL.memory.heap.[verfügbar \$1 belegt] | Metrikkategorie: resource\$1utilization Der Heap-Speicher der Executoren. available/used ALL bedeutet alle Executoren. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Byte | resource\$1utilization |
| glue.ALL.memory.heap.used.percentage | Metrikkategorie: resource\$1utilization Der belegte Heap-Speicher der Executoren (in %). ALL bedeutet alle Executoren. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Prozentsatz | resource\$1utilization |
| glue.ALL.memory.non-heap.[verfügbar \$1 belegt] | Metrikkategorie: resource\$1utilization Der Non-Heap-Speicher der Executoren. available/used ALL bedeutet alle Executoren. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Byte | resource\$1utilization |
| glue.ALL.memory.non-heap.used.percentage | Metrikkategorie: resource\$1utilization Der belegte Non-Heap-Speicher der Executoren (in %). ALL bedeutet alle Executoren. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Prozentsatz | resource\$1utilization |
| glue.ALL.memory.total.[verfügbar \$1 belegt] | Metrikkategorie: resource\$1utilization Der gesamte Arbeitsspeicher der Executer. available/used ALL bedeutet alle Executoren. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Byte | resource\$1utilization |
| glue.ALL.memory.total.used.percentage | Metrikkategorie: resource\$1utilization Der belegte Gesamtspeicher der Executoren (in %). ALL bedeutet alle Executoren. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Prozentsatz | resource\$1utilization |
| glue.driver.disk.[available\$1GB \$1 used\$1GB] | Metrikkategorie: resource\$1utilization Der available/used Festplattenspeicher des Treibers während der Ausführung des Jobs. Dies hilft, Trends bei der Festplattennutzung zu verstehen, insbesondere im Zeitverlauf, wodurch potenzielle Ausfälle vermieden werden. Außerdem können Ausfälle im Zusammenhang mit zu wenig Festplattenspeicher behoben werden. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Gigabyte | resource\$1utilization |
| glue.driver.disk.used.percentage] | Metrikkategorie: resource\$1utilization Der available/used Festplattenspeicher des Treibers während der Ausführung des Jobs. Dies hilft, Trends bei der Festplattennutzung zu verstehen, insbesondere im Zeitverlauf, wodurch potenzielle Ausfälle vermieden werden. Außerdem können Ausfälle im Zusammenhang mit zu wenig Festplattenspeicher behoben werden. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Prozentsatz | resource\$1utilization |
| glue.ALL.disk.[available\$1GB \$1 used\$1GB] | Metrikkategorie: resource\$1utilization Der Festplattenspeicher der Executoren. available/used ALL bedeutet alle Executoren. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Gigabyte | resource\$1utilization |
| glue.ALL.disk.used.percentage | Metrikkategorie: resource\$1utilization Der Festplattenspeicher (%) der Executorenavailable/used/used. ALL bedeutet alle Executoren. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Prozentsatz | resource\$1utilization |
| glue.driver.bytesRead | Metrikkategorie: Durchsatz Die Anzahl der in dieser Auftragsausführung pro Eingabequelle sowie für ALL-Quellen gelesenen Byte. Dies hilft, das Datenvolumen und seine Veränderungen im Laufe der Zeit besser zu verstehen und Probleme wie Datenabweichungen zu lösen. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID oder ALL), Type (Gauge), ObservabilityGroup (resource\$1utilization) und Source (Quelldatenposition) Gültige Statistiken: Durchschnitt Einheit: Byte | Durchsatz |
| glue.driver.[recordsRead \$1 filesRead] | Metrikkategorie: Durchsatz Die Anzahl der records/files Lesevorgänge pro Eingabequelle in dieser Auftragsausführung sowie für ALLE Quellen. Dies hilft, das Datenvolumen und seine Veränderungen im Laufe der Zeit besser zu verstehen und Probleme wie Datenabweichungen zu lösen. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID oder ALL), Type (Gauge), ObservabilityGroup (resource\$1utilization) und Source (Quelldatenposition) Gültige Statistiken: Durchschnitt Einheit: Anzahl | Durchsatz |
| glue.driver.partitionsRead | Metrikkategorie: Durchsatz Die Anzahl der in dieser Auftragsausführung pro Amazon-S3-Eingabequelle sowie für ALL-Quellen gelesenen Partitionen. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID oder ALL), Type (Gauge), ObservabilityGroup (resource\$1utilization) und Source (Quelldatenposition) Gültige Statistiken: Durchschnitt Einheit: Anzahl | Durchsatz |
| glue.driver.bytesWritten | Metrikkategorie: Durchsatz Die Anzahl der in dieser Auftragsausführung pro Ausgabe-Sink sowie für ALL-Sinks geschriebenen Byte. Dies hilft, das Datenvolumen und seine Entwicklung im Laufe der Zeit besser zu verstehen und Probleme wie Verarbeitungsabweichungen zu lösen. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID oder ALL), Type (Gauge), ObservabilityGroup (resource\$1utilization) und Sink (Speicherort der Senkendaten) Gültige Statistiken: Durchschnitt Einheit: Byte | Durchsatz |
| glue.driver.[recordsWritten \$1 filesWritten] | Metrikkategorie: Durchsatz Die Anzahl der records/files Schreibvorgänge pro Ausgabesenke in dieser Auftragsausführung sowie für ALLE Senken. Dies hilft, das Datenvolumen und seine Entwicklung im Laufe der Zeit besser zu verstehen und Probleme wie Verarbeitungsabweichungen zu lösen. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID oder ALL), Type (Gauge), ObservabilityGroup (resource\$1utilization) und Sink (Speicherort der Senkendaten) Gültige Statistiken: Durchschnitt Einheit: Anzahl | Durchsatz |
## Fehlerkategorien
| Fehlerkategorien | Description |
| --- | --- |
| COMPILATION\$1ERROR | Bei der Kompilierung von Scala-Code treten Fehler auf. |
| CONNECTION\$1ERROR | Beim Herstellen einer Verbindung zu einem service/remote Host-/Datenbankdienst usw. treten Fehler auf. |
| DISK\$1NO\$1SPACE\$1ERROR | Wenn auf der Festplatte des Treibers/Executors kein Speicherplatz mehr vorhanden ist, treten Fehler auf. |
| OUT\$1OF\$1MEMORY\$1ERROR | Wenn auf dem Speicher des Treibers/Executors kein Speicherplatz mehr vorhanden ist, treten Fehler auf. |
| IMPORT\$1ERROR | Beim Import von Abhängigkeiten treten Fehler auf. |
| INVALID\$1ARGUMENT\$1ERROR | Wenn die Eingabeargumente ungültig/illegal sind, treten Fehler auf. |
| PERMISSION\$1ERROR | Wenn die Genehmigung für Services, Daten usw. fehlt, treten Fehler auf. |
| RESOURCE\$1NOT\$1FOUND\$1ERROR | Wenn Daten, Speicherorte usw. nicht existieren, treten Fehler auf. |
| QUERY\$1ERROR | Bei der Ausführung von Spark-SQL-Abfragen treten Fehler auf. |
| SYNTAX\$1ERROR | Wenn das Skript einen Syntaxfehler enthält, treten Fehler auf. |
| THROTTLING\$1ERROR | Wenn die Beschränkung der Parallelität von Services erreicht oder die Beschränkung der Service Quotas überschritten wird, treten Fehler auf. |
| DATA\$1LAKE\$1FRAMEWORK\$1ERROR | Aufgrund von nativ AWS Glue-unterstützten Data-Lake-Frameworks wie Hudi, Iceberg usw. treten Fehler auf. |
| UNSUPPORTED\$1OPERATION\$1ERROR | Wenn ein Vorgang ausgeführt wird, der nicht unterstützt wird, treten Fehler auf. |
| RESOURCES\$1ALREADY\$1EXISTS\$1ERROR | Wenn eine Ressource, die erstellt oder hinzugefügt werden soll, bereits vorhanden ist, treten Fehler auf. |
| GLUE\$1INTERNAL\$1SERVICE\$1ERROR | Wenn ein internes Problem mit dem AWS Glue-Service vorliegt, treten Fehler auf. |
| GLUE\$1OPERATION\$1TIMEOUT\$1ERROR | Wenn bei einem AWS Glue-Vorgang eine Zeitüberschreitung eintritt, treten Fehler auf. |
| GLUE\$1VALIDATION\$1ERROR | Wenn ein erforderlicher Wert nicht für den AWS Glue-Auftrag validiert werden konnte, treten Fehler auf. |
| GLUE\$1JOB\$1BOOKMARK\$1VERSION\$1MISMATCH\$1ERROR | Fehler treten auf, wenn derselbe Job denselben Quell-Bucket exoniert und gleichzeitig in das same/different Ziel schreibt (Parallelität >1) |
| LAUNCH\$1ERROR | Während der Startphase des AWS Glue-Auftrags treten Fehler auf. |
| DYNAMODB\$1ERROR | Generische Fehler entstehen durch den Service. Amazon DynamoDB |
| GLUE\$1ERROR | Der AWS Glue-Service ruft generische Fehler hervor. |
| LAKEFORMATION\$1ERROR | Generische Fehler entstehen durch AWS Lake Formation den Service. |
| REDSHIFT\$1ERROR | Generische Fehler entstehen durch Amazon Redshift den Service. |
| S3\$1ERROR | Der Amazon–S3-Service ruft generische Fehler hervor. |
| SYSTEM\$1EXIT\$1ERROR | Generischer Fehler beim Beenden des Systems. |
| TIMEOUT\$1ERROR | Wenn der Auftrag aufgrund eines Timeouts fehlschlägt, treten generische Fehler auf. |
| UNCLASSIFIED\$1SPARK\$1ERROR | Spark ruft generische Fehler hervor. |
| UNCLASSIFIED\$1ERROR | Standard-Fehlerkategorie. |
## Einschränkungen
**Anmerkung**
`glueContext` muss initialisiert werden, um die Metriken zu veröffentlichen.
In der Quelldimension ist der Wert je nach Quelltyp entweder ein Amazon-S3-Pfad oder Tabellenname. Wenn es sich bei der Quelle um JDBC handelt und die Abfrageoption verwendet wird, wird die Abfragezeichenfolge außerdem in der Quelldimension festgelegt. Wenn der Wert länger als 500 Zeichen ist, wird er auf 500 Zeichen gekürzt. Für den Wert gelten folgende Einschränkungen:
+ Nicht-ASCII-Zeichen werden entfernt.
+ Wenn der Quellname kein ASCII-Zeichen enthält, wird er in umgewandelt.
### Einschränkungen und Überlegungen zu Durchsatzmetriken
+ DataFrame und DataFrame based DynamicFrame (z. B. JDBC, Lesen von Parquet auf Amazon S3) werden unterstützt, RDD-basiert DynamicFrame (z. B. Lesen von CSV, JSON auf Amazon S3 usw.) wird jedoch nicht unterstützt. Technisch gesehen werden alle Lese- und Schreibvorgänge, die auf der Spark-Benutzeroberfläche sichtbar sind, unterstützt.
+ Die `recordsRead`-Metrik wird ausgegeben, wenn es sich bei der Datenquelle um eine Katalogtabelle handelt und das Format JSON, CSV, Text oder Iceberg ist.
+ Die Metriken `glue.driver.throughput.recordsWritten`, `glue.driver.throughput.bytesWritten` und `glue.driver.throughput.filesWritten` sind in JDBC- und Iceberg-Tabellen nicht verfügbar.
+ Metriken können verzögert sein. Wenn der Job in etwa einer Minute abgeschlossen ist, gibt es unter Metrics möglicherweise keine Durchsatzmetriken. Amazon CloudWatch
# Auftragsüberwachung und Debugging
Sie können Kennzahlen zu AWS Glue Jobs sammeln und diese auf den CloudWatch Konsolen AWS Glue und Amazon visualisieren, um Probleme zu identifizieren und zu beheben. Die Profilierung Ihrer AWS Glue-Aufträge erfordert die folgenden Schritte:
1. Metriken aktivieren:
1. Aktivieren der Option **Job metrics (Auftragsmetriken)** in der Auftragsdefinition. Sie können die Profilierung in der AWS Glue-Konsole oder als Parameter für den Auftrag aktivieren. Weitere Informationen finden Sie unter [Definieren von Auftragseigenschaften für Spark-Aufträge](add-job.md#create-job) oder [Verwenden von Auftragsparametern in AWS Glue-Jobs](aws-glue-programming-etl-glue-arguments.md).
1. Aktivieren der Option **AWS Glue-Beobachtbarkeitsmetriken** in der Auftragsdefinition. Sie können die Beobachtbarkeit in der AWS Glue-Konsole oder als Parameter für den Auftrag aktivieren. Weitere Informationen finden Sie unter [Überwachung mit AWS Glue-Beobachtbarkeitsmetriken](monitor-observability.md).
1. Vergewissern Sie sich, dass das Auftragsskript einen `GlueContext` initialisiert. Beispiel: Der folgende Skriptausschnitt initialisiert einen `GlueContext` und zeigt, wo der profilierte Code im Skript platziert wird. Dieses allgemeine Format wird in den folgenden Debugging-Szenarien verwendet.
```
import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job
import time
## @params: [JOB_NAME]
args = getResolvedOptions(sys.argv, ['JOB_NAME'])
sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args['JOB_NAME'], args)
...
...
code-to-profile
...
...
job.commit()
```
1. Führen Sie den Auftrag aus.
1. Metriken visualisieren:
1. Sie können die Auftragsmetriken in der AWS Glue-Konsole visualisieren und abnormale Metriken des Treibers oder Executors identifizieren.
1. Überprüfen Sie die Messwerte zur Beobachtbarkeit auf der Seite zur Überwachung von Jobläufen, auf der Seite mit den Details zur Jobausführung oder bei Amazon CloudWatch. Weitere Informationen finden Sie unter [Überwachung mit AWS Glue-Beobachtbarkeitsmetriken](monitor-observability.md).
1. Grenzen Sie die Ursache mithilfe der identifizierten Metrik ein.
1. Optional bestätigen Sie die Ursache mithilfe des Protokollstreams des identifizierten Treibers oder Auftrags-Executors.
**Anwendungsfälle für AWS Glue-Beobachtbarkeitsmetriken**
+ [Debuggen von OOM-Ausnahmen und Auftragsabweichungen](monitor-profile-debug-oom-abnormalities.md)
+ [Debugging von anspruchsvolle Phasen und Straggler-Aufgaben](monitor-profile-debug-straggler.md)
+ [Überwachen des Fortschritts mehrerer Aufträge](monitor-debug-multiple.md)
+ [Überwachung für die DPU-Kapazitätsplanung](monitor-debug-capacity.md)
+ [ Verwenden der AWS Glue-Beobachtbarkeit zur Überwachung der Ressourcennutzung zur Kostensenkung ](https://aws.amazon.com/blogs/big-data/enhance-monitoring-and-debugging-for-aws-glue-jobs-using-new-job-observability-metrics)
# Debuggen von OOM-Ausnahmen und Auftragsabweichungen
Sie können Ausnahmen und Jobanomalien in out-of-memory (OOM) debuggen. AWS Glue In den folgenden Abschnitten werden Szenarien für das Debuggen von out-of-memory Ausnahmen des Apache Spark-Treibers oder eines Spark-Executors beschrieben.
+ [Debuggen einer OOM-Ausnahme für einen Treiber](#monitor-profile-debug-oom-driver)
+ [Debuggen einer OOM-Ausnahme eines Executors](#monitor-profile-debug-oom-executor)
## Debuggen einer OOM-Ausnahme für einen Treiber
In diesem Szenario liest ein Spark-Auftrag eine große Anzahl von kleinen Dateien von Amazon Simple Storage Service (Amazon S3). Er wandelt die Dateien in das Apache-Parquet-Format um und schreibt sie in Amazon S3. Der Spark-Treiber verfügt nicht mehr über genügend Arbeitsspeicher. Die eingegebenen Amazon-S3-Daten umfassen mehr als 1 Million Dateien in verschiedenen Amazon-S3-Partitionen.
Der profilierte Code sieht wie folgt aus:
```
data = spark.read.format("json").option("inferSchema", False).load("s3://input_path")
data.write.format("parquet").save(output_path)
```
### Visualisieren Sie die profilierten Metriken auf der Konsole AWS Glue
Das folgende Diagramm zeigt die Speicherauslastung als Prozentsatz für den Treiber und Executors. Diese Nutzung wird als ein Datenpunkt dargestellt, gemittelt über die Werte in der letzten Minute. Sie sehen im Speicherprofil des Auftrags, dass der [Speicher für den Treiber](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.jvm.heap.usage) die sichere Schwelle von 50 Prozent Auslastung schnell überschreitet. Zum anderen ist die [durchschnittliche Speicherauslastung](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.usage) für alle Executors nach wie vor kleiner als 4 Prozent. Dies zeigt deutlich Anomalien bei der Treiberausführung in diesem Spark-Auftrag.
![\[Die Speichernutzung in Prozent für den Treiber und Executors.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-memoryprofile.png)
Die Auftragsausführung schlägt schnell fehl und der folgende Fehler wird in der AWS Glue-Konsole auf der Registerkarte **History (Verlauf)** angezeigt: Command Failed mit Exit Code 1 (Fehler mit Exit-Code 1 fehlgeschlagen). Diese Fehlermeldung bedeutet, dass der Auftrag aufgrund eines systemischen Fehlers fehlgeschlagen ist. In diesem Fall steht dem Treiber nicht genügend Arbeitsspeicher zur Verfügung.
![\[Die Fehlermeldung auf der AWS Glue-Konsole.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-errorstring.png)
Wählen Sie auf der Konsole auf der Registerkarte **Verlauf** den Link **Fehlerprotokolle** aus, um zu bestätigen, dass Sie in den CloudWatch Protokollen den Treiber-OOM gefunden haben. Suchen Sie in den Fehlerprotokollen des Auftrags nach "**Error**" (Fehler), um zu bestätigen, dass es tatsächlich eine OOM-Ausnahme war, aufgrund derer der Auftrag fehlgeschlagen ist:
```
# java.lang.OutOfMemoryError: Java heap space
# -XX:OnOutOfMemoryError="kill -9 %p"
# Executing /bin/sh -c "kill -9 12039"...
```
Wählen Sie auf der Registerkarte **History (Verlauf)** für den Auftrag die Option **Logs (Protokolle)**. Zu Beginn des Jobs finden Sie in den CloudWatch Protokollen den folgenden Verlauf der Treiberausführung. Der Spark-Treiber versucht, alle Dateien in allen Verzeichnissen aufzulisten, erzeugt einen `InMemoryFileIndex` und startet eine Aufgabe pro Datei. Dies wiederum führt dazu, dass der Spark-Treiber eine große Datenmenge im Arbeitsspeicher halten muss, um den Status aller Aufgaben zu verfolgen. Er speichert die vollständige Liste einer großen Anzahl von Dateien für den In-Memory-Index im Cache, was zu einem OOM-Fehler für den Treiber führt.
### Korrigieren Sie die Verarbeitung von mehreren Dateien unter Verwendung einer Gruppierung
Sie können die Verarbeitung mehrerer Dateien korrigieren, indem Sie die *Gruppierungsfeature* in AWS Glue anwenden. Die Gruppierung wird automatisch aktiviert, wenn Sie dynamische Frames verwenden und wenn das Eingabe-Dataset eine große Anzahl von Dateien (mehr als 50.000) enthält. Die Gruppierung ermöglicht es Ihnen, mehrere Dateien zu einer Gruppe zusammenzufassen, und erlaubt es einer Aufgabe, die gesamte Gruppe statt einer einzelnen Datei zu bearbeiten. Infolgedessen speichert der Spark-Treiber deutlich weniger Status im Speicher, um weniger Aufgaben zu verfolgen. Weitere Informationen zum manuellen Aktivieren der Gruppierung für Ihre Datasets finden Sie unter [Zusammenfassen von Eingabedateien in größeren Gruppen beim Lesen](grouping-input-files.md).
Um das Speicherprofil des AWS Glue-Auftrags zu überprüfen, müssen Sie den folgenden Code mit aktivierter Gruppierung profilieren:
```
df = glueContext.create_dynamic_frame_from_options("s3", {'paths': ["s3://input_path"], "recurse":True, 'groupFiles': 'inPartition'}, format="json")
datasink = glueContext.write_dynamic_frame.from_options(frame = df, connection_type = "s3", connection_options = {"path": output_path}, format = "parquet", transformation_ctx = "datasink")
```
Sie können das Speicherprofil und die ETL-Datenbewegung im AWS Glue-Auftragsprofil überwachen.
Der Treiber wird über die gesamte Laufzeit des AWS Glue-Auftrags unterhalb der Schwelle von 50 Prozent Speicherverbrauch ausgeführt. Die Executors streamen die Daten von Amazon S3, verarbeiten sie und schreiben sie in Amazon S3. Dadurch verbrauchen sie zu jedem Zeitpunkt weniger als 5 Prozent Speicherplatz.
![\[Das Speicherprofil zeigt, dass das Problem behoben ist.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-memoryprofile-fixed.png)
Das folgende Datenbewegungsprofil zeigt die Gesamtzahl der Amazon-S3-Bytes, die beim Auftragsfortschritt in der letzten Minute von allen Executors [gelesen](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.read_bytes) und [geschrieben](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.write_bytes) wurden. Beide folgen einem ähnlichen Muster, da die Daten über alle Executors gestreamt werden. Der Auftrag verarbeitet alle eine Million Dateien in weniger als drei Stunden.
![\[Das Datenbewegungsprofil zeigt, dass das Problem behoben ist.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-etlmovement.png)
## Debuggen einer OOM-Ausnahme eines Executors
In diesem Szenario erfahren Sie, wie Sie OOM-Ausnahmen debuggen, die in Apache Spark Executors auftreten können. Der folgende Code verwendet den Spark MySQL-Reader, um eine große Tabelle mit etwa 34 Millionen Zeilen in einen Spark DataFrame einzulesen. Anschließend schreibt es ihn im Parquet-Format in Amazon S3. Sie können die Verbindungseigenschaften angeben und die Standardkonfigurationen von Spark verwenden, um die Tabelle zu lesen.
```
val connectionProperties = new Properties()
connectionProperties.put("user", user)
connectionProperties.put("password", password)
connectionProperties.put("Driver", "com.mysql.jdbc.Driver")
val sparkSession = glueContext.sparkSession
val dfSpark = sparkSession.read.jdbc(url, tableName, connectionProperties)
dfSpark.write.format("parquet").save(output_path)
```
### Visualisieren der profilierten Metriken auf der AWS Glue-Konsole
Wenn die Steigung des Speicherauslastungsdiagramms positiv ist und 50 Prozent überschreitet und der Auftrag fehlschlägt, bevor die nächste Metrik ausgegeben wird, wird dies wahrscheinlich durch aufgebrauchten Speicher verursacht. Das folgende Diagramm zeigt, dass innerhalb einer Minute der Ausführung die [durchschnittliche Speicherauslastung](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.usage) in allen Executors schnell über 50 Prozent steigt. Die Nutzung erreicht bis zu 92 Prozent und der Container, der den Executor ausführt, wird von Apache Hadoop YARN beendet.
![\[Die durchschnittliche Speicherauslastung in allen Executors.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-2-memoryprofile.png)
Wie die folgende Grafik zeigt, wird immer ein [einzelner Executor](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberAllExecutors) ausgeführt, bis der Auftrag fehlschlägt. Dies liegt daran, dass ein neuer Executor gestartet wird, um den beendeten Executor zu ersetzen. Die Lesevorgänge der JDBC-Datenquelle sind standardmäßig nicht parallelisiert, da dies eine Partitionierung der Tabelle für eine Spalte und das Öffnen mehrerer Verbindungen erforderlich machen würde. Dies bewirkt, dass nur ein Executor die vollständige Tabelle sequenziell liest.
![\[Die Auftragsausführung zeigt, dass ein einzelner Executor aktiv ist, bis der Auftrag fehlschlägt.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-2-execution.png)
Wie die folgende Grafik zeigt, versucht Spark viermal, eine neue Aufgabe zu starten, bevor der Auftrag fehlschlägt. Sie sehen das [Speicherprofil](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.used) von drei Executors. Jeder Executor verbraucht schnell seinen gesamten Arbeitsspeicher. Der vierte Executor hat nicht mehr genügend Speicherplatz, und der Auftrag schlägt fehl. Aus diesem Grund wird die Metrik nicht sofort gemeldet.
![\[Die Speicherprofile der Executors.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-2-exec-memprofile.png)
Sie können anhand der Fehlerzeichenfolge auf der AWS Glue-Konsole bestätigen, dass der Auftrag aufgrund von OOM-Ausnahmen fehlgeschlagen ist, wie im folgenden Bild gezeigt.
![\[Die Fehlermeldung auf der AWS Glue-Konsole.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-2-errorstring.png)
**Jobausgabeprotokolle:** Weitere Informationen zur Bestätigung Ihrer Feststellung einer Executor-OOM-Ausnahme finden Sie in den CloudWatch Protokollen. Wenn Sie nach **Error** suchen, finden Sie zuerst die vier Executors, die etwa in denselben Zeitfenstern beendet wurden, wie auf dem Metriken-Dashboard gezeigt. Alle werden von YARN beendet, wenn sie ihre Speicherlimits überschreiten.
Executor 1
```
18/06/13 16:54:29 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:54:29 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:54:29 ERROR YarnClusterScheduler: Lost executor 1 on ip-10-1-2-175.ec2.internal: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:54:29 WARN TaskSetManager: Lost task 0.0 in stage 0.0 (TID 0, ip-10-1-2-175.ec2.internal, executor 1): ExecutorLostFailure (executor 1 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
```
Executor 2
```
18/06/13 16:55:35 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:55:35 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:55:35 ERROR YarnClusterScheduler: Lost executor 2 on ip-10-1-2-16.ec2.internal: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:55:35 WARN TaskSetManager: Lost task 0.1 in stage 0.0 (TID 1, ip-10-1-2-16.ec2.internal, executor 2): ExecutorLostFailure (executor 2 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
```
Executor 3
```
18/06/13 16:56:37 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:56:37 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:56:37 ERROR YarnClusterScheduler: Lost executor 3 on ip-10-1-2-189.ec2.internal: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:56:37 WARN TaskSetManager: Lost task 0.2 in stage 0.0 (TID 2, ip-10-1-2-189.ec2.internal, executor 3): ExecutorLostFailure (executor 3 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
```
Executor 4
```
18/06/13 16:57:18 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:57:18 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:57:18 ERROR YarnClusterScheduler: Lost executor 4 on ip-10-1-2-96.ec2.internal: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:57:18 WARN TaskSetManager: Lost task 0.3 in stage 0.0 (TID 3, ip-10-1-2-96.ec2.internal, executor 4): ExecutorLostFailure (executor 4 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
```
### Korrigieren der Einstellung der Abrufgröße unter Verwendung dynamischer AWS Glue-Frames
Der Executor hatte beim Lesen der JDBC-Tabelle keinen Speicher mehr zur Verfügung, da die Standardkonfiguration für die Spark JDBC-Abrufgröße Null ist. Dies bedeutet, dass der JDBC-Treiber auf dem Spark Executor versucht, die 34 Millionen Zeilen aus der Datenbank zusammen abzurufen und zwischenzuspeichern, obwohl Spark die Zeilen einzeln durchläuft. Mit Spark können Sie dieses Szenario zu vermeiden, indem Sie den Parameter für die Abrufgröße auf einen Standardwert ungleich Null setzen.
Sie können dieses Problem auch beheben, indem Sie stattdessen dynamische AWS Glue-Frames verwenden. Dynamische Frames verwenden standardmäßig eine Abrufgröße von 1.000 Zeilen. Dieser Wert ist in der Regel ausreichend. Dies bewirkt, dass der Executor nicht mehr als 7 Prozent des gesamten Speichers verbraucht. Der AWS Glue-Auftrag wird in weniger als zwei Minuten mit nur einem einzigen Executor ausgeführt. Dies wird während die Verwendung von dynamischen Frames von AWS Glue als Ansatz empfohlen. Es ist aber auch möglich, eine Abrufgröße mit der Apache-Spark-Eigenschaft `fetchsize` festzulegen. Weitere Informationen finden Sie im [Spark SQL DataFrames and Datasets Guide](https://spark.apache.org/docs/2.2.0/sql-programming-guide.html#jdbc-to-other-databases).
```
val (url, database, tableName) = {
("jdbc_url", "db_name", "table_name")
}
val source = glueContext.getSource(format, sourceJson)
val df = source.getDynamicFrame
glueContext.write_dynamic_frame.from_options(frame = df, connection_type = "s3", connection_options = {"path": output_path}, format = "parquet", transformation_ctx = "datasink")
```
**Normal profilierte Metriken:** Der [Executor-Speicher](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.usage) mit dynamischen AWS Glue-Frames übersteigt nie den sicheren Schwellenwert, wie in der folgenden Abbildung dargestellt. Er streamt die Zeilen aus der Datenbank und speichert jeweils nur 1.000 Zeilen im JDBC-Treiber. Es tritt keine Ausnahme aufgrund von Speichermangel auf.
![\[Die AWS Glue-Konsole zeigt, dass der Executor-Speicher unter der sicheren Schwelle liegt.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-2-memoryprofile-fixed.png)
# Debugging von anspruchsvolle Phasen und Straggler-Aufgaben
Mit dem AWS Glue-Aufgabenprofiling können Sie anspruchsvolle Phasen und Straggler-Aufgaben in Ihren ETL-Aufträgen (Extrahieren, Transformieren und Laden) identifizieren. Eine Straggler-Aufgabe dauert viel länger als der Rest der Aufgaben in einer Phase eines AWS Glue-Auftrags. Dies bewirkt, dass die Phase länger dauert, was auch die gesamte Ausführungszeit des Auftrags verzögert.
## Zusammenführung von kleinen Eingabedateien zu größeren Ausgabedateien
Eine Straggler-Aufgabe kann auftreten, wenn eine uneinheitliche Verteilung der Arbeit auf die verschiedenen Aufgaben gibt, oder wenn eine Datenverzerrung dazu führt, dass eine Aufgabe mehr Daten verarbeiten muss.
Sie können den folgenden Code profilieren (ein gemeinsames Muster in Apache Spark), um eine große Anzahl von kleinen Dateien zu größeren Ausgabedateien zusammenzuführen. In diesem Beispiel besteht das Eingabe-Dataset aus 32 GB mit Gzip komprimierten JSON-Dateien. Das Ausgabe-Dataset umfasst ca. 190 GB nicht komprimierte JSON-Dateien.
Der profilierte Code sieht wie folgt aus:
```
datasource0 = spark.read.format("json").load("s3://input_path")
df = datasource0.coalesce(1)
df.write.format("json").save(output_path)
```
### Visualisieren der profilierten Metriken auf der AWS Glue-Konsole
Sie können Ihren Auftrags profilieren, um vier verschiedene Metrik-Gruppen zu überprüfen:
+ ETL-Datenbewegung
+ Datenmischung über Executors hinweg
+ Auftragsausführung
+ Arbeitsspeicherprofil
**ETL-Datenbewegung**: Im Profil **ETL Data Movement (ETL-Datenbewegung)** werden die Bytes von allen Executors in der ersten Phase, die innerhalb der ersten sechs Minuten abgeschlossen wird, relativ schnell [gelesen](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.read_bytes). Die gesamte Auftragsausführung dauert jedoch etwa eine Stunde, vor allem durch die [Schreibvorgänge](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.write_bytes) für die Daten.
![\[Graph, der das Profil der ETL-Datenbewegung zeigt.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-straggler-1.png)
**Datenmischung über Executors hinweg:** Die Anzahl der [gelesenen](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.shuffleLocalBytesRead) und [geschriebenen Bytes](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.shuffleBytesWritten) während des Mischens zeigt auch eine hohe Zahl, bevor Phase 2 endet, wie durch die Metriken **Job Execution (Auftragsausführung)** und **Data Shuffle (Datenmischung)** gezeigt. Nachdem die Daten aus allen Executors gemischt wurden, werden die Lese- und Schreiboperationen nur noch von Executor Nummer 3 ausgeführt.
![\[Die Metriken für das Mischen der Daten über alle Executors hinweg.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-straggler-2.png)
**Auftragsausführung:** Wie im folgenden Graphen gezeigt, sind alle anderen Executors im Leerlauf und werden schließlich zum Zeitpunkt 10:09 aufgegeben. Zu diesem Zeitpunkt verringert sich die Gesamtanzahl der Executors auf nur einen. Dies zeigt deutlich, dass der Executor Nummer 3 aus der Straggler-Aufgabe besteht, die die längste Ausführungszeit benötigt und zum größten Teil zur Auftragsausführungszeit beiträgt.
![\[Die Ausführungs-Metriken für die aktiven Executors.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-straggler-3.png)
**Speicherprofil:** Nachdem den ersten beiden Phasen verbraucht nur noch [Executor Nummer 3](monitoring-awsglue-with-cloudwatch-metrics.md#glue.executorId.jvm.heap.used) aktiv Arbeitsspeicher zur Verarbeitung der Daten. Die restlichen Executors sind einfach im Leerlauf oder wurden kurz nach Abschluss der ersten beiden Phasen aufgegeben.
![\[Die Metriken für das Arbeitsspeicherprofil nach der ersten zwei Phasen.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-straggler-4.png)
### Beheben von Straggling-Executors unter Verwendung der Gruppierung
Mit der *Gruppierungsfeature* in AWS Glue können Sie Straggling-Executors vermeiden. Verwenden Sie die Gruppierung, um die Daten gleichmäßig auf alle Executors zu verteilen und Dateien zu größeren Dateien zusammenzufassen, indem Sie alle verfügbaren Executors auf dem Cluster verwenden. Weitere Informationen finden Sie unter [Zusammenfassen von Eingabedateien in größeren Gruppen beim Lesen](grouping-input-files.md).
Um die ETL-Datenbewegungen des AWS Glue-Auftrags zu überprüfen, müssen Sie den folgenden Code mit aktivierter Gruppierung profilieren:
```
df = glueContext.create_dynamic_frame_from_options("s3", {'paths': ["s3://input_path"], "recurse":True, 'groupFiles': 'inPartition'}, format="json")
datasink = glueContext.write_dynamic_frame.from_options(frame = df, connection_type = "s3", connection_options = {"path": output_path}, format = "json", transformation_ctx = "datasink4")
```
**ETL-Datenbewegung:** Die Datenschreibvorgänge werden nun parallel zu den Datenlesevorgängen während der gesamten Ausführungszeit des Auftrags gestreamt. Dies bewirkt, dass der Auftrag innerhalb von acht Minuten abgeschlossen wird, viel schneller als zuvor.
![\[Die ETL-Datenbewegungen zeigen, dass das Problem behoben ist.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-straggler-5.png)
**Datenmischung über Executors hinweg:** Da die Eingabedateien während des Lesens über die Gruppierungsfeature zusammengeführt werden, gibt es nach dem Lesen der Daten keine kostspielige Datenmischung.
![\[Die Metriken zur Datenmischung zeigen, dass das Problem behoben ist.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-straggler-6.png)
**Auftragsausführung:** Die Auftragsausführungsmetriken zeigen, dass die Gesamtanzahl der aktiven Executors, die ausgeführt werden und Daten verarbeiten, relativ konstant bleibt. Es gibt keine einzelnen Straggler in dem Auftrag. Alle Executors sind aktiv und werden nicht aufgegeben, bis zum der Auftrag abgeschlossen ist. Da es keine zwischenzeitliche Datenmischung zwischen den Executors gibt, gibt es nur eine einzige Phase in dem Auftrag.
![\[Das Widget mit den Metriken für die Auftragsausführung zeigt, dass keine Straggler im Auftrag vorhanden sind.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-straggler-7.png)
**Speicherprofil:** Die Metriken zeigen die [aktive Speicherbelegung](monitoring-awsglue-with-cloudwatch-metrics.md#glue.executorId.jvm.heap.used) für alle Executors – dies bestätigt, dass Aktivitäten auf allen Executors vorliegen. Da die Daten parallel gestreamt und ausgegeben werden, ist der gesamte Speicherbedarf aller Executors etwa gleich groß und liegt weit unter der sicheren Schwelle für alle Executors.
![\[Die Speicherprofilmetriken zeigen die aktive Speicherbelegung über alle Executors.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-straggler-8.png)
# Überwachen des Fortschritts mehrerer Aufträge
Sie können mehrere AWS Glue Jobs zusammen profilieren und den Datenfluss zwischen ihnen überwachen. Dies ist ein gängiges Workflow-Muster und erfordert die Überwachung des Fortschritts einzelner Aufträge, des Datenverarbeitungsrückstands, der Datenwiederaufbereitung und der Auftragslesezeichen.
**Topics**
+ [Profilierter Code](#monitor-debug-multiple-profile)
+ [Visualisieren der profilierten Metriken auf der AWS Glue-Konsole](#monitor-debug-multiple-visualize)
+ [Korrektur der Dateiverarbeitung](#monitor-debug-multiple-fix)
## Profilierter Code
In diesem Workflow haben Sie zwei Aufträge: einen Eingangsauftrag und einen Ausgangsauftrag. Die Ausführung des Eingangsauftrags ist für alle 30 Minuten eingeplant, wofür ein regelmäßiger Auslöser verwendet wird. Die Ausführung des Ausgangsauftrags ist nach jeder erfolgreichen Ausführung des Eingangsauftrags eingeplant. Diese geplanten Aufträge werden unter Verwendung von Auftragsauslöser kontrolliert.
![\[Screenshot der Konsole mit den Auftragsauslösern, die die Einplanung von Eingangs- und Ausgangsaufträgen kontrollieren.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-multiple-1.png)
**Eingangsauftrag**: Dieser Auftrag liest Daten von einem Amazon Simple Storage Service (Amazon S3)-Speicherort, transformiert sie mit `ApplyMapping` und schreibt sie an einen Amazon-S3-Staging--Speicherort. Der folgende Code ist profilierter Code für den Eingangsauftrag:
```
datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": ["s3://input_path"], "useS3ListImplementation":True,"recurse":True}, format="json")
applymapping1 = ApplyMapping.apply(frame = datasource0, mappings = [map_spec])
datasink2 = glueContext.write_dynamic_frame.from_options(frame = applymapping1, connection_type = "s3", connection_options = {"path": staging_path, "compression": "gzip"}, format = "json")
```
**Ausgangsauftrag**: Dieser Auftrag liest die Ausgabe des Eingangsauftrags vom Staging-Speicherort in Amazon S3, transformiert sie wieder und schreibt sie an ein Ziel:
```
datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": [staging_path], "useS3ListImplementation":True,"recurse":True}, format="json")
applymapping1 = ApplyMapping.apply(frame = datasource0, mappings = [map_spec])
datasink2 = glueContext.write_dynamic_frame.from_options(frame = applymapping1, connection_type = "s3", connection_options = {"path": output_path}, format = "json")
```
## Visualisieren der profilierten Metriken auf der AWS Glue-Konsole
Das folgende Dashboard überlagert die geschriebenen Bytes der Amazon-S3-Metrik vom Eingangsauftrag mit den gelesenen Bytes der Amazon-S3-Metrik auf derselben Zeitachse für den Ausgangsauftrag. Die Zeitachse zeigt verschiedenen Auftragsausführungen der Eingangs- und Ausgangsaufträge. Der Eingangsauftrag (rot markiert) startet alle 30 Minuten. Der Ausgangsauftrag (braun dargestellt) beginnt bei Abschluss des Eingangsauftrags mit einer maximalen Nebenläufigkeit von 1.
![\[Graph, der die gelesenen und geschriebenen Daten zeigt.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-multiple-4.png)
In diesem Beispiel sind die [Auftragslesezeichen](https://docs.aws.amazon.com/glue/latest/dg/monitor-continuations.html) nicht aktiviert. Es werden keine Transformationskontexte verwendet, um Auftragslesezeichen im Skriptcode zu aktivieren.
**Job History (Auftragsverlauf)**: Die Eingangs- und Ausgangsaufträge haben mehrere Ausführungen, wie auf der Registerkarte **History (Verlauf)** gezeigt, beginnend um 12:00 PM.
Der Eingangsauftrag in der AWS Glue-Konsole sieht wie folgt aus:
![\[Screenshot der Konsole mit der Registerkarte History (Verlauf) des Eingangsauftrags.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-multiple-2.png)
Das folgende Bild zeigt den Ausgangsauftrag:
![\[Screenshot der Konsole mit der Registerkarte History (Verlauf) des Ausgangsauftrags.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-multiple-3.png)
**First job runs (Erste Auftragsausführungen)**: Wie im folgenden Graphen für gelesene und geschriebene Datenbytes dargestellt, zeigen die ersten Auftragsausführungen der Eingangs- und Ausgangsaufträge zwischen 12:00 und 12:30 Uhr ungefähr die gleiche Fläche unter den Kurven. Diese Flächen stellen die vom Eingangsauftrag geschriebenen Amazon-S3-Bytes und die vom Ausgangsauftrag gelesenen Amazon-S3-Bytes dar. Diese Daten werden auch durch das Verhältnis von geschriebenen Amazon-S3-Bytes (summiert über 30 Minuten – die Auftragsauslösefrequenz für den Eingangsauftrag) bestätigt. Der Datenpunkt für das Verhältnis für die Eingangsauftragsausführung, die um 12:00 Uhr PM gestartet wurde, ist ebenfalls 1.
Der folgende Graph zeigt das Datenflussverhältnis für alle Auftragsausführungen:
![\[Graph, der das Datenflussverhältnis zeigt: geschriebenen Bytes und gelesene Bytes.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-multiple-5.png)
**Second job runs (Zweite Auftragsausführungen)**: In der zweiten Auftragsausführung gibt es eine klare Differenz zwischen der Anzahl der vom Ausgangsauftrag gelesenen Bytes im Vergleich zu der Anzahl der vom Eingangsauftrag geschriebenen Bytes. (Vergleichen Sie die Fläche unter der Kurve der beiden Auftragsausführungen für den Ausgangsauftrag oder vergleichen Sie die Flächen der zweiten Ausführung der Eingangs- und Ausgangsaufträge.) Das Verhältnis der gelesenen und geschriebenen Bytes zeigt, dass der Ausgangsauftrag in der zweiten Spanne von 30 Minuten von 12:30 bis 13:00 Uhr etwa die 2,5-fache Menge der vom Eingangsauftrag geschriebenen Daten gelesen hat. Der Grund hierfür ist, dass der Ausgangsauftrag die Ausgabe der ersten Auftragsausführung des Eingangsauftrags erneut verarbeitet hat, weil keine Auftragslesezeichen aktiviert waren. Ein Verhältnis von über 1 zeigt, dass es einen zusätzlichen Rückstand an Daten gibt, die von dem Ausgangsauftrag verarbeitet wurde.
**Third job runs (Dritte Auftragsausführungen)**: Der Eingangsauftrag ist relativ konsistent in Bezug auf die Anzahl der geschriebenen Bytes (siehe Fläche unter der roten Kurven). Die dritte Auftragsausführung des Eingangsauftrags ist jedoch länger gelaufen als erwartet (siehe langer Auslauf der roten Kurve). Dies hat zur Folge, dass die dritte Auftragsausführung des Ausgangsauftrags zu spät gestartet wurde. Die dritte Auftragsausführung verarbeitet nur ein Bruchteil der akkumulierten Daten am Staging-Speicherort in den verbleibenden 30 Minuten zwischen 13:00 und 13:30 Uhr. Das Verhältnis des Bytestroms zeigt, dass sie nur 0,83 der von der dritten Auftragsausführung des Eingabeauftrags geschriebenen Daten verarbeitet hat (siehe Verhältnis um 13.00 Uhr).
**Overlap of Input and Output jobs (Überlappende Eingangs- und Ausgangsaufträge)**: Die vierte Auftragsausführung des Eingangsauftrags startete um 13:30 gemäß den Zeitplan, bevor die dritte Auftragsausführung des Ausgangsauftrags abgeschlossen wurde. Es gibt eine partielle Überschneidung zwischen diesen beiden Auftragsausführungen. Die dritte Auftragsausführung des Ausgangsauftrags erfasst nur die Dateien, die am Staging-Speicherort von Amazon S3 aufgelistet sind, als sie etwa um 13:17 Uhr begonnen hat. Dies umfasst alle Datenausgaben aus den ersten Auftragsausführungen des Eingangsauftrags. Das tatsächliche Verhältnis um 13:30 ist etwa 2,75. Die dritte Auftragsausführung des Ausgangsauftrags hat etwa das 2,75-fache der von der vierten Auftragsausführung von 13:30 bis 14:00 Uhr geschriebenen Daten verarbeitet.
Wie diese Bilder zeigen, verarbeitet der Ausgangsauftrag Daten vom Staging-Standort aus allen vorherigen Auftragsausführungen des Eingangsauftrags erneut. Dies hat zur Folge, dass die vierte Auftragsausführung für den Ausgangsauftrag die längste ist und sich mit der gesamten fünften Auftragsausführung des Eingangsauftrags überlappt.
## Korrektur der Dateiverarbeitung
Sie sollten sicherstellen, dass der Ausgangsauftrag nur die Dateien verarbeitet, die von den vorherigen Auftragsausführungen des Ausgangsauftrags nicht verarbeitet wurden. Dazu aktivieren Sie die Auftragslesezeichen und legen Sie den Transformationskontext im Ausgangsauftrag wie folgt fest:
```
datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": [staging_path], "useS3ListImplementation":True,"recurse":True}, format="json", transformation_ctx = "bookmark_ctx")
```
Bei aktivierten Auftragslesezeichen verarbeitet der Ausgangsauftrag die Daten am Staging-Speicherort aus allen vorherigen Auftragsausführungen des Eingangsauftrags nicht erneut. In der folgenden Abbildung mit den gelesenen und geschriebenen Daten ist die Fläche unter der braunen Kurve relativ konsistent und ähnlich den roten Kurven.
![\[Graph, der die gelesenen und geschriebenen Daten als rote und braune Linien zeigt.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-multiple-6.png)
Auch die Verhältnisse des Byteflusses bleiben etwa bei 1, da keine zusätzlichen Daten verarbeitet werden.
![\[Graph, der das Datenflussverhältnis zeigt: geschriebenen Bytes und gelesene Bytes\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-multiple-7.png)
Eine Auftragsausführung für den Ausgangsauftrag startet und erfasst die Dateien am Staging-Speicherort, bevor die nächste Eingangsauftragsausführung gestartet wird, womit weitere Daten am Staging-Standort abgelegt werden. Solange dies fortgesetzt wird, verarbeitet sie nur die Dateien, die von der vorherigen Eingangsauftragsausführung erfasst wurden, und das Verhältnis bleibt etwa 1.
![\[Graph, der das Datenflussverhältnis zeigt: geschriebenen Bytes und gelesene Bytes\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-multiple-7.png)
Angenommen, der Eingangsauftrag dauert länger als erwartet, und der Ausgangsauftrag erfasst aus diesem Grund Dateien am Staging-Standort von zwei Eingangsauftragsausführungen. Das Verhältnis wird dann höher als 1 für diese Ausgangsauftragausführung. Die folgenden Auftragsausführungen des Ausgangsauftrags verarbeiten jedoch keine Dateien, die bereits von den vorherigen Auftragsausführungen des Ausgangsauftrags verarbeitet wurden.
# Überwachung für die DPU-Kapazitätsplanung
Sie können Job-Metriken verwenden AWS Glue , um die Anzahl der Datenverarbeitungseinheiten (DPUs) zu schätzen, die zur Skalierung eines AWS Glue Jobs verwendet werden können.
**Anmerkung**
Diese Seite trifft nur auf AWS Glue-Versionen 0.9 und 1.0 zu. Spätere Versionen von AWS Glue enthalten Funktionen zur Kosteneinsparung, die zusätzliche Überlegungen bei der Kapazitätsplanung mit sich bringen.
**Topics**
+ [Profilierter Code](#monitor-debug-capacity-profile)
+ [Visualisieren der profilierten Metriken auf der AWS Glue-Konsole](#monitor-debug-capacity-visualize)
+ [Bestimmen der optimalen DPU-Kapazität](#monitor-debug-capacity-fix)
## Profilierter Code
Das folgende Skript liest eine Amazon Simple Storage Service (Amazon S3)-Partition mit 428 gezippten JSON-Dateien. Das Skript wendet ein Mapping an, um die Feldnamen zu ändern, und konvertiert und schreibt sie in Amazon S3 im Apache-Parquet-Format. Sie stellen 10 DPUs standardmäßig bereit und führen diesen Job aus.
```
datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": [input_path], "useS3ListImplementation":True,"recurse":True}, format="json")
applymapping1 = ApplyMapping.apply(frame = datasource0, mappings = [(map_spec])
datasink2 = glueContext.write_dynamic_frame.from_options(frame = applymapping1, connection_type = "s3", connection_options = {"path": output_path}, format = "parquet")
```
## Visualisieren der profilierten Metriken auf der AWS Glue-Konsole
**Job-Run 1:** In diesem Job-Run zeigen wir, wie Sie herausfinden können, ob DPUs im Cluster zu wenig Provisioning vorhanden ist. Die Auftragsausführungsfunktionalität in AWS Glue zeigt die [Gesamtzahl der aktiven Executors](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberAllExecutors), die [Anzahl der abgeschlossenen Phasen](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.numCompletedStages) und die [Anzahl der maximal benötigten Executors](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberMaxNeededExecutors).
Die Anzahl der maximal benötigten Executors wird berechnet, indem die Gesamtzahl der laufenden Aufgaben und anstehenden Aufgaben addiert und durch die Aufgaben pro Executor dividiert wird. Dieses Ergebnis ist ein Maß für die Gesamtanzahl der Executors, die erforderlich sind, um die aktuelle Last zu erfüllen.
Im Gegensatz dazu misst die Anzahl der aktiven Executors, wie viele aktive Apache-Spark-Aufgaben ausgeführt werden. Im weiteren Verlauf des Auftrags können sich die maximal benötigten Executors ändern und gehen in der Regel gegen Ende des Auftrags zurück, da die Warteschlange der anstehenden Aufgaben abnimmt.
Die horizontale rote Linie in der folgenden Grafik zeigt die Anzahl der maximal zugewiesenen Executoren, die von der Anzahl der Executoren abhängt, DPUs die Sie dem Job zuweisen. In diesem Fall weisen Sie dem ausgeführten Job 10 DPUs zu. Eine DPU ist für die Verwaltung reserviert. Neun DPUs führen jeweils zwei Executors aus und ein Executor ist für den Spark-Treiber reserviert. Der Spark-Treiber wird in der primären Anwendung ausgeführt. Die Anzahl der maximalen zugewiesenen Executors ist also 2\$1 9 – 1 = 17 Executors.
![\[Die Auftragsmetriken, die die aktiven Executors und die maximal benötigten Executors zeigen.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-capacity-1.png)
Wie der Graph zeigt, beginnt die Anzahl der maximal benötigten Executors bei 107 zu Beginn des Auftrags, während die Anzahl der aktiven Executors bei 17 bleibt. Dies entspricht der Anzahl der maximal zugewiesenen Executoren mit 10. DPUs Das Verhältnis zwischen den maximal benötigten Executors und den maximal zugewiesenen Executors (zu beiden wird für den Spark-Treiber 1 addiert) ergibt den Faktor für die zu niedrig ausgelegte Bereitstellung: 108/18 = 6x. Sie können 6 (unter dem Provisioning Ratio) \$19 (aktuelle DPU-Kapazität — 1) \$1 1 DPUs = 55 bereitstellen, um den Job so DPUs zu skalieren, dass er mit maximaler Parallelität ausgeführt und schneller abgeschlossen wird.
Die AWS Glue -Konsole zeigt die detaillierten Auftragsmetriken als statische Linie an, die die ursprüngliche Anzahl der maximal zugeteilten Executors darstellt. Die Konsole berechnet die maximal zugeteilten Executors aus der Auftragsdefinition für die Metriken. Im Gegensatz dazu berechnet die Konsole für detaillierte Messwerte zur Auftragsausführung die maximal zugewiesenen Executoren aus der Job-Run-Konfiguration, insbesondere die für die Job-Ausführung zugewiesenen. DPUs Um Metriken für eine einzelne Auftragsausführung anzuzeigen, wählen Sie die Auftragsausführung und anschließend **View run metrics (Ausführungsmetriken anzeigen)** aus.
![\[Die Auftragsmetriken, die die ETL-Datenbewegung zeigen.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-capacity-2.png)
Bei der Betrachtung der [gelesenen](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.read_bytes) und [geschriebenen](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.write_bytes) Amazon-S3-Bytes erkennen Sie, dass der Auftrag alle sechs Minuten parallel Daten aus Amazon S3 streamt und schreibt. Alle Kerne auf den zugewiesenen DPUs Kernen lesen und schreiben in Amazon S3. Die maximale Anzahl an benötigten Executors von 107 entspricht auch der Anzahl der Dateien im Amazon-S3-Eingangspfad 428. Jeder Executor können vier Spark-Aufgaben zur Verarbeitung von vier Eingangsdateien (gezippte JSON-Dateien) starten.
## Bestimmen der optimalen DPU-Kapazität
Basierend auf den Ergebnissen der vorherigen Auftragsausführung können Sie die Gesamtzahl der zugewiesenen Aufgaben DPUs auf 55 erhöhen und so die Leistung des Auftrags überprüfen. Der Auftrag wird in weniger als drei Minuten abgeschlossen – der Hälfte der Zeit, die zuvor erforderlich war. Die Auftragsskalierung erfolgt in diesem Fall nicht linear, da es sich um einen kurzen Auftrag handelt.. Jobs mit langlebigen Aufgaben oder einer großen Anzahl von Aufgaben (eine große Anzahl von maximal benötigten Executoren) profitieren von einer close-to-linear DPU-Scale-Out-Leistungssteigerung.
![\[Grafik, die die Zunahme der Gesamtzahl der zugewiesenen Aufgaben zeigt DPUs\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-capacity-3.png)
Wie die folgende Abbildung zeigt, erreicht die Gesamtzahl der aktiven Executors die maximale Anzahl zugewiesener Executors107. Ebenso liegt die maximale Anzahl benötigter Executors nie über den maximal zugewiesenen Executors. Die maximale Anzahl erforderlicher Executors wird anhand der Anzahl der aktiven und ausstehenden Aufgaben berechnet, sie könnte also kleiner sein als die Anzahl der aktiven Executors. Dies liegt daran, dass es Executors geben kann, die für einen kurzen Zeitraum teilweise oder vollständig im Leerlauf sind und noch nicht außer Betrieb genommen wurden.
![\[Graph, der die Gesamtzahl aktiver Executors zeigt, die die maximal zugewiesene Anzahl erreicht.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-capacity-4.png)
Dieser Auftrag nutzt sechsmal mehr Executors für parallele Lese- und Schreibvorgänge in Amazon S3. Dies hat zur Folge, dass diese Auftragsausführung mehr Amazon-S3-Bandbreite für Lese- und Schreibvorgänge verwendet und schneller fertiggestellt wird.
### Identifizieren Sie übermäßig bereitgestellte DPUs
Als Nächstes können Sie feststellen, ob eine weitere Skalierung des Jobs mit 100 DPUs (99 \$1 2 = 198 Executoren) hilfreich ist. Wie der folgende Graph zeigt, dauert die Fertigstellung des Auftrags immer noch drei Minuten. Ebenso kann der Job nicht über 107 Executoren ( DPUsKonfiguration 55) hinaus skaliert werden, und die verbleibenden 91 Executoren sind überprovisioniert und werden überhaupt nicht verwendet. Dies zeigt, dass eine Erhöhung der Anzahl von Executoren DPUs möglicherweise nicht immer zu einer Verbesserung der Leistung führt, wie anhand der maximal benötigten Anzahl von Executoren deutlich wird.
![\[Aus der Grafik geht hervor, dass die Arbeitsleistung nicht immer steigt, wenn die Anzahl der DPUs\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-capacity-5.png)
### Vergleich von Zeitunterschieden
Die drei in der folgenden Tabelle aufgeführten Auftragsausführungen fassen die Ausführungszeiten für 10 DPUs DPUs, 55 und 100 DPUs Jobs zusammen. Sie finden die DPU-Kapazität zur Verbesserung der Auftragsausführungszeit unter Verwendung der Schätzungen, die Sie bei der Überwachung der ersten Auftragsausführung eingerichtet haben.
| Auftrags-ID | Anzahl der DPUs | Execution time (Ausführungszeit) |
| --- | --- | --- |
| jr\$1c894524c8ef5048a4d9... | 10 | 6 Minuten |
| jr\$11a466cf2575e7ffe6856... | 55 | 3 Minuten |
| jr\$134fa1ed4c6aa9ff0a814... | 100 | 3 Minuten |