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.
Wenn Sie Streaming-Anwendungen in der Produktion ausführen, möchten Sie die Anwendung kontinuierlich und unbegrenzt ausführen. Es ist wichtig, die Überwachung und korrekte Alarmierung aller Komponenten zu implementieren, nicht nur der Flink-Anwendung. Andernfalls riskieren Sie, aufkommende Probleme frühzeitig zu übersehen und ein operatives Ereignis erst dann zu erkennen, wenn es vollständig aufgelöst und viel schwieriger zu beheben ist. Zu den allgemeinen Dingen, die es zu überwachen gilt, gehören:
Nimmt die Quelle Daten auf?
Werden Daten aus der Quelle gelesen (aus der Perspektive der Quelle)?
Empfängt die Flink-Anwendung Daten?
Kann die Flink-Anwendung Schritt halten oder gerät sie ins Hintertreffen?
Speichert die Flink-Anwendung Daten dauerhaft in der Senke (aus Sicht der Anwendung)?
Empfängt die Senke Daten?
Spezifischere Metriken sollten dann für die Flink-Anwendung in Betracht gezogen werden. Dieses CloudWatch Dashboard
records_lag_max und millisbehindLatest – Wenn die Anwendung von Kinesis oder Kafka konsumiert, geben diese Metriken an, ob die Anwendung hinterherhinkt und abskaliert 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.
cpuUtilization und heapMemoryUtilization— Diese Metriken geben einen guten Hinweis auf die Gesamtressourcenauslastung der Anwendung und können für eine proaktive Skalierung verwendet werden, sofern die Anwendung nicht I/O-gebunden ist.
downtime – 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.
lastCheckpointSizeund lastCheckpointDuration— Diese Metriken überwachen, wie viele Daten im Status gespeichert sind und wie lange es dauert, bis ein Checkpoint erreicht wird. 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)undRATE(lastCheckpointDuration)zu überwachen.numberOfFailedCheckpoints — 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 die Überwachung von
RATE(numberOfFailedCheckpoints), dass der Alarm anhand des Gefälles und nicht anhand absoluter Werte ausgelöst wird.
