Verwenden von CloudWatch Alarmen mit Amazon Managed Service für Apache Flink - Managed Service für Apache Flink
Empfohlene -Alarme

Amazon Managed Service für Apache Flink war zuvor als Amazon Kinesis Data Analytics für Apache Flink bekannt.

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.

Verwenden von CloudWatch Alarmen mit Amazon Managed Service für Apache Flink

Mithilfe von Amazon CloudWatch Metric Alarms beobachten Sie eine CloudWatch Metrik über einen von Ihnen angegebenen Zeitraum. Der Alarm führt eine oder mehrere Aktionen durch, die vom Wert der Metrik oder des Ausdrucks im Vergleich zu einem Schwellenwert in einer Reihe von Zeiträumen abhängt. Eine Aktion könnte beispielsweise der Versand einer Benachrichtigung an ein Amazon Simple Notification Service (Amazon SNS)-Thema sein.

Weitere Informationen zu CloudWatch Alarmen finden Sie unter Amazon CloudWatch Alarms verwenden.

Dieser Abschnitt enthält die empfohlenen Alarme für die Überwachung von Managed Service für Apache Flink-Anwendungen.

Die Tabelle beschreibt die empfohlenen Alarme und enthält die folgenden Spalten:

  • Metrikausdruck: Die Metrik oder der Metrikausdruck, der anhand des Schwellenwerts getestet werden soll.

  • Statistik: Die Statistik, die zur Überprüfung der Metrik verwendet wird, z. B. Durchschnitt.

  • Schwellenwert: Für die Verwendung dieses Alarms müssen Sie einen Schwellenwert festlegen, der die Grenze der erwarteten Anwendungsleistung definiert. Sie müssen diesen Schwellenwert ermitteln, indem Sie Ihre Anwendung unter normalen Bedingungen überwachen.

  • Beschreibung: Ursachen, die diesen Alarm auslösen könnten, und mögliche Lösungen für diesen Zustand.

