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. # Protokollierung und Überwachung Die Überwachung ist ein wichtiger Bestandteil der Aufrechterhaltung der Zuverlässigkeit, Verfügbarkeit und Leistung von EMR Serverless-Anwendungen und -Jobs. Sie sollten Überwachungsdaten aus allen Teilen Ihrer EMR Serverless-Lösungen sammeln, damit Multipoint-Ausfälle einfacher debuggt werden können, falls sie auftreten. **Topics** + [Speichern von Protokollen](logging.md) + [Rotierende Protokolle](rotating-logs.md) + [Protokolle verschlüsseln](jobs-log-encryption.md) + [Apache Log4j2-Eigenschaften für Amazon EMR Serverless konfigurieren](log4j2.md) + [Serverlose EMR-Überwachung](metrics.md) + [Automatisierung von EMR Serverless mit Amazon EventBridge](using-eventbridge.md) # Speichern von Protokollen Um Ihren Auftragsfortschritt auf EMR Serverless zu überwachen und Auftragsfehler zu beheben, wählen Sie aus, wie EMR Serverless Anwendungsprotokolle speichert und bereitstellt. Wenn Sie einen Job ausführen, geben Sie Managed Storage, Amazon S3 und Amazon CloudWatch als Protokollierungsoptionen an. Geben Sie mit CloudWatch die Protokolltypen und Protokollspeicherorte an, die Sie verwenden möchten, oder akzeptieren Sie die Standardtypen und Speicherorte. Weitere Informationen zu CloudWatch Protokollen finden Sie unter[Protokollierung für EMR Serverless mit Amazon CloudWatch](#jobs-log-storage-cw). Bei verwaltetem Speicher und S3-Protokollierung sind in der folgenden Tabelle die Protokollspeicherorte und die Verfügbarkeit der Benutzeroberfläche aufgeführt, die Sie erwarten können, wenn Sie sich für [verwalteten Speicher](#jobs-log-storage-managed-storage), [Amazon S3 S3-Buckets](#jobs-log-storage-s3-buckets) oder beides entscheiden. | Option | Ereignisprotokolle | Containerprotokolle | Benutzeroberfläche der Anwendung | | --- | --- | --- | --- | | Verwalteter Speicher | In verwaltetem Speicher gespeichert | In verwaltetem Speicher gespeichert | Unterstützt | | Sowohl verwalteter Speicher als auch S3-Bucket | An beiden Orten gespeichert | Im S3-Bucket gespeichert | Unterstützt | | Amazon-S3-Bucket | Im S3-Bucket gespeichert | Im S3-Bucket gespeichert | Nicht unterstützt 1 | 1 Wir empfehlen, dass Sie die Option **Verwalteter Speicher** ausgewählt lassen. Andernfalls können Sie die integrierte Anwendung nicht verwenden UIs. ## Protokollierung für EMR Serverless mit verwaltetem Speicher Standardmäßig speichert EMR Serverless Anwendungsprotokolle sicher für maximal 30 Tage im von Amazon EMR verwalteten Speicher. **Anmerkung** Wenn Sie die Standardoption deaktivieren, kann Amazon EMR Ihre Jobs nicht in Ihrem Namen beheben. Beispiel: Sie können nicht von der EMR Serverless Console aus auf Spark-UI zugreifen. Um diese Option in EMR Studio zu deaktivieren, deaktivieren Sie ** AWS auf der **Seite Job einreichen** im Abschnitt **Zusätzliche Einstellungen** das Kontrollkästchen Zulassen, Protokolle für 30 Tage aufzubewahren**. Um diese Option von zu deaktivieren AWS CLI, verwenden Sie die `managedPersistenceMonitoringConfiguration` Konfiguration, wenn Sie eine Jobausführung einreichen. ``` { "monitoringConfiguration": { "managedPersistenceMonitoringConfiguration": { "enabled": false } } } ``` Wenn sich Ihre EMR Serverless-Anwendung in einem privaten Subnetz mit VPC-Endpunkten für Amazon S3 befindet und Sie eine Endpunktrichtlinie zur Zugriffskontrolle anhängen, fügen Sie die folgenden Berechtigungen für EMR Serverless zum Speichern und Bereitstellen von Anwendungsprotokollen hinzu. Ersetzen Sie sie durch die `AppInfo` Buckets aus der Tabelle `Resource` mit den verfügbaren Regionen in [Beispielrichtlinien für private Subnetze, die auf Amazon S3 zugreifen](https://docs.aws.amazon.com/emr/latest/ManagementGuide/private-subnet-iampolicy.html#private-subnet-iampolicy-regions). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "EMRServerlessManagedLogging", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:PutObjectAcl" ], "Resource": [ "arn:aws:s3:::prod.us-east-1.appinfo.src", "arn:aws:s3:::prod.us-east-1.appinfo.src/*" ], "Condition": { "StringEquals": { "aws:PrincipalServiceName": "emr-serverless.amazonaws.com", "aws:SourceVpc": "vpc-12345678" } } } ] } ``` ------ Verwenden Sie außerdem den `aws:SourceVpc` Bedingungsschlüssel, um sicherzustellen, dass die Anfrage die VPC durchläuft, an die der VPC-Endpunkt angeschlossen ist. ## Protokollierung für EMR Serverless mit Amazon S3 S3-Buckets Bevor Ihre Jobs Protokolldaten an Amazon S3 senden können, müssen Sie die folgenden Berechtigungen in die Berechtigungsrichtlinie für die Job-Runtime-Rolle aufnehmen. `amzn-s3-demo-logging-bucket`Ersetzen Sie es durch den Namen Ihres Logging-Buckets. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket/*" ], "Sid": "AllowS3Putobject" } ] } ``` ------ Um einen Amazon S3 S3-Bucket zum Speichern von Protokollen einzurichten AWS CLI, verwenden Sie die `s3MonitoringConfiguration` Konfiguration, wenn Sie einen Joblauf starten. Geben Sie dazu `--configuration-overrides` in der Konfiguration Folgendes an. ``` { "monitoringConfiguration": { "s3MonitoringConfiguration": { "logUri": "s3://amzn-s3-demo-logging-bucket/logs/" } } } ``` Bei Batch-Jobs, für die keine Wiederholungsversuche aktiviert sind, sendet EMR Serverless die Protokolle an den folgenden Pfad: ``` '/applications//jobs/' ``` Spark-Treiberprotokolle werden von EMR Serverless im folgenden Pfad gespeichert ``` '/applications//jobs//SPARK_DRIVER/' ``` Spark-Executor-Logs werden von EMR Serverless im folgenden Pfad gespeichert ``` '/applications//jobs//SPARK_EXECUTOR/' ``` Das ist eine Ganzzahl. EMR Serverless Releases 7.1.0 und höher unterstützen Wiederholungsversuche für Streaming-Jobs und Batch-Jobs. Wenn Sie einen Job mit aktivierten Wiederholungsversuchen ausführen, fügt EMR Serverless dem Protokollpfadpräfix automatisch eine Versuchsnummer hinzu, sodass Sie Protokolle besser unterscheiden und verfolgen können. ``` '/applications//jobs//attempts//' ``` ## Protokollierung für EMR Serverless mit Amazon CloudWatch Wenn Sie einen Job an eine EMR Serverless-Anwendung senden, wählen Sie Amazon CloudWatch als Option zum Speichern Ihrer Bewerbungsprotokolle. Auf diese Weise können Sie Protokollanalysefunktionen wie CloudWatch CloudWatch Logs Insights und Live Tail verwenden. Sie können Protokolle auch von CloudWatch anderen Systemen streamen, z. B. OpenSearch zur weiteren Analyse. EMR Serverless bietet Echtzeitprotokollierung für Treiberprotokolle. Sie können in Echtzeit mit der CloudWatch Live-Tail-Funktion oder über CloudWatch CLI-Tail-Befehle auf die Protokolle zugreifen. Standardmäßig ist die CloudWatch Protokollierung für EMR Serverless deaktiviert. Um es zu aktivieren, verwenden Sie die Konfiguration in. [AWS CLI](#jobs-log-storage-cw-cli) **Anmerkung** Amazon CloudWatch veröffentlicht Protokolle in Echtzeit, sodass mehr Ressourcen von Mitarbeitern benötigt werden. Wenn Sie sich für eine geringe Arbeitskapazität entscheiden, kann sich die Auswirkung auf die Laufzeit Ihres Jobs erhöhen. Wenn Sie die CloudWatch Protokollierung aktivieren, empfehlen wir Ihnen, eine höhere Arbeitskapazität zu wählen. Es ist auch möglich, dass die Protokollveröffentlichung drosselt, wenn die Transaktionsrate pro Sekunde (TPS) für `PutLogEvents` zu niedrig ist. Die CloudWatch Drosselungskonfiguration gilt global für alle Dienste, einschließlich EMR Serverless. Weitere Informationen finden Sie unter [Wie stelle ich die Drosselung in meinen Protokollen fest? CloudWatch ](https://repost.aws/knowledge-center/cloudwatch-logs-throttling) *auf AWS re:post.* ### Erforderliche Berechtigungen für das Loggen mit CloudWatch Bevor Ihre Jobs Protokolldaten an Amazon senden können CloudWatch, müssen Sie die folgenden Berechtigungen in die Berechtigungsrichtlinie für die Job-Runtime-Rolle aufnehmen. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:DescribeLogGroups" ], "Resource": [ "arn:aws:logs:*:123456789012:*" ], "Sid": "AllowLOGSDescribeloggroups" }, { "Effect": "Allow", "Action": [ "logs:PutLogEvents", "logs:CreateLogGroup", "logs:CreateLogStream", "logs:DescribeLogStreams" ], "Resource": [ "arn:aws:logs:*:123456789012:log-group:my-log-group-name:*" ], "Sid": "AllowLOGSPutlogevents" } ] } ``` ------ ### AWS CLI CloudWatch Um Amazon so einzurichten, dass Protokolle für EMR Serverless von gespeichert werden AWS CLI, verwenden Sie die `cloudWatchLoggingConfiguration` Konfiguration, wenn Sie einen Joblauf starten. Geben Sie dazu die folgenden Konfigurationsüberschreibungen an. Geben Sie optional auch einen Protokollgruppennamen, einen Protokollstream-Präfixnamen, Protokolltypen und einen Verschlüsselungsschlüssel-ARN an. Wenn Sie die optionalen Werte nicht angeben, werden die Protokolle in einer Standardprotokollgruppe `/aws/emr-serverless` mit dem Standardprotokollstream CloudWatch veröffentlicht`/applications/applicationId/jobs/jobId/worker-type`. EMR Serverless Releases 7.1.0 und höher unterstützen Wiederholungsversuche für Streaming-Jobs und Batch-Jobs. Wenn Sie Wiederholungsversuche für einen Job aktiviert haben, fügt EMR Serverless dem Protokollpfadpräfix automatisch eine Versuchsnummer hinzu, sodass Sie Protokolle besser unterscheiden und verfolgen können. ``` '/applications//jobs//attempts//worker-type' ``` Im Folgenden wird die Mindestkonfiguration veranschaulicht, die erforderlich ist, um die CloudWatch Amazon-Protokollierung mit den Standardeinstellungen für EMR Serverless zu aktivieren: ``` { "monitoringConfiguration": { "cloudWatchLoggingConfiguration": { "enabled": true } } } ``` Das folgende Beispiel zeigt alle erforderlichen und optionalen Konfigurationen, die angeben, wann Sie die CloudWatch Amazon-Protokollierung für EMR Serverless aktivieren. Die unterstützten `logTypes` Werte sind auch im folgenden Beispiel aufgeführt. ``` { "monitoringConfiguration": { "cloudWatchLoggingConfiguration": { "enabled": true, // Required "logGroupName": "Example_logGroup", // Optional "logStreamNamePrefix": "Example_logStream", // Optional "encryptionKeyArn": "key-arn", // Optional "logTypes": { "SPARK_DRIVER": ["stdout", "stderr"] //List of values } } } } ``` Standardmäßig veröffentlicht EMR Serverless nur die Treiber-Stdout- und Stderr-Protokolle. CloudWatch Wenn Sie andere Protokolle verwenden möchten, geben Sie im Feld eine Container-Rolle und die entsprechenden Protokolltypen an. `logTypes` In der folgenden Liste sind die unterstützten Worker-Typen aufgeführt, die für die `logTypes` Konfiguration angegeben wurden: **Spark** + `SPARK_DRIVER : ["STDERR", "STDOUT"]` + `SPARK_EXECUTOR : ["STDERR", "STDOUT"]` **Hive** + `HIVE_DRIVER : ["STDERR", "STDOUT", "HIVE_LOG", "TEZ_AM"]` + `TEZ_TASK : ["STDERR", "STDOUT", "SYSTEM_LOGS"]` # Rotierende Protokolle Amazon EMR Serverless kann Spark-Anwendungsprotokolle und Ereignisprotokolle rotieren. Die Protokollrotation hilft bei dem Problem, dass lange laufende Jobs große Protokolldateien erzeugen, die Ihren gesamten Festplattenspeicher beanspruchen können. Durch das Rotieren von Protokollen können Sie Festplattenspeicher sparen und die Anzahl der fehlgeschlagenen Jobs reduzieren, da Sie keinen Speicherplatz mehr auf Ihrer Festplatte haben. Die Protokollrotation ist standardmäßig aktiviert und nur für Spark-Jobs verfügbar. **Spark-Ereignisprotokolle** **Anmerkung** Die Rotation des Spark-Ereignisprotokolls ist für alle Amazon EMR-Release-Labels verfügbar. Anstatt eine einzelne Ereignisprotokolldatei zu generieren, rotiert EMR Serverless das Ereignisprotokoll in regelmäßigen Zeitintervallen und entfernt die älteren Ereignisprotokolldateien. Das Rotieren von Protokollen wirkt sich nicht auf die in den S3-Bucket hochgeladenen Protokolle aus. **Spark-Anwendungsprotokolle** **Anmerkung** Die Rotation der Spark-Anwendungsprotokolle ist für alle Amazon EMR-Release-Labels verfügbar. EMR Serverless rotiert auch die Spark-Anwendungsprotokolle für Treiber und Executoren, wie z. B. AND-Dateien. `stdout` `stderr` Sie können auf die neuesten Protokolldateien zugreifen, indem Sie die Log-Links in Studio auswählen, indem Sie die Links zum Spark History Server und zur Live-Benutzeroberfläche verwenden. Protokolldateien sind die gekürzten Versionen der neuesten Protokolle. Um auf die älteren rotierten Protokolle zu verweisen, geben Sie beim Speichern von Protokollen einen Amazon S3 S3-Speicherort an. Weitere Informationen finden Sie unter [Logging for EMR Serverless with Amazon S3 Buckets](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/logging.html#jobs-log-storage-s3-buckets). Die neuesten Protokolldateien finden Sie am folgenden Speicherort. EMR Serverless aktualisiert die Dateien alle 15 Sekunden. Diese Dateien können zwischen 0 MB und 128 MB liegen. ``` /applications//jobs//SPARK_DRIVER/stderr.gz ``` Der folgende Speicherort enthält die älteren rotierten Dateien. Jede Datei ist 128 MB groß. ``` /applications//jobs//SPARK_DRIVER/archived/stderr_.gz ``` Das gleiche Verhalten gilt auch für Spark-Executoren. Diese Änderung gilt nur für die S3-Protokollierung. Durch die Protokollrotation werden keine Änderungen an den auf Amazon hochgeladenen Protokollstreams vorgenommen CloudWatch. EMR Serverless Releases 7.1.0 und höher unterstützen Wiederholungsversuche für Streaming- und Batch-Jobs. Wenn Sie für Ihren Job Wiederholungsversuche aktiviert haben, fügt EMR Serverless dem Protokollpfad für solche Jobs ein Präfix hinzu, sodass Sie die Protokolle besser verfolgen und voneinander unterscheiden können. Dieser Pfad enthält alle rotierten Protokolle. ``` '/applications//jobs//attempts//'. ``` # Protokolle verschlüsseln ## Verschlüsselung von serverlosen EMR-Protokollen mit verwaltetem Speicher Um Protokolle im verwalteten Speicher mit Ihrem eigenen KMS-Schlüssel zu verschlüsseln, verwenden Sie die `managedPersistenceMonitoringConfiguration` Konfiguration, wenn Sie eine Jobausführung einreichen. ``` { "monitoringConfiguration": { "managedPersistenceMonitoringConfiguration" : { "encryptionKeyArn": "key-arn" } } } ``` ## Verschlüsselung von serverlosen EMR-Protokollen mit Amazon S3 S3-Buckets Um Logs in Ihrem Amazon S3 S3-Bucket mit Ihrem eigenen KMS-Schlüssel zu verschlüsseln, verwenden Sie die `s3MonitoringConfiguration` Konfiguration, wenn Sie eine Jobausführung einreichen. ``` { "monitoringConfiguration": { "s3MonitoringConfiguration": { "logUri": "s3://amzn-s3-demo-logging-bucket/logs/", "encryptionKeyArn": "key-arn" } } } ``` ## Verschlüsselung von serverlosen EMR-Protokollen mit Amazon CloudWatch Um Protokolle in Amazon CloudWatch mit Ihrem eigenen KMS-Schlüssel zu verschlüsseln, verwenden Sie die `cloudWatchLoggingConfiguration` Konfiguration, wenn Sie einen Job-Lauf einreichen. ``` { "monitoringConfiguration": { "cloudWatchLoggingConfiguration": { "enabled": true, "encryptionKeyArn": "key-arn" } } } ``` ## Erforderliche Berechtigungen für die Protokollverschlüsselung **Topics** + [Erforderliche Benutzerberechtigungen](#jobs-log-encryption-permissions-user) + [Berechtigungen für Verschlüsselungsschlüssel für Amazon S3 und verwalteten Speicher](#jobs-log-encryption-permissions-s3) + [Berechtigungen für Verschlüsselungsschlüssel für Amazon CloudWatch](#jobs-log-encryption-permissions-cw) ### Erforderliche Benutzerberechtigungen Der Benutzer, der den Job einreicht oder die Protokolle oder die Anwendung ansieht, UIs muss über die erforderlichen Berechtigungen zur Verwendung des Schlüssels verfügen. Sie können die Berechtigungen entweder in der KMS-Schlüsselrichtlinie oder in der IAM-Richtlinie für den Benutzer, die Gruppe oder die Rolle angeben. Wenn der Benutzer, der den Job einreicht, nicht über die KMS-Schlüsselberechtigungen verfügt, lehnt EMR Serverless die Übermittlung der Auftragsausführung ab. **Beispiel für eine Schlüsselrichtlinie** Die folgende Schlüsselrichtlinie stellt die Berechtigungen für `kms:GenerateDataKey` und bereit`kms:Decrypt`: ``` { "Effect": "Allow", "Principal":{ "AWS": "arn:aws:iam::111122223333:user/user-name" }, "Action": [ "kms:GenerateDataKey", "kms:Decrypt" ], "Resource": "*" } ``` **Beispiel für eine IAM-Richtlinie** Die folgende IAM-Richtlinie bietet die Berechtigungen für `kms:GenerateDataKey` und`kms:Decrypt`: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kms:GenerateDataKey", "kms:Decrypt" ], "Resource": [ "arn:aws:kms:*:123456789012:key/12345678-1234-1234-1234-123456789012" ], "Sid": "AllowKMSGeneratedatakey" } ] } ``` ------ Um die Spark- oder Tez-Benutzeroberfläche zu starten, geben Sie Ihren Benutzern, Gruppen oder Rollen die folgenden Zugriffsberechtigungen für die `emr-serverless:GetDashboardForJobRun` API: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "emr-serverless:GetDashboardForJobRun" ], "Resource": [ "*" ], "Sid": "AllowEMRSERVERLESSGetdashboardforjobrun" } ] } ``` ------ ### Berechtigungen für Verschlüsselungsschlüssel für Amazon S3 und verwalteten Speicher Wenn Sie Protokolle mit Ihrem eigenen Verschlüsselungsschlüssel entweder im verwalteten Speicher oder in Ihren S3-Buckets verschlüsseln, konfigurieren Sie die KMS-Schlüsselberechtigungen wie folgt. Der `emr-serverless.amazonaws.com` Prinzipal muss in der Richtlinie für den KMS-Schlüssel über die folgenden Berechtigungen verfügen: ``` { "Effect": "Allow", "Principal":{ "Service": "emr-serverless.amazonaws.com" }, "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": "*" "Condition": { "StringLike": { "aws:SourceArn": "arn:aws:emr-serverless:region:aws-account-id:/applications/application-id" } } } ``` Aus Sicherheitsgründen empfehlen wir, der KMS-Schlüsselrichtlinie einen `aws:SourceArn` Bedingungsschlüssel hinzuzufügen. Der globale IAM-Bedingungsschlüssel `aws:SourceArn` trägt dazu bei, dass EMR Serverless den KMS-Schlüssel nur für einen Anwendungs-ARN verwendet. Die IAM-Richtlinie der Job-Runtime-Rolle muss über die folgenden Berechtigungen verfügen: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kms:GenerateDataKey", "kms:Decrypt" ], "Resource": [ "arn:aws:kms:*:123456789012:key/12345678-1234-1234-1234-123456789012" ], "Sid": "AllowKMSGeneratedatakey" } ] } ``` ------ ### Berechtigungen für Verschlüsselungsschlüssel für Amazon CloudWatch Verwenden Sie die folgende IAM-Richtlinie für die Job-Runtime-Rolle, um den KMS-Schlüssel-ARN Ihrer Protokollgruppe zuzuordnen. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:AssociateKmsKey" ], "Resource": [ "arn:aws:logs:*:123456789012:log-group:my-log-group-name:*" ], "Sid": "AllowLOGSAssociatekmskey" } ] } ``` ------ Konfigurieren Sie die KMS-Schlüsselrichtlinie, um Amazon KMS-Berechtigungen zu gewähren CloudWatch: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "key-default-1", "Statement": [ { "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": [ "*" ], "Condition": { "ArnLike": { "kms:EncryptionContext:aws:logs:arn": "arn:aws:logs:*:123456789012:*" } }, "Sid": "AllowKMSDecrypt" } ] } ``` ------ # Apache Log4j2-Eigenschaften für Amazon EMR Serverless konfigurieren Auf dieser Seite wird beschrieben, wie Sie benutzerdefinierte [Apache Log4j 2.x-Eigenschaften](https://logging.apache.org/log4j/2.x/) für EMR Serverless-Jobs unter konfigurieren. `StartJobRun` Wenn Sie Log4j-Klassifizierungen auf Anwendungsebene konfigurieren möchten, finden Sie weitere Informationen unter. [Standardanwendungskonfiguration für EMR Serverless](default-configs.md) ## Konfigurieren Sie die Spark Log4J2-Eigenschaften für Amazon EMR Serverless Mit den Amazon EMR-Versionen 6.8.0 und höher können Sie die Eigenschaften von [Apache Log4j 2.x](https://logging.apache.org/log4j/2.x/) anpassen, um detaillierte Protokollkonfigurationen zu spezifizieren. Dies vereinfacht die Fehlerbehebung Ihrer Spark-Jobs auf EMR Serverless. Verwenden Sie die Klassifizierungen `spark-driver-log4j2` und`spark-executor-log4j2`, um diese Eigenschaften zu konfigurieren. **Topics** + [Log4j2-Klassifizierungen für Spark](#log4j2-spark-class) + [Log4j2-Konfigurationsbeispiel für Spark](#log4j2-spark-example) + [Log4j2 in Spark-Beispielaufträgen](#log4j2-spark-jobs) + [Überlegungen zu Log4j2 für Spark](#log4j2-spark-considerations) ### Log4j2-Klassifizierungen für Spark Um die Spark-Protokollkonfigurationen anzupassen, verwenden Sie die folgenden Klassifizierungen mit. [https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_ConfigurationOverrides.html#emrserverless-Type-ConfigurationOverrides-applicationConfiguration](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_ConfigurationOverrides.html#emrserverless-Type-ConfigurationOverrides-applicationConfiguration) Verwenden Sie Folgendes, um die Log4j 2.x-Eigenschaften zu konfigurieren. [https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_Configuration.html#emrserverless-Type-Configuration-properties](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_Configuration.html#emrserverless-Type-Configuration-properties) **`spark-driver-log4j2`** Diese Klassifizierung legt die Werte in der `log4j2.properties` Datei für den Treiber fest. **`spark-executor-log4j2`** Diese Klassifizierung legt die Werte in der `log4j2.properties` Datei für den Executor fest. ### Log4j2-Konfigurationsbeispiel für Spark Das folgende Beispiel zeigt, wie Sie einen Spark-Job einreichen, `applicationConfiguration` um die Log4J2-Konfigurationen für den Spark-Treiber und -Executor anzupassen. Informationen zur Konfiguration von Log4j-Klassifizierungen auf Anwendungsebene und nicht erst, wenn Sie den Job einreichen, finden Sie unter. [Standardanwendungskonfiguration für EMR Serverless](default-configs.md) ``` aws emr-serverless start-job-run \ --application-id application-id \ --execution-role-arn job-role-arn \ --job-driver '{ "sparkSubmit": { "entryPoint": "/usr/lib/spark/examples/jars/spark-examples.jar", "entryPointArguments": ["1"], "sparkSubmitParameters": "--class org.apache.spark.examples.SparkPi --conf spark.executor.cores=4 --conf spark.executor.memory=20g --conf spark.driver.cores=4 --conf spark.driver.memory=8g --conf spark.executor.instances=1" } }' --configuration-overrides '{ "applicationConfiguration": [ { "classification": "spark-driver-log4j2", "properties": { "rootLogger.level":"error", // will only display Spark error logs "logger.IdentifierForClass.name": "classpath for setting logger", "logger.IdentifierForClass.level": "info" } }, { "classification": "spark-executor-log4j2", "properties": { "rootLogger.level":"error", // will only display Spark error logs "logger.IdentifierForClass.name": "classpath for setting logger", "logger.IdentifierForClass.level": "info" } } ] }' ``` ### Log4j2 in Spark-Beispielaufträgen Die folgenden Codebeispiele zeigen, wie Sie eine Spark-Anwendung erstellen, während Sie eine benutzerdefinierte Log4j2-Konfiguration für die Anwendung initialisieren. ------ #### [ Python ] **Example - Log4j2 für einen Spark-Job mit Python verwenden** ``` import os import sys from pyspark import SparkConf, SparkContext from pyspark.sql import SparkSession app_name = "PySparkApp" if __name__ == "__main__": spark = SparkSession\ .builder\ .appName(app_name)\ .getOrCreate() spark.sparkContext._conf.getAll() sc = spark.sparkContext log4jLogger = sc._jvm.org.apache.log4j LOGGER = log4jLogger.LogManager.getLogger(app_name) LOGGER.info("pyspark script logger info") LOGGER.warn("pyspark script logger warn") LOGGER.error("pyspark script logger error") // your code here spark.stop() ``` Verwenden Sie die folgende Konfiguration, um Log4j2 für den Treiber anzupassen, wenn Sie einen Spark-Job ausführen: ``` { "classification": "spark-driver-log4j2", "properties": { "rootLogger.level":"error", // only display Spark error logs "logger.PySparkApp.level": "info", "logger.PySparkApp.name": "PySparkApp" } } ``` ------ #### [ Scala ] **Example - Verwenden von Log4j2 für einen Spark-Job mit Scala** ``` import org.apache.log4j.Logger import org.apache.spark.sql.SparkSession object ExampleClass { def main(args: Array[String]): Unit = { val spark = SparkSession .builder .appName(this.getClass.getName) .getOrCreate() val logger = Logger.getLogger(this.getClass); logger.info("script logging info logs") logger.warn("script logging warn logs") logger.error("script logging error logs") // your code here spark.stop() } } ``` Verwenden Sie die folgende Konfiguration, um Log4j2 für den Treiber anzupassen, wenn Sie einen Spark-Job ausführen: ``` { "classification": "spark-driver-log4j2", "properties": { "rootLogger.level":"error", // only display Spark error logs "logger.ExampleClass.level": "info", "logger.ExampleClass.name": "ExampleClass" } } ``` ------ ### Überlegungen zu Log4j2 für Spark Die folgenden Log4j2.x-Eigenschaften sind für Spark-Prozesse nicht konfigurierbar: + `rootLogger.appenderRef.stdout.ref` + `appender.console.type` + `appender.console.name` + `appender.console.target` + `appender.console.layout.type` + `appender.console.layout.pattern` [Ausführliche Informationen zu den Log4j2.x-Eigenschaften, die konfiguriert werden, finden Sie in der Datei unter. `log4j2.properties.template`](https://github.com/apache/spark/blob/v3.3.0/conf/log4j2.properties.template) GitHub # Serverlose EMR-Überwachung In diesem Abschnitt wird beschrieben, wie Sie Ihre Amazon EMR Serverless-Anwendungen und -Jobs überwachen können. **Topics** + [Überwachung von serverlosen EMR-Anwendungen und -Jobs](app-job-metrics.md) + [Überwachen Sie Spark-Metriken mit Amazon Managed Service für Prometheus](monitor-with-prometheus.md) + [Metriken zur serverlosen Nutzung von EMR](monitoring-usage.md) # Überwachung von serverlosen EMR-Anwendungen und -Jobs Mit Amazon CloudWatch Metrics for EMR Serverless können Sie CloudWatch Metriken von einer Minute erhalten und auf CloudWatch Dashboards zugreifen, um auf den near-real-time Betrieb und die Leistung Ihrer EMR Serverless-Anwendungen zuzugreifen. EMR Serverless sendet Metriken an CloudWatch jede Minute. EMR Serverless gibt diese Metriken auf Anwendungsebene sowie auf Job-, Worker-Typ- und Arbeitsebene aus. capacity-allocation-type Verwenden Sie zunächst die EMR Serverless CloudWatch Dashboard-Vorlage, die im EMR [ GitHub Serverless-Repository bereitgestellt wird, und stellen](https://github.com/aws-samples/emr-serverless-samples/tree/main/cloudformation/emr-serverless-cloudwatch-dashboard/) Sie sie bereit. **Anmerkung** Bei [serverlosen interaktiven EMR-Workloads](interactive-workloads.md) ist nur die Überwachung auf Anwendungsebene aktiviert und sie verfügen über eine neue Worker-Typ-Dimension. `Spark_Kernel` Um Ihre interaktiven Workloads zu überwachen und zu debuggen, greifen Sie von [Ihrem EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-studio-debug.html#emr-studio-debug-serverless) Studio Workspace aus auf die Protokolle und die Apache Spark-Benutzeroberfläche zu. ## Überwachung von Kennzahlen **Wichtig** Wir strukturieren die Anzeige unserer Kennzahlen neu, um Dimensionen hinzuzufügen `ApplicationName` und `JobName` sie als Dimensionen hinzuzufügen. Für Version 7.10 und höher werden die älteren Metriken nicht mehr aktualisiert. Für EMR-Versionen unter 7.10 sind die älteren Metriken weiterhin verfügbar. **Aktuelle Abmessungen** In der folgenden Tabelle werden die im Namespace verfügbaren EMR-Serverless-Dimensionen beschrieben. `AWS/EMR Serverless` **Dimensionen für EMR Serverless-Metriken** | Dimension | Description | | --- | --- | | ApplicationId | Filtert nach allen Metriken einer serverlosen EMR-Anwendung unter Verwendung der Anwendungs-ID. | | ApplicationName | Filtert nach allen Metriken einer serverlosen EMR-Anwendung, die den Namen verwenden. **Wenn der Name nicht angegeben wird oder Nicht-ASCII-Zeichen enthält, wird er als [Unspecified] veröffentlicht.** | | JobId | Filtert nach allen Metriken eines EMR Serverless die Job-Run-ID. | | JobName | Filtert nach allen Metriken eines EMR Serverless-Jobs, der unter Verwendung des Namens ausgeführt wird. **Wenn der Name nicht angegeben wird oder Nicht-ASCII-Zeichen enthält, wird er als [Unspecified] veröffentlicht.** | | WorkerType | Filtert nach allen Metriken eines bestimmten Arbeitertyps. Sie können beispielsweise nach `SPARK_DRIVER` und `SPARK_EXECUTORS` nach Spark-Jobs filtern. | | CapacityAllocationType | Filtert nach allen Metriken eines bestimmten Kapazitätszuweisungstyps. Sie können beispielsweise nach `PreInitCapacity` vorinitialisierter Kapazität und `OnDemandCapacity` nach allem anderen filtern. | ## Überwachung auf Anwendungsebene Sie können die Kapazitätsnutzung auf Ebene der EMR-Serverless-Anwendung mit CloudWatch Amazon-Metriken überwachen. Sie können auch eine einzige Anzeige zur Überwachung der Anwendungskapazitätsnutzung in einem CloudWatch Dashboard einrichten. **Metriken für serverlose EMR-Anwendungen** | Metrik | Description | Einheit | Dimension | | --- | --- | --- | --- | | MaxCPUAllowed | Die maximal zulässige CPU-Anzahl für die Anwendung. | vCPU | ApplicationId, ApplicationName | | MaxMemoryAllowed | Der maximal zulässige Arbeitsspeicher in GB für die Anwendung. | Gigabyte (GB) | ApplicationId, ApplicationName | | MaxStorageAllowed | Der maximal zulässige Speicherplatz in GB für die Anwendung. | Gigabyte (GB) | ApplicationId, ApplicationName | | CPUAllocated | Die Gesamtzahl der zugewiesenen V. CPUs | vCPU | ApplicationId, ApplicationName, WorkerType, CapacityAllocationType | | IdleWorkerCount | Die Gesamtzahl der untätigen Arbeitnehmer. | Anzahl | ApplicationId, ApplicationName, WorkerType, CapacityAllocationType | | MemoryAllocated | Der gesamte zugewiesene Speicher in GB. | Gigabyte (GB) | ApplicationId, ApplicationName, WorkerType, CapacityAllocationType | | PendingCreationWorkerCount | Die Gesamtzahl der Mitarbeiter, deren Erstellung noch aussteht. | Anzahl | ApplicationId, ApplicationName, WorkerType, CapacityAllocationType | | RunningWorkerCount | Die Gesamtzahl der Mitarbeiter, die von der Anwendung verwendet werden. | Anzahl | ApplicationId, ApplicationName, WorkerType, CapacityAllocationType | | StorageAllocated | Der gesamte zugewiesene Festplattenspeicher in GB. | Gigabyte (GB) | ApplicationId, ApplicationName, WorkerType, CapacityAllocationType | | TotalWorkerCount | Die Anzahl der insgesamt verfügbaren Arbeitskräfte. | Anzahl | ApplicationId, ApplicationName, WorkerType, CapacityAllocationType | ## Überwachung auf Arbeitsebene Amazon EMR Serverless sendet jede Minute die folgenden Metriken auf Amazon CloudWatch Auftragsebene. Sie können auf die Metrikwerte für aggregierte Auftragsausführungen nach Status der Auftragsausführung zugreifen. Die Einheit für jede der Metriken ist *Anzahl*. **EMR Serverless Metriken auf Jobebene** | Metrik | Description | Dimension | | --- | --- | --- | | SubmittedJobs | Die Anzahl der Jobs mit dem Status „Gesendet“. | ApplicationId, ApplicationName | | PendingJobs | Die Anzahl der Jobs mit dem Status Ausstehend. | ApplicationId, ApplicationName | | ScheduledJobs | Die Anzahl der Jobs mit dem Status „Geplant“. | ApplicationId, ApplicationName | | RunningJobs | Die Anzahl der Jobs im Status Wird ausgeführt. | ApplicationId, ApplicationName | | SuccessJobs | Die Anzahl der Jobs im Status Erfolgreich. | ApplicationId, ApplicationName | | FailedJobs | Die Anzahl der Jobs mit dem Status Fehlgeschlagen. | ApplicationId, ApplicationName | | CancellingJobs | Die Anzahl der Jobs mit dem Status „Storniert“. | ApplicationId, ApplicationName | | CancelledJobs | Die Anzahl der Jobs mit dem Status Storniert. | ApplicationId, ApplicationName | Sie können Engine-spezifische Metriken für ausgeführte und abgeschlossene EMR Serverless-Jobs mit einer Engine-spezifischen Anwendung überwachen. UIs Wenn Sie auf die Benutzeroberfläche für einen laufenden Job zugreifen, wird die Benutzeroberfläche der Live-Anwendung mit Aktualisierungen in Echtzeit angezeigt. Wenn Sie auf die Benutzeroberfläche für einen abgeschlossenen Job zugreifen, wird die persistente App-Benutzeroberfläche angezeigt. **Ausführen von Aufgaben** Greifen Sie für Ihre laufenden EMR Serverless-Jobs auf eine Echtzeitschnittstelle zu, die Engine-spezifische Metriken bereitstellt. Sie können entweder die Apache Spark-Benutzeroberfläche oder die Hive Tez-Benutzeroberfläche verwenden, um Ihre Jobs zu überwachen und zu debuggen. Um auf diese zuzugreifen UIs, verwenden Sie die EMR Studio-Konsole oder fordern Sie einen sicheren URL-Endpunkt mit dem an AWS Command Line Interface. **Abgeschlossene Jobs** Verwenden Sie für Ihre abgeschlossenen EMR Serverless-Jobs den Spark History Server oder die Persistent Hive Tez-Benutzeroberfläche, um auf Jobdetails, Phasen, Aufgaben und Metriken für Spark- oder Hive-Jobausführungen zuzugreifen. Um auf diese zuzugreifen UIs, verwenden Sie die EMR Studio-Konsole oder fordern Sie einen sicheren URL-Endpunkt mit dem AWS Command Line Interface an. ## Überwachung auf Arbeitgeberebene Amazon EMR Serverless sendet die folgenden Metriken auf Job-Worker-Ebene, die im `AWS/EMRServerless` Namespace und in der `Job Worker Metrics` Metrikgruppe verfügbar sind, an Amazon. CloudWatch EMR Serverless sammelt Datenpunkte von einzelnen Mitarbeitern während der Auftragsausführung auf Auftragsebene, Arbeitstyp und Ebene. capacity-allocation-type Sie können diese Dimension verwenden`ApplicationId`, um mehrere Jobs zu überwachen, die zu derselben Anwendung gehören. **Anmerkung** Um bei der Anzeige der Metriken in der CloudWatch Amazon-Konsole den gesamten CPU- und Speicherverbrauch eines EMR-Serverless-Jobs anzuzeigen, verwenden Sie die Statistik als Summe und Zeitraum als 1 Minute. **EMR Serverless Job Metriken auf Mitarbeiterebene** | Metrik | Description | Einheit | Dimension | | --- | --- | --- | --- | | WorkerCpuAllocated | Die Gesamtzahl der vCPU-Kerne, die Workern in einer Jobausführung zugewiesen wurden. | vCPU | JobId, JobName, ApplicationId, ApplicationName, WorkerType, und CapacityAllocationType | | WorkerCpuUsed | Die Gesamtzahl der vCPU-Kerne, die von Workern in einem Joblauf verwendet werden. | vCPU | JobId, JobName, ApplicationId, ApplicationName, WorkerType, und CapacityAllocationType | | WorkerMemoryAllocated | Der Gesamtspeicher in GB, der Workern in einer Auftragsausführung zugewiesen wurde. | Gigabyte (GB) | JobId, JobName, ApplicationId, ApplicationName, WorkerType, und CapacityAllocationType | | WorkerMemoryUsed | Der gesamte Arbeitsspeicher in GB, der von Arbeitern bei einer Auftragsausführung genutzt wird. | Gigabyte (GB) | JobId, JobName, ApplicationId, ApplicationName, WorkerType, und CapacityAllocationType | | WorkerEphemeralStorageAllocated | Die Anzahl der Byte an flüchtigem Speicher, die Workern in einer Auftragsausführung zugewiesen wurden. | Gigabyte (GB) | JobId, JobName, ApplicationId, ApplicationName, WorkerType, und CapacityAllocationType | | WorkerEphemeralStorageUsed | Die Anzahl der Byte an flüchtigem Speicher, die von Arbeitern bei einer Auftragsausführung verwendet werden. | Gigabyte (GB) | JobId, JobName, ApplicationId, ApplicationName, WorkerType, und CapacityAllocationType | | WorkerStorageReadBytes | Die Anzahl der Byte, die von Arbeitern während einer Auftragsausführung aus dem Speicher gelesen wurden. | Bytes | JobId, JobName, ApplicationId, ApplicationName, WorkerType, und CapacityAllocationType | | WorkerStorageWriteBytes | Die Anzahl der Byte, die während einer Auftragsausführung von Workern in den Speicher geschrieben wurden. | Bytes | JobId, JobName, ApplicationId, ApplicationName, WorkerType, und CapacityAllocationType | In den folgenden Schritten wird beschrieben, wie Sie auf die verschiedenen Arten von Metriken zugreifen können. ------ #### [ Console ] **So greifen Sie mit der Konsole auf die Benutzeroberfläche Ihrer Anwendung zu** 1. Navigieren Sie zu Ihrer EMR Serverless-Anwendung im EMR Studio. Folgen Sie den Anweisungen unter [Erste Schritte von der Konsole aus](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/getting-started.html#gs-console). 1. So greifen Sie auf Engine-spezifische Anwendungen UIs und Protokolle für einen laufenden Job zu: 1. Wählen Sie einen Job mit einem Status aus`RUNNING`. 1. Wählen Sie die Job auf der Seite mit den **Bewerbungsdetails** aus, oder navigieren Sie zur Seite mit den **Stellendetails** für Ihre Stelle. 1. Wählen Sie im Dropdownmenü „**Benutzeroberfläche anzeigen**“ entweder **Spark UI** oder **Hive Tez UI** aus, um zur Anwendungsoberfläche für Ihren Jobtyp zu gelangen. 1. Um auf die Spark-Engine-Logs zuzugreifen, navigieren Sie in der Spark-Benutzeroberfläche zur Registerkarte **Executors** und wählen Sie den Link **Logs** für den Treiber. Um auf die Hive-Engine-Logs zuzugreifen, wählen Sie in der Hive Tez-Benutzeroberfläche den Link **Logs** für die entsprechende DAG. 1. So greifen Sie auf maschinenspezifische Anwendungen UIs und Protokolle für einen abgeschlossenen Job zu: 1. Wählen Sie einen Job mit einem Status aus`SUCCESS`. 1. Wählen Sie die Job auf der Seite mit den **Bewerbungsdetails** Ihrer Bewerbung aus oder navigieren Sie zur Seite mit den **Stellendetails** der Stelle. 1. Wählen Sie im Dropdownmenü „**Benutzeroberfläche anzeigen**“ entweder **Spark History Server** oder **Persistent Hive Tez UI** aus, um zur Anwendungsoberfläche für Ihren Jobtyp zu gelangen. 1. Um auf die Spark-Engine-Logs zuzugreifen, navigieren Sie in der Spark-Benutzeroberfläche zur Registerkarte **Executors** und wählen Sie den Link **Logs** für den Treiber. Um auf die Hive-Engine-Logs zuzugreifen, wählen Sie in der Hive Tez-Benutzeroberfläche den Link **Logs** für die entsprechende DAG. ------ #### [ AWS CLI ] **Um auf die Benutzeroberfläche Ihrer Anwendung zuzugreifen, verwenden Sie AWS CLI** + Rufen Sie die `GetDashboardForJobRun` API auf, um eine URL zu generieren, über die Sie auf die Benutzeroberfläche Ihrer Anwendung für laufende und abgeschlossene Jobs zugreifen können. ``` aws emr-serverless get-dashboard-for-job-run / --application-id / --job-run-id ``` Die URL, die Sie generieren, ist eine Stunde lang gültig. ------ # Überwachen Sie Spark-Metriken mit Amazon Managed Service für Prometheus Mit den Amazon EMR-Versionen 7.1.0 und höher können Sie EMR Serverless in Amazon Managed Service for Prometheus integrieren, um Apache Spark-Metriken für EMR Serverless-Jobs und -Anwendungen zu sammeln. Diese Integration ist verfügbar, wenn Sie einen Job einreichen oder eine Anwendung mit der AWS Konsole, der EMR Serverless API oder dem erstellen. AWS CLI ## Voraussetzungen Bevor Sie Ihre Spark-Metriken an Amazon Managed Service for Prometheus übermitteln können, müssen Sie die folgenden Voraussetzungen erfüllen. + [Erstellen Sie einen Amazon Managed Service for Prometheus Workspace.](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html) Dieser Workspace dient als Aufnahme-Endpunkt. Notieren Sie sich die URL, die für **Endpoint — Remote Write-URL** angezeigt wird. Sie müssen die URL angeben, wenn Sie Ihre EMR Serverless-Anwendung erstellen. + Um Amazon Managed Service for Prometheus zu Überwachungszwecken Zugriff auf Ihre Jobs zu gewähren, fügen Sie Ihrer Job-Ausführungsrolle die folgende Richtlinie hinzu. ``` { "Sid": "AccessToPrometheus", "Effect": "Allow", "Action": ["aps:RemoteWrite"], "Resource": "arn:aws:aps:::workspace/" } ``` ## Einrichtung **So verwenden Sie die AWS Konsole, um eine Anwendung zu erstellen, die in Amazon Managed Service for Prometheus integriert ist** 1. Informationen zum Erstellen einer Anwendung finden Sie unter [Erste Schritte mit Amazon EMR Serverless](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/getting-started.html ). 1. Wählen Sie beim Erstellen einer Anwendung die Option **Benutzerdefinierte Einstellungen verwenden** und konfigurieren Sie dann Ihre Anwendung, indem Sie die Informationen in die Felder eingeben, die Sie konfigurieren möchten. 1. Wählen Sie unter **Anwendungsprotokolle und Metriken** die Option **Engine-Metriken an Amazon Managed Service for Prometheus liefern** aus und geben Sie dann Ihre Remote-Write-URL an. 1. Geben Sie alle anderen gewünschten Konfigurationseinstellungen an und wählen Sie dann Anwendung **erstellen und starten**. **Verwenden Sie die AWS CLI oder EMR Serverless API** Sie können auch die AWS CLI oder EMR Serverless API verwenden, um Ihre EMR Serverless-Anwendung in Amazon Managed Service for Prometheus zu integrieren, wenn Sie die Befehle oder die Befehle ausführen. `create-application` `start-job-run` ------ #### [ create-application ] ``` aws emr-serverless create-application \ --release-label emr-7.1.0 \ --type "SPARK" \ --monitoring-configuration '{ "prometheusMonitoringConfiguration": { "remoteWriteUrl": "https://aps-workspaces..amazonaws.com/workspaces//api/v1/remote_write" } }' ``` ------ #### [ start-job-run ] ``` aws emr-serverless start-job-run \ --application-id \ --execution-role-arn \ --job-driver '{ "sparkSubmit": { "entryPoint": "local:///usr/lib/spark/examples/src/main/python/pi.py", "entryPointArguments": ["10000"], "sparkSubmitParameters": "--conf spark.dynamicAllocation.maxExecutors=10" } }' \ --configuration-overrides '{ "monitoringConfiguration": { "prometheusMonitoringConfiguration": { "remoteWriteUrl": "https://aps-workspaces..amazonaws.com/workspaces//api/v1/remote_write" } } }' ``` ------ Die Aufnahme `prometheusMonitoringConfiguration` in Ihrem Befehl bedeutet, dass EMR Serverless den Spark-Job mit einem Agenten ausführen muss, der die Spark-Metriken sammelt und sie auf Ihren `remoteWriteUrl` Endpunkt für Amazon Managed Service for Prometheus schreibt. Anschließend können Sie die Spark-Metriken in Amazon Managed Service for Prometheus für Visualisierungen, Benachrichtigungen und Analysen verwenden. ## Erweiterte Konfigurationseigenschaften EMR Serverless verwendet eine Komponente innerhalb von Spark, die `PrometheusServlet` zur Erfassung von Spark-Metriken benannt ist, und übersetzt Leistungsdaten in Daten, die mit Amazon Managed Service for Prometheus kompatibel sind. Standardmäßig legt EMR Serverless Standardwerte in Spark fest und analysiert Treiber- und Executor-Metriken, wenn Sie einen Job mit senden. `PrometheusMonitoringConfiguration` In der folgenden Tabelle werden alle Eigenschaften beschrieben, die konfiguriert werden, wenn ein Spark-Job übermittelt wird, der Metriken an Amazon Managed Service for Prometheus sendet. | Spark-Eigenschaft | Standardwert | Description | | --- | --- | --- | | spark.metrics.conf.\$1.sink.prometheusServlet.class | org.apache.spark.metrics.sink. PrometheusServlet | Die Klasse, die Spark verwendet, um Metriken an Amazon Managed Service for Prometheus zu senden. Um das Standardverhalten zu überschreiben, geben Sie Ihre eigene benutzerdefinierte Klasse an. | | spark.metrics.conf.\$1.source.jvm.class | org.apache.spark.metrics.source. JvmSource | Die Klasse, die Spark verwendet, um wichtige Metriken von der zugrunde liegenden virtuellen Java-Maschine zu sammeln und zu senden. Um die Erfassung von JVM-Metriken zu beenden, deaktivieren Sie diese Eigenschaft, indem Sie sie auf eine leere Zeichenfolge setzen, z. B. `""` Um das Standardverhalten zu überschreiben, geben Sie Ihre eigene benutzerdefinierte Klasse an. | | spark.metrics.conf.driver.sink.prometheusServlet.path | /metrics/prometheus | Die eindeutige URL, die Amazon Managed Service for Prometheus verwendet, um Metriken vom Treiber zu sammeln. Um das Standardverhalten zu überschreiben, geben Sie Ihren eigenen Pfad an. Um die Erfassung von Treibermetriken zu beenden, deaktivieren Sie diese Eigenschaft, indem Sie sie auf eine leere Zeichenfolge setzen, z. `""` B. | | spark.metrics.conf.executor.sink.prometheusServlet.path | /metrics/executor/prometheus | Die eindeutige URL, die Amazon Managed Service for Prometheus verwendet, um Metriken vom Testamentsvollstrecker zu sammeln. Um das Standardverhalten zu überschreiben, geben Sie Ihren eigenen Pfad an. Um die Erfassung von Executor-Metriken zu beenden, deaktivieren Sie diese Eigenschaft, indem Sie sie auf eine leere Zeichenfolge setzen, z. B. `""` | Weitere Informationen zu den Spark-Metriken finden Sie unter [Apache Spark-Metriken](https://spark.apache.org/docs/3.5.0/monitoring.html#metrics). ## Überlegungen und Einschränkungen Wenn Sie Amazon Managed Service for Prometheus verwenden, um Metriken von EMR Serverless zu sammeln, sollten Sie die folgenden Überlegungen und Einschränkungen berücksichtigen. + Support für die Verwendung von Amazon Managed Service for Prometheus mit EMR Serverless ist nur dort verfügbar, [AWS-Regionen wo Amazon Managed Service für Prometheus](https://docs.aws.amazon.com/general/latest/gr/prometheus-service.html) allgemein verfügbar ist. + Die Ausführung des Agenten zur Erfassung von Spark-Metriken auf Amazon Managed Service for Prometheus erfordert mehr Ressourcen von den Mitarbeitern. Wenn Sie eine kleinere Worker-Größe wählen, z. B. einen vCPU-Worker, kann sich Ihre Job-Laufzeit verlängern. + Support für die Verwendung von Amazon Managed Service for Prometheus mit EMR Serverless ist nur für Amazon EMR-Versionen 7.1.0 und höher verfügbar. + Amazon Managed Service for Prometheus muss in demselben Konto bereitgestellt werden, in dem Sie EMR Serverless ausführen, um Metriken zu sammeln. # Metriken zur serverlosen Nutzung von EMR Sie können die CloudWatch Amazon-Nutzungsmetriken verwenden, um einen Überblick über die Ressourcen zu erhalten, die Ihr Konto verwendet. Verwenden Sie diese Metriken, um Ihre Servicenutzung in CloudWatch Grafiken und Dashboards zu visualisieren. Die Metriken zur Nutzung von EMR Serverless entsprechen Service Quotas. Sie können Alarme konfigurieren, mit denen Sie benachrichtigt werden, wenn sich Ihre Nutzung einem Servicekontingent nähert. Weitere Informationen finden Sie unter [Service Quotas und CloudWatch Amazon-Alarme](https://docs.aws.amazon.com/servicequotas/latest/userguide/configure-cloudwatch.html) im *Service Quotas Quotas-Benutzerhandbuch*. Weitere Informationen zu EMR Serverless Service Quotas finden Sie unter. [Endpunkte und Kontingente für EMR Serverless](endpoints-quotas.md) ## Metriken zur Nutzung von Servicekontingenten für EMR Serverless EMR Serverless veröffentlicht die folgenden Messdaten zur Nutzung von Dienstkontingenten im `AWS/Usage` Namespace. **** | Metrik | Description | | --- | --- | | `ResourceCount` | Die Gesamtanzahl der angegebenen Ressource, die auf Ihrem Konto ausgeführt wird. Die Ressource wird durch die [Dimensionen](#usage-metrics-dimensions) definiert, die der Metrik zugeordnet sind. | ## Dimensionen für Metriken zur Nutzung der Kontingente für EMR Serverless Service Sie können die folgenden Dimensionen verwenden, um die von EMR Serverless veröffentlichten Nutzungsmetriken zu verfeinern. **** | Dimension | Wert | Description | | --- | --- | --- | | `Service` | EMR Serverlos | Der Name des AWS-Service , der die Ressource enthält. | | `Type` | Ressource | Der Entitätstyp, den EMR Serverless meldet. | | `Resource` | vCPU | Der Ressourcentyp, den EMR Serverless verfolgt. | | `Class` | Keine | Die Ressourcenklasse, die EMR Serverless verfolgt. | # Automatisierung von EMR Serverless mit Amazon EventBridge Sie können Amazon EventBridge damit Ihre Systemereignisse automatisieren AWS-Services und automatisch darauf reagieren, z. B. Probleme mit der Anwendungsverfügbarkeit oder Ressourcenänderungen. EventBridge liefert nahezu in Echtzeit einen Stream von Systemereignissen, die Änderungen an Ihren AWS Ressourcen beschreiben. Sie können einfache Regeln schreiben, um anzugeben, welche Ereignisse für Sie interessant sind und welche automatisierten Aktionen durchgeführt werden sollen, wenn sich für ein Ereignis eine Übereinstimmung mit einer Regel ergibt. Mit EventBridge können Sie automatisch: + Eine AWS Lambda Funktion aufrufen + Ein Ereignis an Amazon Kinesis Data Streams weiterleiten + Aktivieren Sie eine AWS Step Functions Zustandsmaschine + Ein Amazon SNS SNS-Thema oder eine Amazon SQS SQS-Warteschlange benachrichtigen Wenn Sie beispielsweise EventBridge mit EMR Serverless arbeiten, können Sie eine AWS Lambda Funktion aktivieren, wenn ein ETL-Job erfolgreich ist, oder ein Amazon SNS SNS-Thema benachrichtigen, wenn ein ETL-Job fehlschlägt. EMR Serverless sendet vier Arten von Ereignissen aus: + Ereignisse zur Änderung des Anwendungsstatus — Ereignisse, die jede Statusänderung einer Anwendung auslösen. Weitere Informationen zu Anwendungsstatus finden Sie unter[Status der Anwendung](applications.md#application-states). + Ereignisse zur Statusänderung bei Auftragsausführung — Ereignisse, die jede Statusänderung eines Joblaufs auslösen. Weitere Informationen zu finden Sie unter[Status von Aufgabenausführungen](job-states.md). + Ereignisse zur Wiederholung von Auftragsausführungen — Ereignisse, die bei jedem erneuten Versuch einer Auftragsausführung von Amazon EMR Serverless 7.1.0 und höher ausgelöst werden. + Aktualisierungsereignisse für die Job-Ressourcenauslastung — Ereignisse, die in Intervallen von fast 30 Minuten Updates zur Ressourcennutzung für einen Job ausgeben. ## Beispiel für serverlose EMR-Ereignisse EventBridge Von EMR Serverless gemeldete Ereignisse haben den Wert `aws.emr-serverless` zugewiesen`source`, wie in den folgenden Beispielen. **Ereignis zur Änderung des Anwendungsstatus** Das folgende Beispielereignis zeigt eine Anwendung im `CREATING` Status. ``` { "version": "0", "id": "9fd3cf79-1ff1-b633-4dd9-34508dc1e660", "detail-type": "EMR Serverless Application State Change", "source": "aws.emr-serverless", "account": "123456789012", "time": "2022-05-31T21:16:31Z", "region": "us-east-1", "resources": [], "detail": { "applicationId": "00f1cbsc6anuij25", "applicationName": "3965ad00-8fba-4932-a6c8-ded32786fd42", "arn": "arn:aws:emr-serverless:us-east-1:111122223333:/applications/00f1cbsc6anuij25", "releaseLabel": "emr-6.6.0", "state": "CREATING", "type": "HIVE", "createdAt": "2022-05-31T21:16:31.547953Z", "updatedAt": "2022-05-31T21:16:31.547970Z", "autoStopConfig": { "enabled": true, "idleTimeout": 15 }, "autoStartConfig": { "enabled": true } } } ``` **Ereignis zur Änderung des Status des ausgeführten Job** Das folgende Beispielereignis zeigt eine Auftragsausführung, bei der vom `SCHEDULED` Status in den `RUNNING` Status gewechselt wird. ``` { "version": "0", "id": "00df3ec6-5da1-36e6-ab71-20f0de68f8a0", "detail-type": "EMR Serverless Job Run State Change", "source": "aws.emr-serverless", "account": "123456789012", "time": "2022-05-31T21:07:42Z", "region": "us-east-1", "resources": [], "detail": { "jobRunId": "00f1cbn5g4bb0c01", "applicationId": "00f1982r1uukb925", "arn": "arn:aws:emr-serverless:us-east-1:123456789012:/applications/00f1982r1uukb925/jobruns/00f1cbn5g4bb0c01", "releaseLabel": "emr-6.6.0", "state": "RUNNING", "previousState": "SCHEDULED", "createdBy": "arn:aws:sts::123456789012:assumed-role/TestRole-402dcef3ad14993c15d28263f64381e4cda34775/6622b6233b6d42f59c25dd2637346242", "updatedAt": "2022-05-31T21:07:42.299487Z", "createdAt": "2022-05-31T21:07:25.325900Z" } } ``` **Ereignis zur Wiederholung eines Auftrags** Im Folgenden finden Sie ein Beispiel für ein Ereignis zur Wiederholung eines Auftrags. ``` { "version": "0", "id": "00df3ec6-5da1-36e6-ab71-20f0de68f8a0", "detail-type": "EMR Serverless Job Run Retry", "source": "aws.emr-serverless", "account": "123456789012", "time": "2022-05-31T21:07:42Z", "region": "us-east-1", "resources": [], "detail": { "jobRunId": "00f1cbn5g4bb0c01", "applicationId": "00f1982r1uukb925", "arn": "arn:aws:emr-serverless:us-east-1:123456789012:/applications/00f1982r1uukb925/jobruns/00f1cbn5g4bb0c01", "releaseLabel": "emr-6.6.0", "createdBy": "arn:aws:sts::123456789012:assumed-role/TestRole-402dcef3ad14993c15d28263f64381e4cda34775/6622b6233b6d42f59c25dd2637346242", "updatedAt": "2022-05-31T21:07:42.299487Z", "createdAt": "2022-05-31T21:07:25.325900Z", //Attempt Details "previousAttempt": 1, "previousAttemptState": "FAILED", "previousAttemptCreatedAt": "2022-05-31T21:07:25.325900Z", "previousAttemptEndedAt": "2022-05-31T21:07:30.325900Z", "newAttempt": 2, "newAttemptCreatedAt": "2022-05-31T21:07:30.325900Z" } } ``` **Aktualisierung der Auslastung der Arbeitsressourcen** Das folgende Beispielereignis zeigt das letzte Update zur Ressourcennutzung für einen Job, der nach der Ausführung in einen Terminalstatus übergegangen ist. ``` { "version": "0", "id": "00df3ec6-5da1-36e6-ab71-20f0de68f8a0", "detail-type": "EMR Serverless Job Resource Utilization Update", "source": "aws.emr-serverless", "account": "123456789012", "time": "2022-05-31T21:07:42Z", "region": "us-east-1", "resources": [ "arn:aws:emr-serverless:us-east-1:123456789012:/applications/00f1982r1uukb925/jobruns/00f1cbn5g4bb0c01" ], "detail": { "applicationId": "00f1982r1uukb925", "jobRunId": "00f1cbn5g4bb0c01", "attempt": 1, "mode": "BATCH", "createdAt": "2022-05-31T21:07:25.325900Z", "startedAt": "2022-05-31T21:07:26.123Z", "calculatedFrom": "2022-05-31T21:07:42.299487Z", "calculatedTo": "2022-05-31T21:07:30.325900Z", "resourceUtilizationFinal": true, "resourceUtilizationForInterval": { "vCPUHour": 0.023, "memoryGBHour": 0.114, "storageGBHour": 0.228 }, "billedResourceUtilizationForInterval": { "vCPUHour": 0.067, "memoryGBHour": 0.333, "storageGBHour": 0 }, "totalResourceUtilization": { "vCPUHour": 0.023, "memoryGBHour": 0.114, "storageGBHour": 0.228 }, "totalBilledResourceUtilization": { "vCPUHour": 0.067, "memoryGBHour": 0.333, "storageGBHour": 0 } } } ``` Das Feld **StartedAt** ist nur dann vorhanden, wenn der Job in den Status Running übergegangen ist.