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.
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.
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 Verkehr bedeutet nicht, dass ein Problem vorliegt. 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).
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.
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.
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.
Abgeleitete Metriken
Um tiefere Einblicke zu erhalten, können Sie abgeleitete Metriken erstellen, um mehr über Ihre Streaming-Jobs bei Amazon zu erfahren CloudWatch.
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.
InputRecordsPerSecondgibt die Geschwindigkeit an, mit der Sie Eingabedatensätze erhalten. Sie wird wie folgt abgeleitet: Anzahl der Eingabedatensätze (glue.driver.streaming.NumRecords)/. WindowSize
ProcessingRecordsPerSecondgibt 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.
numberAllExecutorsist 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.
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
batchProcessingTimeInMsskaliert 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.