Metrikausdruck Statistik Threshold Beschreibung
downtime> 0 Durchschnitt 0 Eine Ausfallzeit von mehr als Null bedeutet, dass die Anwendung ausgefallen ist. Wenn der Wert größer als 0 ist, verarbeitet die Anwendung keine Daten. Für alle Anwendungen empfohlen. Die Downtime Metrik misst die Dauer eines Ausfalls. Eine Ausfallzeit von mehr als Null bedeutet, dass die Anwendung ausgefallen ist. Informationen zur Problembehandlung finden Sie unterDie Anwendung wird neu gestartet.
RATE (numberOfFailedCheckpoints)> 0 Durchschnitt 0 Diese Metrik zählt die Anzahl der fehlgeschlagenen Checkpoints seit dem Start der Anwendung. Je nach Anwendung kann es toleriert werden, dass Prüfpunkte gelegentlich fehlschlagen. Wenn Prüfpunkte jedoch regelmäßig ausfallen, ist die Anwendung wahrscheinlich fehlerhaft und benötigt weitere Aufmerksamkeit. Wir empfehlen, RATE (numberOfFailedCheckpoints) so zu überwachen, dass der Alarm auf dem Gradienten und nicht auf absoluten Werten basiert. Für alle Anwendungen empfohlen. Verwenden Sie diese Metrik, um den Zustand der Anwendung und den Fortschritt der Checkpoints zu überwachen. Die Anwendung speichert Statusdaten an Checkpoints, wenn sie fehlerfrei ist. Checkpointing kann aufgrund von Timeouts fehlschlagen, wenn die Anwendung bei der Verarbeitung der Eingabedaten keine Fortschritte macht. Informationen zur Problembehandlung finden Sie unter. Beim Checkpointing kommt es zu einer Zeitüberschreitung
Operator.numRecordsOutPerSecond< Schwellenwert Durchschnitt Die Mindestanzahl von Datensätzen, die unter normalen Bedingungen von der Anwendung gesendet werden. Für alle Anwendungen empfohlen. Ein Unterschreiten dieses Schwellenwerts kann darauf hindeuten, dass die Anwendung bei den Eingabedaten nicht die erwarteten Fortschritte erzielt. Informationen zur Problembehandlung finden Sie unterDurchsatz ist zu langsam.
records_lag_max|millisbehindLatest> Schwellenwert Maximum Die maximal zu erwartende Latenz unter normalen Bedingungen. Wenn die Anwendung viel Kinesis oder Kafka verbraucht, geben diese Metriken an, ob die Anwendung hinterherhinkt und skaliert werden muss, um mit der aktuellen Auslastung Schritt zu halten. Dies ist eine gute generische Metrik, die für alle Arten von Anwendungen leicht nachzuverfolgen ist. Sie kann jedoch nur für reaktive Skalierung verwendet werden, d. h. wenn die Anwendung bereits ins Hintertreffen geraten ist. Für alle Anwendungen empfohlen. Verwenden Sie die records_lag_max Metrik für eine Kafka-Quelle oder die millisbehindLatest für eine Kinesis-Stream-Quelle. Eine Überschreitung dieses Schwellenwerts kann darauf hindeuten, dass die Anwendung bei den Eingabedaten nicht die erwarteten Fortschritte erzielt. Informationen zur Problembehandlung finden Sie unterDurchsatz ist zu langsam.
lastCheckpointDuration> Schwellenwert Maximum Die maximal zu erwartende Checkpoint-Dauer unter normalen Bedingungen. Überwacht, wie viele Daten im Status gespeichert sind und wie lange es dauert, bis ein Checkpoint abgeschlossen ist. Wenn die Anzahl der Prüfpunkte zunimmt oder lange dauert, verbringt die Anwendung kontinuierlich Zeit mit Prüfpunkten und hat weniger Zyklen für die eigentliche Verarbeitung. An manchen Stellen können Prüfpunkte zu groß werden oder so lange dauern, dass sie ausfallen. Neben der Überwachung absoluter Werte sollten Kunden auch erwägen, die Änderungsrate mit RATE(lastCheckpointSize) und RATE(lastCheckpointDuration) zu überwachen. Wenn der Wert lastCheckpointDuration kontinuierlich ansteigt, kann ein Überschreiten dieses Schwellenwerts darauf hinweisen, dass die Anwendung bei den Eingabedaten nicht die erwarteten Fortschritte erzielt oder dass Probleme mit dem Zustand der Anwendung vorliegen, wie z. B. Gegendruck. Informationen zur Problembehandlung finden Sie unterUnbegrenztes Staatswachstum.
lastCheckpointSize> Schwellenwert Maximum Die maximal zu erwartende Checkpoint-Größe unter normalen Bedingungen. Überwacht, wie viele Daten im Status gespeichert sind und wie lange es dauert, bis ein Checkpoint abgeschlossen ist. Wenn die Anzahl der Prüfpunkte zunimmt oder lange dauert, verbringt die Anwendung kontinuierlich Zeit mit Prüfpunkten und hat weniger Zyklen für die eigentliche Verarbeitung. An manchen Stellen können Prüfpunkte zu groß werden oder so lange dauern, dass sie ausfallen. Neben der Überwachung absoluter Werte sollten Kunden auch erwägen, die Änderungsrate mit RATE(lastCheckpointSize) und RATE(lastCheckpointDuration) zu überwachen. Wenn der Wert lastCheckpointSize kontinuierlich ansteigt, kann ein Überschreiten dieses Schwellenwerts darauf hinweisen, dass die Anwendung Zustandsdaten sammelt. Wenn die Zustandsdaten zu groß werden, kann der Anwendung bei der Wiederherstellung von einem Checkpoint der Speicherplatz ausgehen, oder die Wiederherstellung von einem Checkpoint kann zu lange dauern. Informationen zur Problembehandlung finden Sie unter. Unbegrenztes Staatswachstum
heapMemoryUtilization> Schwellenwert Maximum Dies gibt einen guten Hinweis auf die gesamte Ressourcenauslastung der Anwendung und kann für eine proaktive Skalierung verwendet werden, sofern die Anwendung nicht I/O-gebunden ist. Die maximale heapMemoryUtilization Größe, die unter normalen Bedingungen erwartet wird, mit einem empfohlenen Wert von 90 Prozent. Sie können diese Metrik verwenden, um die maximale Speicherauslastung von Task-Managern in der gesamten Anwendung zu überwachen. Wenn die Anwendung diesen Schwellenwert erreicht, müssen Sie mehr Ressourcen bereitstellen. Sie tun dies, indem Sie die automatische Skalierung aktivieren oder die Anwendungsparallelität erhöhen. Weitere Informationen zur Erhöhung der Ressourcen finden Sie unter. Skalierung
cpuUtilization> Schwellenwert Maximum Dies gibt einen guten Hinweis auf die gesamte Ressourcenauslastung der Anwendung und kann für eine proaktive Skalierung verwendet werden, sofern die Anwendung nicht I/O-gebunden ist. Die maximale cpuUtilization Größe, die unter normalen Bedingungen erwartet wird, mit einem empfohlenen Wert von 80 Prozent. Sie können diese Metrik verwenden, um die maximale CPU-Auslastung von Task-Managern in der gesamten Anwendung zu überwachen. Wenn die Anwendung diesen Schwellenwert erreicht, müssen Sie mehr Ressourcen bereitstellen. Dazu aktivieren Sie die automatische Skalierung oder erhöhen die Anwendungsparallelität. Weitere Informationen zur Erhöhung der Ressourcen finden Sie unter. Skalierung
threadsCount> Schwellenwert Maximum Die maximal zu erwartende threadsCount Größe unter normalen Bedingungen. Sie können diese Metrik verwenden, um in Task-Managern in der gesamten Anwendung nach Thread-Leaks Ausschau zu halten. Wenn diese Metrik diesen Schwellenwert erreicht, überprüfen Sie Ihren Anwendungscode auf Threads, die erstellt wurden, ohne geschlossen zu werden.
(oldGarbageCollectionTime * 100)/60_000 over 1 min period')> Schwellenwert Maximum Die maximale erwartete oldGarbageCollectionTime Dauer. Wir empfehlen, einen Schwellenwert so festzulegen, dass die typische Garbage-Collection-Zeit 60 Prozent des angegebenen Schwellenwerts beträgt. Der richtige Schwellenwert für Ihre Anwendung kann jedoch variieren. Wenn diese Kennzahl kontinuierlich steigt, kann dies darauf hindeuten, dass in den Task-Managern der gesamten Anwendung ein Speicherverlust vorliegt.
RATE(oldGarbageCollectionCount) > Schwellenwert Maximum Das oldGarbageCollectionCount unter normalen Bedingungen erwartete Maximum. Der richtige Schwellenwert für Ihre Anwendung wird variieren. Wenn diese Kennzahl kontinuierlich steigt, kann dies darauf hindeuten, dass in den Task-Managern der gesamten Anwendung ein Speicherverlust vorliegt.
Operator.currentOutputWatermark - Operator.currentInputWatermark > Schwellenwert Minimum Der minimale zu erwartende Anstieg des Wasserzeichens unter normalen Bedingungen. Der richtige Schwellenwert für Ihre Anwendung wird variieren. Wenn diese Kennzahl kontinuierlich steigt, kann dies darauf hindeuten, dass entweder die Anwendung immer ältere Ereignisse verarbeitet oder dass eine vorgelagerte Unteraufgabe seit immer längerer Zeit kein Wasserzeichen mehr gesendet hat.