Amazon EMR-Cluster-Protokollierung und Debugging konfigurieren - Amazon EMR

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-stepId1/ für den ersten Schritt, /mnt/var/log/hadoop/steps/s-stepId2/ für den zweiten Schritt, und so weiter. Die 13-stellige Schritt-ID (z. B. stepId1 stepId2) ist für einen Cluster eindeutig.

  • 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/log auf allen Knoten. Die Speicherorte der Protokolldateien für die Hadoop-Komponenten unter /mnt/var/log lauten 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.

Console
Wie Sie Protokolldateien auf Amazon S3 mit der neuen Konsole archivieren
  1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon EMR-Konsole unter https://console.aws.amazon.com/emr.

  2. Wählen Sie im linken Navigationsbereich unter EMR in EC2 die Option Cluster und dann Cluster erstellen aus.

  3. Aktivieren Sie unter Cluster-Protokolle das Kontrollkästchen Cluster-spezifische Protokolle in Amazon S3 veröffentlichen.

  4. Geben Sie im Feld Speicherort von Amazon S3 einen Amazon-S3-Pfad zum Speichern Ihrer Protokolle ein. Wenn Sie den Namen eines Ordners eingeben, der nicht im Bucket vorhanden ist, wird er von Amazon S3 erstellt.

    Wenn Sie diesen Wert festlegen, kopiert Amazon EMR die Protokolldateien von den EC2-Instances im Cluster nach Amazon S3. Dadurch wird verhindert, dass die Protokolldateien verloren gehen, wenn der Cluster beendet wird und EC2 die Instances, die den Cluster hosten, beendet. Diese Protokolle sind bei der Fehlerbehebung hilfreich. Weitere Informationen finden Sie unter Protokolldateien anzeigen.

  5. Aktivieren Sie optional das Kontrollkästchen Clusterspezifische Protokolle verschlüsseln. Wählen Sie dann einen AWS KMS Schlüssel aus der Liste aus, geben Sie einen Schlüssel-ARN ein oder erstellen Sie einen neuen Schlüssel. Diese Option ist nur mit Amazon-EMR-Version 5.30.0 und höher verfügbar, mit Ausnahme von Version 6.0.0. Um diese Option zu verwenden, fügen Sie die Berechtigung AWS KMS für Ihr EC2-Instance-Profil und Ihre Amazon EMR-Rolle hinzu. Weitere Informationen finden Sie unter Um in Amazon S3 gespeicherte Protokolldateien mit einem AWS vom Kunden verwalteten KMS-Schlüssel zu verschlüsseln.

  6. Wählen Sie alle anderen Optionen aus, die für Ihren Cluster gelten.

  7. Um Ihren Cluster jetzt zu starten, wählen Sie Cluster erstellen aus.

CLI
Um Protokolldateien auf Amazon S3 zu archivieren mit dem AWS CLI

Um Protokolldateien mit dem in Amazon S3 zu archivieren AWS CLI, geben Sie den create-cluster Befehl ein und geben Sie den Amazon S3 S3-Protokollpfad mithilfe des --log-uri Parameters an.

  1. Um Dateien in Amazon S3 zu protokollieren, geben Sie den folgenden Befehl ein und myKey ersetzen Sie ihn durch den Namen Ihres EC2-Schlüsselpaars.

    aws emr create-cluster --name "Test cluster" --release-label emr-7.12.0 --log-uri s3://DOC-EXAMPLE-BUCKET/logs --applications Name=Hadoop Name=Hive Name=Pig --use-default-roles --ec2-attributes KeyName=myKey --instance-type m5.xlarge --instance-count 3
  2. Wenn 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 Amazon-EMR-Servicerolle und das EC2-Instance-Profil erstellt haben, geben Sie aws emr create-default-roles ein, um sie zu erstellen, bevor Sie den Unterbefehl create-cluster eingeben.

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:GenerateDataKey verfügen.

  • Die für den Cluster verwendete Amazon-EMR-Rolle muss über die Berechtigung kms:DescribeKey verfü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:

    1. Öffnen Sie die Konsole AWS Key Management Service (AWS KMS) unter https://console.aws.amazon.com /kms.

    2. Um die AWS Region zu ändern, verwenden Sie die Regionsauswahl in der oberen rechten Ecke der Seite.

    3. Wählen Sie den Alias des zu ändernden KMS-Schlüssels aus.

    4. Wählen Sie auf der Seite mit den Schlüsseldetails unter Key Users (Schlüsselbenutzer( die Option Add (Hinzufügen) aus.

    5. Wählen Sie im Dialogfeld Schlüsselbenutzer hinzufügen Ihr Amazon-EC2-Instance-Profil und Ihre Amazon-EMR-Rolle aus.

    6. Wählen Sie Hinzufügen aus.

  • Außerdem müssen Sie den KMS-Schlüssel so konfigurieren, dass die persistentappui.elasticmapreduce.amazonaws.com und elasticmapreduce.amazonaws.com Service Principals und kms:GenerateDataKey kms:GenerateDataKeyWithoutPlaintext kms:Decrypt Auf 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 Verwendung kms:GenerateDataKey von 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:SourceArn Bedingungen kms:EncryptionContext und 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 myKey durch den Namen Ihres EC2-Schlüsselpaars. Sie können zusätzlich jeden der roten Texte durch Ihre eigenen Konfigurationen ersetzen.

    aws emr create-cluster --name "Test cluster" \ --release-label emr-7.12.0 \ --applications Name=Hadoop \ --use-default-roles \ --ec2-attributes KeyName=myKey \ --instance-type m5.xlarge \ --instance-count 3 \ --configurations file://./myConfig.json

    Wenn 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-roles aus, um sie zu erstellen, bevor Sie den Unterbefehl create-cluster ausfü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 stderr und stdout, directory.info, prelaunch.out und launch_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 es var/log/hive/hiveserver2.log an den obigen Link an.

  • Um HiveCLI-Protokolle zu finden, entfernen Sie das Sternchen (*) und fügen Sie /var/log/hive/user/hadoop/hive.log an 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.log an 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.