Wie kann ich auf Spark-Treiberprotokolle in einem Amazon EMR-Cluster zugreifen?
Ich möchte Probleme mit einer Apache Spark-Anwendung beheben. Wie greife ich auf Spark-Treiberprotokolle in einem Amazon EMR-Cluster zu?
Kurzbeschreibung
Auf Amazon EMR läuft Spark als YARN-Anwendung und unterstützt zwei Bereitstellungsmodi:
- Client-Modus: Dies ist der Standard-Bereitstellungsmodus. Im Client-Modus läuft der Spark-Treiber auf dem Host, auf dem der Befehl spark-submit ausgeführt wird.
- Cluster-Modus: Der Spark-Treiber wird im Anwendungs-Master ausgeführt. Der Anwendungs-Master ist der erste Container, der ausgeführt wird, wenn der Spark-Job ausgeführt wird.
Behebung
Jobs im Client-Modus
Wenn Sie eine Spark-Anwendung einreichen, indem Sie spark-submit mit dem --deploy-mode-client auf dem Hauptknoten ausführen, werden die Treiberprotokolle im Terminalfenster angezeigt. Amazon EMR archiviert diese Protokolle standardmäßig nicht. Um die Protokolle zu erfassen, speichern Sie die Ausgabe des Befehls spark-submit in einer Datei. Beispiel:
$ spark-submit [--deploy-mode client] ... 1>output.log 2>error.log
Wenn Sie eine Spark-Anwendung mithilfe eines Amazon EMR-Schritts einreichen, werden die Treiberprotokolle in der Datei stderr.gz auf Amazon Simple Storage Service (Amazon S3) archiviert. Der Dateipfad sieht in etwa wie folgt aus:
s3://aws-logs-111111111111-us-east-1/elasticmapreduce/j-35PUYZBQVIJNM/steps/s-2M809TD67U2IA/stderr.gz
Weitere Informationen finden Sie unter In Amazon S3 archivierte Protokolldateien anzeigen.
Laden Sie die Schrittprotokolle auf eine Amazon Elastic Compute Cloud (Amazon EC2) -Instance herunter und suchen Sie dann nach Warnungen und Fehlern:
1.Laden Sie die Schrittprotokolle herunter:
aws s3 sync s3://aws-logs-111111111111-us-east-1/elasticmapreduce/j-35PUYZBQVIJNM/steps/s-2M809TD67U2IA/ s-2M809TD67U2IA/
2.Öffnen Sie den Ordner mit den Schrittprotokollen:
cd s-2M809TD67U2IA/
3.Dekomprimieren Sie die Logdatei:
find . -type f -exec gunzip {} \;
4.Rufen Sie die YARN-Anwendungs-ID aus dem Clustermodus-Protokoll ab:
grep "Client: Application report for" * | tail -n 1
5.Finden Sie Fehler und Warnungen im Protokoll des Client-Modus:
egrep "WARN|ERROR" *
Es ist auch möglich, eine Spark-Anwendung mit einer Anwendung wie JupyterHub, Apache Livy oder Apache Zeppelin einzureichen. Diese Anwendungen werden zum Client, der die Spark-Anwendung an den Cluster übermittelt. In diesem Szenario werden die Treiberprotokolle in den Protokollen der entsprechenden Anwendung im Ordner /mnt/var/log/ auf dem Hauptknoten gespeichert. Sie finden die komprimierten Protokolle auch im folgenden Amazon S3-Pfad:
s3://awsexamplebucket/JOBFLOW_ID/node/MASTER_ID/applications/
Wenn Sie beispielsweise Zeppelin verwenden, finden Sie die Spark-Treiberprotokolle in /mnt/var/log/zeppelin/zeppelin-interpreter-spark-xxxxxxxxxx.log.
Hinweis: Für Jupyter werden die Treiberprotokolle in den Livy-Logs gespeichert: /mnt/var/log/livy/livy-livy-server.out.
Weitere Informationen zum Zugriff auf anwendungsspezifische Protokolle finden Sie unter In Amazon S3 archivierte Protokolldateien anzeigen.
Jobs im Clustermodus
Wenn Sie die Spark-Anwendung im Clustermodus einreichen, wird der Treiberprozess im Mastercontainer der Anwendung ausgeführt. Der Anwendungs-Master ist der erste Container, der ausgeführt wird, wenn die Spark-Anwendung ausgeführt wird. Der Client protokolliert den YARN-Anwendungsbericht. Um die Treiberprotokolle abzurufen:
1.Rufen Sie die Anwendungs-ID aus den Client-Protokollen ab. Im folgenden Beispiel ist application_1572839353552_0008 die Anwendungs-ID.
19/11/04 05:24:42 INFO Client: Application report for application_1572839353552_0008 (state: ACCEPTED)
2.Identifizieren Sie die Master-Container-Logs der Anwendung. Im Folgenden finden Sie eine Beispielliste von Spark-Anwendungsprotokollen. In dieser Liste ist container_1572839353552_0008_01_000001 der erste Container, was bedeutet, dass es sich um den Mastercontainer der Anwendung handelt.
s3://aws-logs-111111111111-us-east-1/elasticmapreduce/j-35PUYZBQVIJNM/containers/application_1572839353552_0008/container_1572839353552_0008_01_000001/stderr.gz
s3://aws-logs-111111111111-us-east-1/elasticmapreduce/j-35PUYZBQVIJNM/containers/application_1572839353552_0008/container_1572839353552_0008_01_000001/stdout.gz
s3://aws-logs-111111111111-us-east-1/elasticmapreduce/j-35PUYZBQVIJNM/containers/application_1572839353552_0008/container_1572839353552_0008_01_000002/stderr.gz
s3://aws-logs-111111111111-us-east-1/elasticmapreduce/j-35PUYZBQVIJNM/containers/application_1572839353552_0008/container_1572839353552_0008_01_000002/stdout.gz
3.Laden Sie die Master-Container-Logs der Anwendung auf eine EC2-Instanz herunter:
aws s3 sync s3://aws-logs-111111111111-us-east-1/elasticmapreduce/j-35PUYZBQVIJNM/containers/application_1572839353552_0008/ application_1572839353552_0008/
4.Öffnen Sie den Spark-Anwendungsprotokollordner:
cd application_1572839353552_0008/
5.Dekomprimieren Sie die Logdatei:
find . -type f -exec gunzip {} \;
6.Durchsuchen Sie alle Container-Logs nach Fehlern und Warnungen:
egrep -Ril "ERROR|WARN" . | xargs egrep "WARN|ERROR"
7.Öffnen Sie die Container-Logs, die in der Ausgabe des vorherigen Befehls zurückgegeben wurden.
In einem laufenden Cluster können Sie die YARN-CLI verwenden, um die Protokolle des YARN-Anwendungscontainers abzurufen. Für eine Spark-Anwendung, die im Clustermodus eingereicht wurde, können Sie auf die Spark-Treiberprotokolle zugreifen, indem Sie die Master-Container-Logs der Anwendung wie folgt abrufen:
# 1. Get the address of the node that the application master container ran on $ yarn logs -applicationId application_1585844683621_0001 | grep 'Container: container_1585844683621_0001_01_000001' 20/04/02 19:15:09 INFO client.RMProxy: Connecting to ResourceManager at ip-xxx-xx-xx-xx.us-west-2.compute.internal/xxx.xx.xx.xx:8032 Container: container_1585844683621_0001_01_000001 on ip-xxx-xx-xx-xx.us-west-2.compute.internal_8041 # 2. Use the node address to pull the container logs $ yarn logs -applicationId application_1585844683621_0001 -containerId container_1585844683621_0001_01_000001 -nodeAddress ip-xxx-xx-xx-xx.us-west-2.compute.internal
Weitere Informationen
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor 3 Jahren
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor 2 Jahren