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.
# Über die Überwachung von AWS Glue Streaming-Jobs
Die Überwachung Ihres Streaming-Auftrags ist ein entscheidender Teil des Aufbaus Ihrer ETL-Pipeline. Neben der Spark-Benutzeroberfläche können Sie auch Amazon verwenden, CloudWatch um die Metriken zu überwachen. Im Folgenden finden Sie eine Liste der vom AWS Glue Framework ausgegebenen Streaming-Metriken. Eine vollständige Liste aller AWS Glue Metriken finden Sie unter [Überwachung AWS Glue mithilfe von CloudWatch Amazon-Metriken](https://docs.aws.amazon.com/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html).
AWS Glue verwendet ein strukturiertes Streaming-Framework, um die Eingabeereignisse zu verarbeiten. Sie können entweder die Spark-API direkt in Ihrem Code verwenden oder den von `GlueContext` bereitgestellten `ForEachBatch` nutzen, der diese Metriken veröffentlicht. Um diese Metriken zu verstehen, müssen wir zuerst `windowSize` verstehen.
**windowSize**: `windowSize` ist das Micro-Batch-Intervall, das Sie angeben. Wenn Sie eine Fenstergröße von 60 Sekunden angeben, wartet der AWS Glue Streaming-Job 60 Sekunden (oder länger, wenn der vorherige Batch bis dahin noch nicht abgeschlossen ist), bevor er Daten in einem Batch aus der Streaming-Quelle liest und die unter angegebenen Transformationen anwendet. `ForEachBatch` Dies wird auch als Auslöser-Intervall bezeichnet.
Schauen wir uns die Metriken genauer an, um die Zustands- und Leistungsmerkmale zu verstehen.
**Anmerkung**
Die Metriken werden alle 30 Sekunden ausgegeben. Wenn Ihre `windowSize` weniger als 30 Sekunden beträgt, handelt es sich bei den gemeldeten Metriken um eine Aggregation. Nehmen wir an, Ihre `windowSize` beträgt 10 Sekunden und Sie verarbeiten kontinuierlich 20 Datensätze pro Micro-Batch. In diesem Szenario wäre der ausgegebene Metrikwert für numRecords 60.
Eine Metrik wird nicht ausgegeben, wenn dafür keine Daten verfügbar sind. Außerdem müssen Sie im Falle der Metrik für die Verzögerung von Verbrauchern das Feature aktivieren, um Metriken für sie zu erhalten.
# AWS Glue Streaming-Metriken visualisieren
So zeichnen Sie visuelle Metriken auf:
1. Gehen Sie in der CloudWatch Amazon-Konsole zu **Metrics** und wählen Sie dann den Tab **Durchsuchen**. Wählen Sie dann unter „Benutzerdefinierte Namespaces“ die Option **Glue**.
![\[Der Screenshot zeigt den Zugriff auf Metriken in der CloudWatch Amazon-Konsole bei der Überwachung von AWS Glue Streaming-Jobs.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/streaming-monitoring-1.png)
1. Wählen Sie **Auftrag-Metriken**, um Ihnen die Metriken für all Ihre Aufträge anzuzeigen.
1. Filtern Sie die Metriken nach Ihrem JobName = glue-feb-monitoring und dann nach JobRunId =ALL. Sie können auf das „\$1“-Zeichen klicken, wie in der Abbildung unten gezeigt, um es dem Suchfilter hinzuzufügen.
1. Wählen Sie das Kontrollkästchen für die Metriken aus, an denen Sie interessiert sind. In der folgenden Abbildung haben wir `numberAllExecutors` und `numberMaxNeededExecutors` ausgewählt.
![\[Der Screenshot zeigt die Anwendung eines Durchschnitts auf Metriken bei der Überwachung von Streaming-Aufträgen.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/streaming-monitoring-2.png)
1. Sobald Sie diese Metriken ausgewählt haben, können Sie zur Registerkarte **Grafisch dargestellte Metriken** wechseln und Ihre Statistiken anwenden.
1. Da die Metriken jede Minute ausgegeben werden, können Sie den „Durchschnitt“ über eine Minute für `batchProcessingTimeInMs` und `maxConsumerLagInMs` anwenden. Für `numRecords` kann die „Summe“ für jede Minute angewendet werden.
1. Sie können Ihrem Diagramm mithilfe der Registerkarte **Optionen** eine horizontale `windowSize`-Anmerkung hinzufügen.
![\[Der Screenshot zeigt das Hinzufügen einer windowSize-Anmerkung zu Ihrem Diagramm bei der Überwachung von Streaming-Aufträgen.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/streaming-monitoring-3.png)
1. Sobald Sie Ihre Metriken ausgewählt haben, erstellen Sie ein Dashboard und fügen Sie es hinzu. Hier ist ein Beispiel-Dashboard.
![\[Der Screenshot zeigt ein Beispiel-Dashboard zur Überwachung von Streaming-Aufträgen.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/streaming-monitoring-4.png)
# AWS Glue Streaming-Metriken verwenden
In diesem Abschnitt werden die einzelnen Metriken und ihre Beziehung zueinander beschrieben.
## Anzahl der Datensätze (Metrik: streaming.numRecords)
Diese Metrik gibt an, wie viele Datensätze verarbeitet werden.
![\[Der Screenshot zeigt die Überwachung der Anzahl von Datensätzen in Streaming-Aufträgen.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/streaming-monitoring-5numrecords.png)
Diese Streaming-Metrik bietet gibt Aufschluss über die Anzahl der Datensätze, die Sie in einem Fenster verarbeiten. Zusammen mit der Anzahl der verarbeiteten Datensätze hilft es Ihnen auch, das Verhalten des Eingabe-Datenverkehrs zu verstehen.
+ Indikator 1 zeigt ein Beispiel für stabilen Datenverkehr ohne Spitzenbelastungen. In der Regel handelt es sich dabei um Anwendungen wie IoT-Sensoren, die in regelmäßigen Abständen Daten sammeln und diese an die Streaming-Quelle senden.
+ Indikator 2 zeigt ein Beispiel für einen plötzlichen Anstieg des Datenverkehrs bei ansonsten stabiler Last. Dies kann in einer Clickstream-Anwendung passieren, wenn es ein Marketing-Ereignis wie den Black Friday gibt und die Anzahl der Klicks sprunghaft ansteigt.
+ Indikator 3 zeigt ein Beispiel für unvorhersehbaren Datenverkehr. Unvorhersehbarer Datenverkehr bedeutet nicht, dass es ein Problem gibt. Das liegt in der Natur der Eingabedaten. Um auf das Beispiel mit den IoT-Sensoren zurückzukommen: Sie können sich Hunderte von Sensoren vorstellen, die Ereignisse im Zusammenhang mit Wetteränderungen an die Streaming-Quelle senden. Da der Wetterwechsel nicht vorhersehbar ist, sind es auch die Daten nicht. Das Verständnis des Verkehrsaufkommens ist der Schlüssel zur Dimensionierung Ihrer Executors. Wenn die Eingangsdaten sehr sprunghaft sind, können Sie Auto Scaling in Betracht ziehen (mehr dazu später).
![\[Der Screenshot zeigt die Überwachung anhand der Anzahl der Datensätze und PutRecords Kinesis-Metriken in Streaming-Jobs.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/streaming-monitoring-6putrecords.png)
Sie können diese Metrik mit der PutRecords Kinesis-Metrik kombinieren, um sicherzustellen, dass die Anzahl der aufgenommenen Ereignisse und die Anzahl der gelesenen Datensätze nahezu identisch sind. Das ist vor allem dann nützlich, wenn Sie versuchen, Verzögerungen zu verstehen. Mit steigender Aufnahmerate steigt auch der Lesevorgang. `numRecords` AWS Glue
## Batch-Verarbeitungszeit (Metrik: Streaming). batchProcessingTimeInMs)
Anhand der Metrik für die Batch-Verarbeitungszeit können Sie feststellen, ob der Cluster nicht ausreichend oder übermäßig ausgelastet ist.
![\[Der Screenshot zeigt die Überwachung der Batch-Verarbeitungszeit bei Streaming-Aufträgen.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/streaming-monitoring-7batchprocess.png)
Diese Metrik gibt die Anzahl der Millisekunden an, die für die Verarbeitung eines jeden Micro-Batches von Datensätzen benötigt wurden. Das Hauptziel ist es, diese Zeit zu überwachen, um sicherzustellen, dass sie kürzer als das Intervall `windowSize` ist. Es ist in Ordnung, wenn die `batchProcessingTimeInMs` vorübergehend zu hoch ausfällt, solange sie sich im folgenden Fensterintervall wieder einpendelt. Indikator 1 zeigt eine mehr oder weniger stabile Zeit für die Bearbeitung des Auftrags an. Wenn jedoch die Anzahl der Eingabedatensätze zunimmt, steigt auch die Zeit, die für die Verarbeitung des Auftrags benötigt wird, wie Indikator 2 zeigt. Wenn die `numRecords` nicht ansteigt, aber die Verarbeitungszeit ansteigt, müssen Sie die Auftragsverarbeitung der Executors genauer unter die Lupe nehmen. Es empfiehlt sich, einen Schwellenwert und einen Alarm einzustellen, um sicherzustellen, dass die `batchProcessingTimeInMs` nicht länger als 10 Minuten über 120 % bleibt. Weitere Informationen zum Einstellen von Alarmen finden Sie unter [ CloudWatch Amazon-Alarme verwenden](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html).
## Verzögerung bei Verbrauchern (Metrik: Streaming). maxConsumerLagInMs)
Die Metrik für den Verbraucherverzögerungen hilft Ihnen zu verstehen, ob es eine Verzögerung bei der Verarbeitung von Ereignissen gibt. Wenn die Verzögerung zu groß ist, könnten Sie das Verarbeitungs-SLA, von dem Ihr Unternehmen abhängt, verpassen – auch wenn Sie eine korrekte windowSize haben. Sie müssen diese Metriken explizit über die `emitConsumerLagMetrics`-Verbindungsoption aktivieren. Weitere Informationen finden Sie unter [KinesisStreamingSourceOptions](https://docs.aws.amazon.com/glue/latest/webapi/API_KinesisStreamingSourceOptions.html).
![\[Der Screenshot zeigt die Verzögerung bei der Überwachung von Streaming-Aufträgen.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/streaming-monitoring-8lag.png)
## Abgeleitete Metriken
Um tiefere Einblicke zu erhalten, können Sie abgeleitete Metriken erstellen, um mehr über Ihre Streaming-Jobs bei Amazon zu erfahren CloudWatch.
![\[Der Screenshot zeigt die Überwachung abgeleiteter Metriken in Streaming-Aufträgen.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/streaming-monitoring-9derived.png)
Sie können ein Diagramm mit abgeleiteten Metriken erstellen, um zu entscheiden, ob Sie mehr verwenden müssen DPUs. Auto Scaling hilft Ihnen dabei, dies automatisch zu tun, aber Sie können abgeleitete Metriken verwenden, um festzustellen, ob Auto Scaling effektiv funktioniert.
+ **InputRecordsPerSecond**gibt die Geschwindigkeit an, mit der Sie Eingabedatensätze erhalten. Sie wird wie folgt abgeleitet: Anzahl der Eingabedatensätze (Glue.Driver.Streaming.NumRecords)/. WindowSize
+ **ProcessingRecordsPerSecond**gibt die Geschwindigkeit an, mit der Ihre Datensätze verarbeitet werden. Sie wird wie folgt abgeleitet: Anzahl der Eingabedatensätze (glue.driver.streaming.NumRecords)/. batchProcessingTime InMs
Wenn die Eingaberate höher ist als die Verarbeitungsrate, müssen Sie möglicherweise mehr Kapazität zur Verarbeitung Ihres Auftrags hinzufügen oder die Parallelität erhöhen.
## Auto-Scaling-Metriken
Wenn der Eingabe-Datenverkehr sprunghaft ansteigt, sollten Sie Auto Scaling aktivieren und die maximale Anzahl der Worker festlegen. Damit erhalten Sie zwei zusätzliche Metriken, `numberAllExecutors` und `numberMaxNeededExecutors`.
+ **numberAllExecutors**ist die Anzahl der aktiv laufenden Job-Executoren
+ **numberMaxNeededExecutors** ist die maximale Anzahl von (aktiv ausgeführten und ausstehenden) Job-Executoren, die benötigt werden, um die aktuelle Last zu bewältigen.
Diese beiden Metriken helfen Ihnen zu verstehen, ob Ihr Auto Scaling ordnungsgemäß funktioniert.
![\[Der Screenshot zeigt die Überwachung von Auto Scaling bei Streaming-Aufträgen.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/streaming-monitoring-10autoscaling.png)
AWS Glue überwacht die `batchProcessingTimeInMs` Metrik über einige Mikrobatches und führt dabei eine von zwei Aktionen aus. Dabei werden die Executors aufskaliert, wenn `batchProcessingTimeInMs` näher an `windowSize` liegt, oder die Executors werden abskaliert, wenn `batchProcessingTimeInMs` vergleichsweise niedriger ist als `windowSize`. Außerdem wird ein Algorithmus zur schrittweisen Skalierung der Executors verwendet.
+ Indikator 1 zeigt Ihnen, wie die aktiven Executors hochskaliert haben, um mit den maximal benötigten Executors mithalten zu können und die Last zu verarbeiten.
+ Indikator 2 zeigt Ihnen, wie die aktiven Executors seit der niedrigen `batchProcessingTimeInMs` skaliert haben.
Sie können diese Metriken verwenden, um die aktuelle Parallelität auf Executor-Ebene zu überwachen und die Anzahl der maximalen Worker in Ihrer Auto-Scaling-Konfiguration entsprechend anzupassen.
## So erzielen Sie die beste Leistung
Spark wird versuchen, eine zu lesende Aufgabe pro Shard im Amazon-Kinesis-Stream zu erstellen. Die Daten in jedem Shard werden zu einer Partition. Anschließend werden diese Aufgaben auf die Executors/Worker verteilt, abhängig von der Anzahl der Kerne auf jedem Worker (die Anzahl der Kerne pro Worker hängt von dem von Ihnen gewählten Worker-Typ ab, `G.025X`, `G.1X`, usw.). Es ist jedoch nicht bestimmbar, wie die Aufgaben verteilt werden. Alle Aufgaben werden parallel auf ihren jeweiligen Kernen ausgeführt. Wenn es mehr Shards als verfügbare Executor-Kerne gibt, werden die Aufgaben in eine Warteschlange gestellt.
Sie können eine Kombination aus den oben genannten Metriken und der Anzahl der Shards verwenden, um Ihre Executors für eine stabile Last mit etwas Spielraum für Spitzenlasten bereitzustellen. Es empfiehlt sich, einige Iterationen Ihres Auftrags durchzuführen, um die ungefähre Anzahl der Worker zu ermitteln. Für einen unstable/spiky Workload können Sie dasselbe tun, indem Sie Autoscaling und Max Workers einrichten.
Stellen Sie die `windowSize` gemäß den SLA-Anforderungen Ihres Unternehmens ein. Wenn Ihr Unternehmen beispielsweise verlangt, dass die verarbeiteten Daten nicht älter als 120 Sekunden sein dürfen, dann setzen Sie Ihre `windowSize` auf mindestens 60 Sekunden, so dass die durchschnittliche Verzögerung beim Verbraucher weniger als 120 Sekunden beträgt (siehe Abschnitt über die Verzögerung beim Verbraucher oben). Von dort aus können Sie je nach Anzahl `numRecords` und Anzahl der Shards die Kapazität so einplanen, DPUs dass Sie in den `windowSize` meisten Fällen weniger als 70% Ihrer Kapazität haben. `batchProcessingTimeInMs`
**Anmerkung**
Hot Shards können zu Datenverzerrungen führen, was bedeutet, dass einige viel größer shards/partitions sind als die anderen. Dies kann dazu führen, dass einige Aufgaben, die parallel ausgeführt werden, mehr Zeit benötigen und Nachzügleraufgaben verursachen. Dies hat zur Folge, dass der nächste Batch erst dann beginnen kann, wenn alle Aufgaben des vorherigen Batches abgeschlossen sind, was sich auf die `batchProcessingTimeInMillis` und die maximale Verzögerung auswirkt.