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.
Amazon EMR-Cluster-Protokollierung und Debugging konfigurieren
Bei der Planung Ihres Clusters müssen Sie sich unter anderem für die verfügbare Debugging-Unterstützung entscheiden. Wenn Sie Ihre Datenverarbeitungsanwendung erstmals entwickeln, empfehlen wir Ihnen, die Anwendung auf einem Cluster zu testen, indem Sie eine kleine, aber repräsentative Untermenge Ihrer Daten verarbeiten. Wenn Sie dies tun, möchten Sie wahrscheinlich die Vorteile all der Debugging-Tools in Amazon EMR nutzen, z. B. die Archivierung von Protokolldateien in Amazon S3.
Wenn Sie die Entwicklung Ihrer Anwendung abgeschlossen haben und die Datenverarbeitung in die Produktionsumgebung wechselt, können Sie das Debuggen verringern. Auf diese Weise können Sie die Kosten für die Speicherung von Protokolldateiarchiven in Amazon S3 einsparen und die Verarbeitungslast für den Cluster reduzieren, da dieser den Zustand nicht mehr zu Amazon S3 schreiben muss. Der Nachteil ist, das Ihnen bei Problemen weniger Tools zur Verfügung stehen, um das Problem zu untersuchen.
Standardmäßige Protokolldateien
Standardmäßig schreibt jeder Cluster Protokolldateien auf allen Knoten. Die Dateien werden in das /mnt/var/log/-Verzeichnis geschrieben. Sie können auf sie zugreifen, indem Sie SSH verwenden, um eine Verbindung zu einem der Knoten herzustellen, wie unter beschriebenStellen Sie mithilfe von SSH eine Connect zum primären Knoten des Amazon EMR-Clusters her. Amazon EMR sammelt bestimmte System- und Anwendungsprotokolle, die von Amazon EMR-Daemons und anderen Amazon EMR-Prozessen generiert wurden, um einen effektiven Servicebetrieb sicherzustellen.
Anmerkung
Wenn Sie Amazon EMR Version 6.8.0 oder früher verwenden, werden Protokolldateien während der Clusterbeendigung nicht in Amazon S3 gespeichert, sodass Sie nach dem Beenden der Knoten nicht auf die Protokolldateien zugreifen können. Amazon EMR veröffentlicht 6.9.0 und höher und archiviert Protokolle während der Cluster-Herunterskalierung in Amazon S3, sodass die auf dem Cluster generierten Protokolldateien auch nach dem Beenden des Knotens bestehen bleiben.
Sie müssen nichts aktivieren, damit Protokolldateien auf alle Knoten geschrieben werden. Dies ist das Standardverhalten von Amazon EMR und Hadoop.
Amazon EMR erfasst drei Kategorien von Protokollen für die S3-Protokollierung:
-
Systemprotokolle: EMR-Daemon-Protokolle
-
Anwendungsprotokolle: Framework-Protokolle von Hadoop, Spark, Hive und anderen Anwendungen, die auf dem Cluster ausgeführt werden
-
Persistente UI-Protokolle: Protokolle, die für persistente Anwendungen UIs wie Spark History Server und Tez UI erforderlich sind
Auf dem lokalen Dateisystem generiert ein Cluster verschiedene Arten von Protokolldateien/mnt/var/log, darunter:
-
Schritt-Protokolle – Diese Protokolle werden vom Amazon-EMR-Service generiert und enthalten Informationen über den Cluster und die Ergebnisse der einzelnen Schritte. Die Protokolldateien werden im
/mnt/var/log/hadoop/steps/-Verzeichnis auf dem Primärknoten gespeichert. Jeder Schritt protokolliert seine Ergebnisse in einem separaten, nummerierten Unterverzeichnis:/mnt/var/log/hadoop/steps/s-für den ersten Schritt,stepId1//mnt/var/log/hadoop/steps/s-für den zweiten Schritt, und so weiter. Die 13-stellige Schritt-ID (z. B. stepId1 stepId2) ist für einen Cluster eindeutig.stepId2/ -
Hadoop- und YARN-Komponentenprotokolle — Die Protokolle für Komponenten MapReduce, die sowohl Apache YARN als auch zugeordnet sind, befinden sich beispielsweise in separaten Ordnern
/mnt/var/logauf allen Knoten. Die Speicherorte der Protokolldateien für die Hadoop-Komponenten unter/mnt/var/loglauten folgendermaßen: hadoop-hdfs, hadoop-mapreduce, hadoop-httpfs und hadoop-yarn. Das hadoop-state-pusher Verzeichnis ist für die Ausgabe des Hadoop-State-Pusher-Prozesses vorgesehen. -
Bootstrap-Aktion-Protokolle – Wenn Ihr Auftrag Bootstrap-Aktionen verwendet, werden die Ergebnisse dieser Aktionen protokolliert. Die Protokolldateien werden in/mnt/var/log/bootstrap-actions/ auf allen Knoten gespeichert. Jede Bootstrap-Aktion protokolliert ihre Ergebnisse in einem separaten, nummerierten Unterverzeichnis:
/mnt/var/log/bootstrap-actions/1/für die erste Bootstrap-Aktion,/mnt/var/log/bootstrap-actions/2/für die zweite, und so weiter. -
Instance-Statusprotokolle – Diese Protokolle enthalten Informationen über die CPU, den Arbeitsspeicher und die Garbage Collector-Threads des Knotens. Die Protokolldateien werden
/mnt/var/log/instance-state/auf allen Knoten gespeichert.
Archivieren von Protokolldateien in Amazon S3
Anmerkung
Sie können mit dem yarn logs-Dienstprogramm derzeit keine Protokollzusammenführung in Amazon S3 durchführen.
Amazon EMR veröffentlicht 6.9.0 und höher und archiviert Protokolle während der Cluster-Herunterskalierung in Amazon S3, sodass die auf dem Cluster generierten Protokolldateien auch nach dem Beenden des Knotens bestehen bleiben. Dieses Verhalten wird automatisch aktiviert, sodass Sie nichts unternehmen müssen, um es zu aktivieren. Für Amazon EMR-Versionen 6.8.0 und früher können Sie einen Cluster so konfigurieren, dass die auf allen Knoten gespeicherten Protokolldateien regelmäßig in Amazon S3 archiviert werden. Auf diese Weise wird sichergestellt, dass die Protokolldateien verfügbar sind, nachdem der Cluster beendet wird (unabhängig davon, ob dieser normal heruntergefahren wurde oder ob ein Fehler aufgetreten ist). Amazon EMR archiviert die Protokolldateien in 5-Minuten-Intervallen in Amazon S3.
Um die Protokolldateien in Amazon S3 für Amazon-EMR-Versionen 6.8.0 zu archivieren, müssen Sie dieses Feature beim Start des Clusters aktivieren. Sie können dies entweder über Konsole, die CLI oder die API erledigen. Die Protokollierung ist bei über die Konsole gestarteten Clustern standardmäßig aktiviert. Für Cluster, die per CLI oder über die API gestartet wurden, muss die Protokollierung in Amazon S3 manuell aktiviert werden.
Um in Amazon S3 gespeicherte Protokolldateien mit einem AWS vom Kunden verwalteten KMS-Schlüssel zu verschlüsseln
Mit Amazon EMR Version 5.30.0 und höher (außer Amazon EMR 6.0.0) können Sie in Amazon S3 gespeicherte Protokolldateien mit einem vom Kunden verwalteten KMS-Schlüssel verschlüsseln. AWS Um diese Option über die Konsole zu aktivieren, führen Sie die Schritte unter Archivieren von Protokolldateien in Amazon S3 aus. Ihr Amazon-EC2-Instance-Profil und Ihre Amazon-EMR-Rolle müssen die folgenden Voraussetzungen erfüllen:
-
Das für den Cluster verwendete Amazon-EC2-Instance-Profil muss über die Berechtigung
kms:GenerateDataKeyverfügen. -
Die für den Cluster verwendete Amazon-EMR-Rolle muss über die Berechtigung
kms:DescribeKeyverfügen. -
Das Amazon EC2 EC2-Instance-Profil und die Amazon EMR-Rolle müssen der Liste der Hauptbenutzer für den angegebenen kundenverwalteten AWS KMS-Schlüssel hinzugefügt werden, wie die folgenden Schritte zeigen:
-
Um die AWS Region zu ändern, verwenden Sie die Regionsauswahl in der oberen rechten Ecke der Seite.
-
Wählen Sie den Alias des zu ändernden KMS-Schlüssels aus.
-
Wählen Sie auf der Seite mit den Schlüsseldetails unter Key Users (Schlüsselbenutzer( die Option Add (Hinzufügen) aus.
-
Wählen Sie im Dialogfeld Schlüsselbenutzer hinzufügen Ihr Amazon-EC2-Instance-Profil und Ihre Amazon-EMR-Rolle aus.
-
Wählen Sie Hinzufügen aus.
Außerdem müssen Sie den KMS-Schlüssel so konfigurieren, dass die
persistentappui---elasticmapreduce.amazonaws.com.rproxy.govskope.usundelasticmapreduce.amazonaws.com.rproxy.govskope.usService Principals undkms:GenerateDataKeykms:GenerateDataKeyWithoutPlaintextkms:DecryptAuf diese Weise kann EMR mit dem KMS-Schlüssel verschlüsselte Protokolle lesen und in den verwalteten Speicher schreiben. Die Benutzer-IAM-Rolle muss über die Berechtigung zur Verwendungkms:GenerateDataKeyvon und verfügen.kms:Decrypt{ "Sid": "Allow User Role to use KMS key", "Effect": "Allow", "Principal": { "AWS": "User Role" }, "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": "*", "Condition": { "StringLike": { "kms:EncryptionContext:aws:elasticmapreduce:clusterId": "j-*", "kms:ViaService": "elasticmapreduce.region.amazonaws.com" } } }, { "Sid": "Allow Persistent APP UI to validate KMS key for write", "Effect": "Allow", "Principal":{ "Service": [ "elasticmapreduce.amazonaws.com" ] }, "Action": [ "kms:GenerateDataKeyWithoutPlaintext" ], "Resource": "*", "Condition": { "StringLike": { "aws:SourceArn": "arn:aws:elasticmapreduce:region:account:cluster/j-*", "kms:EncryptionContext:aws:elasticmapreduce:clusterId": "j-*" } } }, { "Sid": "Allow Persistent APP UI to Write/Read Logs", "Effect": "Allow", "Principal":{ "Service": [ "persistentappui.elasticmapreduce.amazonaws.com", "elasticmapreduce.amazonaws.com" ] }, "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": "*", "Condition": { "StringLike": { "aws:SourceArn": "arn:aws:elasticmapreduce:region:account:cluster/j-*", "kms:EncryptionContext:aws:elasticmapreduce:clusterId": "j-*", "kms:ViaService": "s3.region.amazonaws.com" } } }Aus Sicherheitsgründen empfehlen wir, die
aws:SourceArnBedingungenkms:EncryptionContextund hinzuzufügen. Diese Bedingungen tragen dazu bei, dass der Schlüssel nur von Amazon EMR auf EC2 und nur für Protokolle verwendet wird, die von Aufträgen generiert werden, die in einem bestimmten Cluster ausgeführt werden.
Weitere Informationen finden Sie unter Von Amazon EMR verwendete IAM-Servicerollen und Verwenden von Schlüsselrichtlinien im AWS Key Management Service-Entwicklerhandbuch.
Um Protokolle in Amazon S3 zu aggregieren, verwenden Sie AWS CLI
Anmerkung
Sie können mit dem yarn logs-Dienstprogramm derzeit keine Protokollzusammenführung durchführen. Sie können die durch dieses Verfahren unterstützte Aggregation nutzen.
Bei der Protokollaggregation (Hadoop 2.x) werden Protokolle für eine bestimmte Anwendung aus allen Containern in einer einzigen Datei zusammengestellt. Um die Protokollaggregation für Amazon S3 mithilfe von zu aktivieren AWS CLI, verwenden Sie beim Clusterstart eine Bootstrap-Aktion, um die Protokollaggregation zu aktivieren und den Bucket zum Speichern der Protokolle anzugeben.
-
Um die Protokollaggregation zu aktivieren, erstellen Sie die folgende Konfigurationsdatei mit dem Namen
myConfig.json, die Folgendes enthält:[ { "Classification": "yarn-site", "Properties": { "yarn.log-aggregation-enable": "true", "yarn.log-aggregation.retain-seconds": "-1", "yarn.nodemanager.remote-app-log-dir": "s3:\/\/DOC-EXAMPLE-BUCKET\/logs" } } ]Geben Sie den folgenden Befehl ein und ersetzen Sie
durch den Namen Ihres EC2-Schlüsselpaars. Sie können zusätzlich jeden der roten Texte durch Ihre eigenen Konfigurationen ersetzen.myKeyaws emr create-cluster --name "Test cluster" \ --release-labelemr-7.12.0\ --applications Name=Hadoop\ --use-default-roles \ --ec2-attributes KeyName=myKey\ --instance-typem5.xlarge\ --instance-count3\ --configurations file://./myConfig.jsonWenn Sie die Instance-Anzahl ohne den
--instance-groups-Parameter angeben, wird ein einzelner Primärknoten gestartet. Die verbleibenden Instances werden dabei als Core-Knoten gestartet. Alle Knoten verwenden den im Befehl angegebenen Instance-Typ.Anmerkung
Wenn Sie zuvor nicht die standardmäßige EMR-Servicerolle und das EC2-Instance-Profil erstellt haben, führen Sie
aws emr create-default-rolesaus, um sie zu erstellen, bevor Sie den Unterbefehlcreate-clusterausführen.
Weitere Informationen zur Verwendung von Amazon EMR-Befehlen finden Sie in der AWS CLIAWS CLI Befehlsreferenz.
Amazon EMR-Selbstdiagnose- und Problembehebungstools
Dieses Runbook hilft bei der Identifizierung von Fehlern bei der Ausführung eines Jobs auf einem Amazon EMR-Cluster. Das Runbook analysiert eine Liste definierter Protokolle im Dateisystem und sucht nach einer Liste mit vordefinierten Schlüsselwörtern. Diese Protokolleinträge werden verwendet, um Amazon CloudWatch Events-Ereignisse zu erstellen, sodass Sie auf der Grundlage der Ereignisse alle erforderlichen Maßnahmen ergreifen können. Optional veröffentlicht das Runbook Protokolleinträge in der Amazon CloudWatch Logs-Protokollgruppe Ihrer Wahl. AWSSupport-AnalyzeEMRLogs.
Dieses Runbook hilft bei der Diagnose von Amazon EMR-Protokollen auf S3 mithilfe von Amazon Athena in Integration mit AWS Glue Data Catalog. Amazon Athena wird verwendet, um die Amazon EMR-Protokolldateien nach Containern, Knotenprotokollen oder beidem abzufragen, mit optionalen Parametern für bestimmte Datumsbereiche oder schlüsselwortbasierte Suchen. Dieses Runbook enthält eine Liste aller Fehler und häufig aufgetretenen Ausnahmen, die in den Amazon EMR-Clusterprotokollen gefunden wurden, zusammen mit den entsprechenden S3-Protokollspeicherorten. Es bietet auch eine Zusammenfassung der eindeutigen bekannten Ausnahmen, die in den Amazon EMR-Protokollen gefunden wurden, sowie empfohlene Lösungen und Artikel im Knowledge Center/ re:POST, die bei der Fehlerbehebung helfen. AWSSupport-DiagnoseEMRLogsWithAthena
Protokollspeicherorte
Die folgende Liste enthält alle Protokolltypen und ihre Speicherorte in Amazon S3. Sie können diese zur Behebung von Problemen mit Amazon EMR verwenden.
- Schrittprotokolle
-
s3://DOC-EXAMPLE-LOG-BUCKET/<cluster-id>/steps/<step-id>/ - Anwendungsprotokolle
-
s3://DOC-EXAMPLE-LOG-BUCKET/<cluster-id>/containers/Dieser Speicherort umfasst Container
stderrundstdout,directory.info,prelaunch.outundlaunch_container.sh-Protokolle. - Resource-Manager-Protokolle
-
s3://DOC-EXAMPLE-LOG-BUCKET/<cluster-id>/node/<leader-instance-id>/applications/hadoop-yarn/ - Hadoop HDFS
-
s3://DOC-EXAMPLE-LOG-BUCKET/<cluster-id>/node/<all-instance-id>/applications/hadoop-hdfs/Dieser Speicherort umfasst NameNode, und DataNode YARN-Protokolle. TimelineServer
- Knoten-Manager-Protokolle
-
s3://DOC-EXAMPLE-LOG-BUCKET/<cluster-id>/node/<all-instance-id>/applications/hadoop-yarn/ - Instance-Statusprotokolle
-
s3://DOC-EXAMPLE-LOG-BUCKET/<cluster-id>/node/<all-instance-id>/daemons/instance-state/ - Bereitstellungsprotokolle für Amazon EMR
-
s3://DOC-EXAMPLE-LOG-BUCKET/<cluster-id>/node/<leader-instance-id>/provision-node/* - Hive-Protokolle
-
s3://DOC-EXAMPLE-LOG-BUCKET/<cluster-id>/node/<leader-instance-id>/applications/hive/*-
Um Hive-Protokolle in Ihrem Cluster zu finden, entfernen Sie das Sternchen (
*) und fügen Sie/var/log/hive/an den obigen Link an. -
Um HiveServer zwei Logs zu finden, entferne das Sternchen (
*) und füge esvar/log/hive/hiveserver2.logan den obigen Link an. -
Um HiveCLI-Protokolle zu finden, entfernen Sie das Sternchen (
*) und fügen Sie/var/log/hive/user/hadoop/hive.logan den obigen Link an. -
Um Hive-Metastore-Server-Protokolle zu finden, entfernen Sie das Sternchen (
*) und fügen Sie/var/log/hive/user/hive/hive.logan den obigen Link an.
Wenn Ihr Fehler im Primär- oder Aufgabenknoten Ihrer Tez-Anwendung auftritt, stellen Sie die Protokolle des entsprechenden Hadoop-Containers bereit.
-
Steuern Sie das S3-Protokollierungsverhalten (Amazon EMR 7.13.0 und höher)
Ab Amazon EMR 7.13.0 können Sie das Upload-Verhalten über die S3-Funktion steuern. LoggingConfiguration Auf diese Weise können Sie unterschiedliche Upload-Richtlinien für verschiedene Protokolltypen angeben: Systemprotokolle, Anwendungsprotokolle und persistente Benutzeroberflächenprotokolle.
Richtlinien hochladen
Für jeden Protokolltyp können Sie eine der folgenden Upload-Richtlinien angeben. Bei nicht spezifizierten Protokolltypen wird standardmäßig das Standardverhalten (emr-managed) verwendet:
- emr-managed (Standard)
-
Standardverhalten. Protokolle werden wie in Ihrem konfiguriert auf Amazon S3 hochgeladenLogUri, wobei bestimmte Protokolle vom Service für Betriebsunterstützung und Problembehebung aufbewahrt werden.
- on-customer-sNur 3
-
Nur vom Kunden verwalteter Speicher. Protokolle werden nur in den vom Kunden angegebenen S3-Bucket hochgeladen. Dazu müssen Sie bei der LogUri Erstellung des Clusters a angeben. Persistent-ui-logskann keine Richtlinie on-customer-s nur für 3 haben. Zulässige Richtlinien für persistent-ui-logs werden von EMR verwaltet und sind deaktiviert.
- disabled
-
Kein S3-Upload für diesen Protokolltyp.
Beispiele für Konfigurationen
Sie können die S3-Protokollierung konfigurieren, wenn Sie einen neuen Amazon EMR-Cluster über das AWS CLI, oder AWS SDKs erstellen. Die Konfiguration wird über den MonitoringConfiguration Parameter angegeben.
Beispiel: Standardverhalten
Wenn Sie S3 nicht angebenLoggingConfiguration, verwenden alle Protokolltypen standardmäßig das von EMR verwaltete Verhalten:
aws emr create-cluster \ --name "MyCluster" \ --release-label emr-7.13.0 \ --instance-type m5.xlarge \ --instance-count 3 \ --log-uri s3://my-bucket/logs/ \ --use-default-roles
Beispiel: Benutzerdefinierte S3-Protokollierungskonfiguration
Dieses Beispiel zeigt, wie unterschiedliche Upload-Richtlinien für jeden Protokolltyp konfiguriert werden:
aws emr create-cluster \ --name "MyCluster" \ --release-label emr-7.13.0 \ --instance-type m5.xlarge \ --instance-count 3 \ --log-uri s3://my-bucket/logs/ \ --use-default-roles \ --monitoring-configuration '{ "S3LoggingConfiguration": { "LogTypeUploadPolicy": { "application-logs": "on-customer-s3only", "persistent-ui-logs": "disabled" } } }'
Diese Konfiguration lädt Anwendungsprotokolle nur in den S3-Bucket des Kunden hoch und deaktiviert persistente UI-Protokoll-Uploads vollständig. Der nicht spezifizierte Protokolltyp (Systemprotokolle) folgt dem Standardverhalten (von EMR verwaltet).
Überlegungen
-
Die S3-Protokollierungskonfiguration kann nur zum Zeitpunkt der Clustererstellung festgelegt werden und kann nicht für laufende Cluster geändert werden.
-
Persistent-ui-logs kann keine Richtlinie on-customer-s nur für 3 haben. Zulässige Richtlinien für persistent-ui-logs werden von EMR verwaltet und sind deaktiviert.
-
LogUri Anforderung: Wenn Sie die Richtlinie „ on-customer-sNur 3“ für Systemprotokolle oder Anwendungsprotokolle verwenden, müssen Sie einen Parameter angeben. LogUri Andernfalls schlägt die LogUri Clustererstellung fehl.
-
Standardverhalten: Wenn S3 nicht angegeben LoggingConfiguration ist, verwenden alle Protokolltypen standardmäßig das von EMR verwaltete Verhalten.