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.
# Fehlerbehebung während der Laufzeit
Dieser Abschnitt enthält Informationen zum Diagnostizieren und Beheben von Laufzeitproblemen mit Ihrer Anwendung, die Managed Service für Apache Flink nutzt.
**Topics**
+ [Tools zur Fehlerbehebung](#troubleshooting-tools)
+ [Probleme mit der Anwendung](troubleshooting-symptoms.md)
+ [Die Anwendung wird neu gestartet](troubleshooting-rt-restarts.md)
+ [Der Durchsatz ist zu langsam](troubleshooting-rt-throughput.md)
+ [Unbegrenztes Staatswachstum](troubleshooting-rt-stateleaks.md)
+ [E/A-gebundene Operatoren](troubleshooting-io-bound-operators.md)
+ [Upstream- oder Quelldrosselung aus einem Kinesis-Datenstrom](troubleshooting-source-throttling.md)
+ [Checkpoints](troubleshooting-checkpoints.md)
+ [Beim Checkpointing kommt es zu einer Zeitüberschreitung](troubleshooting-chk-timeout.md)
+ [Checkpoint-Fehler für Apache-Beam-Anwendung](troubleshooting-chk-failure-beam.md)
+ [Gegendruck](troubleshooting-backpressure.md)
+ [Verzerrte Datenverteilung](troubleshooting-data-skew.md)
+ [Zustandsverzerrung](troubleshooting-state-skew.md)
+ [Integrieren Sie Ressourcen in verschiedenen Regionen](troubleshooting-resources-in-different-regions.md)
## Tools zur Fehlerbehebung
Das wichtigste Tool zur Erkennung von Anwendungsproblemen sind CloudWatch Alarme. Mithilfe von CloudWatch Alarmen können Sie Schwellenwerte für CloudWatch Messwerte festlegen, die auf Fehler oder Engpässe in Ihrer Anwendung hinweisen. Informationen zu empfohlenen CloudWatch Alarmen finden Sie unter. [Verwenden Sie CloudWatch Alarme mit Amazon Managed Service für Apache Flink](monitoring-metrics-alarms.md)
# Probleme mit der Anwendung
Dieser Abschnitt enthält Lösungen für Fehlerbedingungen, die bei Ihrer Anwendung, die Managed Service für Apache Flink nutzt, auftreten können.
**Topics**
+ [Die Anwendung steckt in einem vorübergehenden Status fest](#troubleshooting-rt-stuck)
+ [Die Erstellung eines Snapshots schlägt feh](#troubleshooting-rt-snapshots)
+ [Auf Ressourcen in einer VPC kann nicht zugegriffen werden](#troubleshooting-rt-vpc)
+ [Beim Schreiben in einen Amazon S3 S3-Bucket gehen Daten verloren](#troubleshooting-rt-s3)
+ [Die Anwendung befindet sich im Status RUNNING, verarbeitet aber keine Daten](#troubleshooting-rt-processing)
+ [Fehler beim Snapshot, beim Anwendungsupdate oder beim Beenden der Anwendung: InvalidApplicationConfigurationException](#troubleshooting-rt-appconfigexception)
+ [java.nio.file. NoSuchFileException:/usr/local/openjdk-8/lib/security/cacerts](#troubleshooting-rt-fnf)
## Die Anwendung steckt in einem vorübergehenden Status fest
Wenn sich Ihre Anwendung in einem vorübergehenden Status (`STARTING`,`UPDATING`, oder`AUTOSCALING`) befindet`STOPPING`, können Sie Ihre Anwendung beenden, indem Sie die [StopApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_StopApplication.html)Aktion mit dem `Force` Parameter auf beenden. `true` Sie können das Beenden einer Anwendung im Status `DELETING` nicht erzwingen. Wenn sich die Anwendung im Status `UPDATING` oder `AUTOSCALING` befindet, können Sie sie alternativ auf die vorherige laufende Version zurücksetzen. Wenn Sie ein Rollback einer Anwendung durchführen, werden Statusdaten aus dem letzten erfolgreichen Snapshot geladen. Wenn die Anwendung keine Snapshots hat, lehnt Managed Service für Apache Flink die Rollback-Anfrage ab. Weitere Informationen zum Zurücksetzen einer Anwendung finden Sie unter [RollbackApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_RollbackApplication.html)Aktion.
**Anmerkung**
Das erzwungene Beenden Ihrer Anwendung kann zu Datenverlust oder -duplizierung führen. Um Datenverlust oder doppelte Verarbeitung von Daten bei Anwendungsneustarts zu verhindern, empfehlen wir Ihnen, regelmäßig Snapshots Ihrer Anwendung zu erstellen.
Ursachen für hängengebliebene Anwendungen sind unter anderem:
+ **Anwendungszustand ist zu groß:** Ein zu großer oder zu persistenter Anwendungszustand kann dazu führen, dass die Anwendung während eines Checkpoint- oder Snapshot-Vorgangs hängen bleibt. Überprüfen Sie die Metriken `lastCheckpointDuration` und `lastCheckpointSize` Ihrer Anwendung auf stetig steigende Werte oder ungewöhnlich hohe Werte.
+ **Anwendungscode ist zu groß:** Stellen Sie sicher, dass die JAR-Datei Ihrer Anwendung kleiner als 512 MB ist. JAR-Dateien, die größer als 512 MB sind, werden nicht unterstützt.
+ **Erstellung eines Anwendungs-Snapshots schlägt fehl:** Managed Service für Apache Flink erstellt während einer [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_UpdateApplication.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_UpdateApplication.html)- oder [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_StopApplication.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_StopApplication.html)-Anfrage einen Snapshot der Anwendung. Der Service verwendet dann diesen Snapshot-Status und stellt die Anwendung mithilfe der aktualisierten Anwendungskonfiguration wieder her, um *exakt einmal* eine Verarbeitungssemantik bereitzustellen. Falls die automatische Snapshot-Erstellung fehlschlägt, finden Sie im Folgenden unter [Die Erstellung eines Snapshots schlägt feh](#troubleshooting-rt-snapshots) weitere Informationen.
+ **Wiederherstellung aus einem Snapshot schlägt fehl:** Wenn Sie einen Operator in einem Anwendungsupdate entfernen oder ändern und versuchen, eine Wiederherstellung aus einem Snapshot durchzuführen, schlägt die Wiederherstellung standardmäßig fehl, wenn der Snapshot Zustandsdaten für den fehlenden Operator enthält. Darüber hinaus bleibt die Anwendung entweder im Status `STOPPED` oder `UPDATING` hängen. Um dieses Verhalten zu ändern und sicherzustellen, dass die Wiederherstellung erfolgreich ist, ändern Sie den *AllowNonRestoredState*Parameter der Anwendung [FlinkRunConfiguration](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_FlinkRunConfiguration.html)auf`true`. Dadurch können beim Wiederaufnahmevorgang Zustandsdaten übersprungen werden, die dem neuen Programm nicht zugeordnet werden können.
+ **Anwendungsinitialisierung dauert länger:** Managed Service für Apache Flink verwendet ein internes Timeout von 5 Minuten (Soft-Einstellung), während auf den Start eines Flink-Auftrags gewartet wird. Wenn Ihr Job innerhalb dieses Timeouts nicht gestartet werden kann, wird ein CloudWatch Protokoll wie folgt angezeigt:
```
Flink job did not start within a total timeout of 5 minutes for application: %s under account: %s
```
Wenn Sie auf den oben genannten Fehler stoßen, bedeutet dies, dass Ihre mit der `main`-Methode des Flink-Auftrags definierten Operationen mehr als 5 Minuten dauern, was zu einem Timeout bei der Erstellung des Flink-Auftrags auf der Seite von Managed Service für Apache Flink führt. Wir empfehlen Ihnen, sowohl die **JobManager**Flink-Logs als auch Ihren Anwendungscode zu überprüfen, um festzustellen, ob mit dieser Verzögerung bei der `main` Methode zu rechnen ist. Wenn nicht, müssen Sie Maßnahmen ergreifen, um das Problem zu beheben, damit sie in weniger als 5 Minuten abgeschlossen wird.
Sie können den Status Ihrer Anwendung mithilfe der [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ListApplications.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ListApplications.html)- oder der [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_DescribeApplication.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_DescribeApplication.html)-Aktion überprüfen.
## Die Erstellung eines Snapshots schlägt feh
Der Service von Managed Service für Apache Flink kann unter den folgenden Umständen keinen Snapshot erstellen:
+ Die Anwendung hat das Snapshot-Limit überschritten. Das Limit für Snapshots ist 1 000. Weitere Informationen finden Sie unter [Anwendungs-Backups mithilfe von Snapshots verwalten](how-snapshots.md).
+ Die Anwendung ist nicht berechtigt, auf ihre Quelle oder Senke zuzugreifen.
+ Der Anwendungscode funktioniert nicht richtig.
+ Bei der Anwendung treten andere Konfigurationsprobleme auf.
Wenn beim Erstellen eines Snapshots während eines Anwendungsupdates oder beim Beenden der Anwendung eine Ausnahme auftritt, setzen Sie die `SnapshotsEnabled`-Eigenschaft der [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ApplicationSnapshotConfiguration.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ApplicationSnapshotConfiguration.html) Ihrer Anwendung auf `false` und wiederholen Sie die Anfrage.
Snapshots können fehlschlagen, wenn die Operatoren Ihrer Anwendung nicht ordnungsgemäß bereitgestellt werden. Informationen zur Optimierung der Operatorleistung finden Sie unter [Operatorenskalierung](performance-improving.md#performance-improving-scaling-op).
Wenn die Anwendung wieder in einen fehlerfreien Zustand zurückkehrt, empfehlen wir, die `SnapshotsEnabled`-Eigenschaft Ihrer Anwendung auf `true` zu setzen.
## Auf Ressourcen in einer VPC kann nicht zugegriffen werden
Wenn Ihre Anwendung eine VPC verwendet, die auf Amazon VPC läuft, gehen Sie wie folgt vor, um zu überprüfen, ob Ihre Anwendung Zugriff auf ihre Ressourcen hat:
+ Überprüfen Sie Ihre CloudWatch Protokolle auf den folgenden Fehler. Dieser Fehler weist darauf hin, dass Ihre Anwendung nicht auf Ressourcen in Ihrer VPC zugreifen kann:
```
org.apache.kafka.common.errors.TimeoutException: Failed to update metadata after 60000 ms.
```
Wenn Sie diesen Fehler sehen, überprüfen Sie, ob Ihre Routing-Tabellen korrekt eingerichtet sind und ob Ihre Konnektoren die richtigen Verbindungseinstellungen haben.
Informationen zum Einrichten und Analysieren von CloudWatch Protokollen finden Sie unter[Protokollierung und Überwachung in Amazon Managed Service für Apache Flink](monitoring-overview.md).
## Beim Schreiben in einen Amazon S3 S3-Bucket gehen Daten verloren
Beim Schreiben von Ausgaben in einen Amazon-S3-Bucket mit Apache Flink Version 1.6.2 kann es zu Datenverlusten kommen. Wir empfehlen, die neueste unterstützte Version von Apache Flink zu verwenden, wenn Sie Amazon S3 direkt für die Ausgabe verwenden. Um mit Apache Flink 1.6.2 in einen Amazon S3 S3-Bucket zu schreiben, empfehlen wir die Verwendung von Firehose. Weitere Informationen zur Verwendung von Firehose mit Managed Service für Apache Flink finden Sie unter. [Firehose-Spüle](earlier.md#get-started-exercise-fh)
## Die Anwendung befindet sich im Status RUNNING, verarbeitet aber keine Daten
Sie können den Status Ihrer Anwendung mithilfe der [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ListApplications.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ListApplications.html)- oder der [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_DescribeApplication.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_DescribeApplication.html)-Aktion überprüfen. Wenn Ihre Anwendung den `RUNNING` Status annimmt, aber keine Daten in Ihre Senke schreibt, können Sie das Problem beheben, indem Sie Ihrer Anwendung einen CloudWatch Amazon-Protokollstream hinzufügen. Weitere Informationen finden Sie unter [Arbeiten Sie mit den Optionen für die CloudWatch Anwendungsprotokollierung](cloudwatch-logs.md#adding_cloudwatch). Der Protokollstream enthält Meldungen, mit denen Sie Anwendungsprobleme beheben können.
## Fehler beim Snapshot, beim Anwendungsupdate oder beim Beenden der Anwendung: InvalidApplicationConfigurationException
Während eines Snapshot-Vorgangs oder während eines Vorgangs, der einen Snapshot erstellt, z. B. beim Aktualisieren oder Beenden einer Anwendung, kann ein Fehler auftreten, der dem folgenden ähnelt:
```
An error occurred (InvalidApplicationConfigurationException) when calling the UpdateApplication operation:
Failed to take snapshot for the application xxxx at this moment. The application is currently experiencing downtime.
Please check the application's CloudWatch metrics or CloudWatch logs for any possible errors and retry the request.
You can also retry the request after disabling the snapshots in the Managed Service for Apache Flink console or by updating
the ApplicationSnapshotConfiguration through the AWS SDK
```
Dieser Fehler tritt auf, wenn die Anwendung keinen Snapshot erstellen kann.
Wenn dieser Fehler während eines Snapshot-Vorgangs oder eines Vorgangs, der einen Snapshot erstellt, auftritt, gehen Sie wie folgt vor:
+ Deaktivieren Sie Snapshots für Ihre Anwendung. Sie können dies entweder in der Managed Service for Apache Flink-Konsole oder mithilfe des `SnapshotsEnabledUpdate` [UpdateApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_UpdateApplication.html)Aktionsparameters tun.
+ Untersuchen Sie, warum keine Snapshots erstellt werden können. Weitere Informationen finden Sie unter [Die Anwendung steckt in einem vorübergehenden Status fest](#troubleshooting-rt-stuck).
+ Aktivieren Sie Snapshots erneut, wenn die Anwendung wieder fehlerfrei ist.
## java.nio.file. NoSuchFileException:/usr/local/openjdk-8/lib/security/cacerts
Der Speicherort des SSL-Truststores wurde in einer früheren Bereitstellung aktualisiert. Verwenden Sie stattdessen den folgenden Wert für den `ssl.truststore.location`-Parameter:
```
/usr/lib/jvm/java-11-amazon-corretto/lib/security/cacerts
```
# Die Anwendung wird neu gestartet
Wenn Ihre Anwendung nicht fehlerfrei ist, schlägt ihr Apache-Flink-Auftrag ständig fehl und wird neu gestartet. In diesem Abschnitt werden Symptome und Schritte zur Behebung dieses Problems beschrieben.
## Symptome
Dieses Problem kann folgende Symptome aufweisen:
+ Die `FullRestarts`-Metrik ist nicht Null. Diese Metrik gibt an, wie oft der Auftrag der Anwendung neu gestartet wurde, seit Sie die Anwendung gestartet haben.
+ Die `Downtime`-Metrik ist nicht Null. Diese Metrik stellt die Anzahl der Millisekunden dar, für die sich die Anwendung im Status `FAILING` oder `RESTARTING` befindet.
+ Das Anwendungsprotokoll enthält Statusänderungen zu `RESTARTING` oder `FAILED`. Mit der folgenden CloudWatch Logs Insights-Abfrage können Sie Ihr Anwendungsprotokoll nach diesen Statusänderungen abfragen:[Fehler analysieren: Fehler im Zusammenhang mit Anwendungsaufgaben](cloudwatch-logs-reading.md#cloudwatch-logs-reading-apps).
## Ursachen und Lösungen
Die folgenden Bedingungen können dazu führen, dass Ihre Anwendung instabil wird und wiederholt neu gestartet wird:
+ **Der Operator löst eine Ausnahme aus:** Wenn eine Ausnahme in einem Operator in Ihrer Anwendung nicht behandelt wird, führt die Anwendung ein Failover durch (indem interpretiert wird, dass der Fehler nicht vom Operator behandelt werden kann). Die Anwendung wird vom letzten Checkpoint aus neu gestartet, um die Semantik der Exakt-einmal-Verarbeitung beizubehalten. Daher ist während dieser Neustartphasen `Downtime` nicht Null. Um dies zu verhindern, empfehlen wir Ihnen, alle wiederholbaren Ausnahmen im Anwendungscode zu behandeln.
Sie können die Ursachen für dieses Problem untersuchen, indem Sie Ihre Anwendungsprotokolle nach Änderungen des Zustands Ihrer Anwendung von `RUNNING` auf `FAILED` abfragen. Weitere Informationen finden Sie unter [Fehler analysieren: Fehler im Zusammenhang mit Anwendungsaufgaben](cloudwatch-logs-reading.md#cloudwatch-logs-reading-apps).
+ **Kinesis-Datenstreams werden nicht ordnungsgemäß bereitgestellt:** Wenn eine Quelle oder Senke für Ihre Anwendung ein Kinesis-Datenstream ist, überprüfen Sie die [Metriken](https://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.html) für den Stream auf Fehler. `ReadProvisionedThroughputExceeded` `WriteProvisionedThroughputExceeded`
Wenn Sie diese Fehler sehen, können Sie den verfügbaren Durchsatz für den Kinesis-Stream erhöhen, indem Sie die Anzahl der Shards des Streams erhöhen. Weitere Informationen finden Sie unter [Wie kann ich die Anzahl der offenen Shards in Kinesis Data Streams ändern?](https://aws.amazon.com/premiumsupport/knowledge-center/kinesis-data-streams-open-shards/)
+ **Andere Quellen oder Senken werden nicht ordnungsgemäß bereitgestellt oder sind nicht verfügbar:** Stellen Sie sicher, dass Ihre Anwendung Quellen und Senken korrekt bereitstellt. Vergewissern Sie sich, dass alle in der Anwendung verwendeten Quellen oder Senken (z. B. andere AWS Dienste oder externe Quellen oder Ziele) ordnungsgemäß bereitgestellt sind, dass keine Lese- oder Schreibdrosselung auftritt oder dass sie regelmäßig nicht verfügbar sind.
Wenn Sie Probleme mit dem Durchsatz Ihrer abhängigen Services haben, erhöhen Sie entweder die für diese Services verfügbaren Ressourcen oder untersuchen Sie die Ursache für Fehler oder Nichtverfügbarkeit.
+ **Operatoren werden nicht ordnungsgemäß bereitgestellt:** Wenn der Workload auf den Threads für einen der Operatoren in Ihrer Anwendung nicht richtig verteilt ist, kann der Operator überlastet werden und die Anwendung kann abstürzen. Informationen zur Optimierung der Operatorparallelität finden Sie unter [Richtiges Verwalten der Operatorenskalierung](performance-improving.md#performance-improving-scaling-op).
+ **Die Anwendung schlägt fehl mit DaemonException:** Dieser Fehler wird in Ihrem Anwendungsprotokoll angezeigt, wenn Sie eine Version von Apache Flink vor 1.11 verwenden. Möglicherweise müssen Sie auf eine neuere Version von Apache Flink aktualisieren, damit eine KPL-Version von 0.14 oder höher verwendet wird.
+ **Die Anwendung schlägt fehl mit TimeoutException FlinkException, oder RemoteTransportException:** Diese Fehler können in Ihrem Anwendungsprotokoll erscheinen, wenn Ihre Task-Manager abstürzen. Wenn Ihre Anwendung überlastet ist, kann es bei Ihren Aufgabenmanagern zu einer Überlastung der CPU- oder Speicherressourcen kommen, wodurch sie ausfallen.
Diese Fehler können wie folgt aussehen:
+ `java.util.concurrent.TimeoutException: The heartbeat of JobManager with id xxx timed out`
+ `org.apache.flink.util.FlinkException: The assigned slot xxx was removed`
+ `org.apache.flink.runtime.io.network.netty.exception.RemoteTransportException: Connection unexpectedly closed by remote task manager`
Um dieses Problem zu beheben, überprüfen Sie Folgendes:
+ Überprüfen Sie Ihre CloudWatch Messwerte auf ungewöhnliche Spitzen bei der CPU- oder Speicherauslastung.
+ Überprüfen Sie Ihre Anwendung auf Durchsatzprobleme. Weitere Informationen finden Sie unter [Beheben Sie Leistungsprobleme](performance-troubleshooting.md).
+ Untersuchen Sie Ihr Anwendungsprotokoll auf unbehandelte Ausnahmen, die Ihr Anwendungscode auslöst.
+ Die **Anwendung schlägt mit dem Fehler JaxbAnnotationModule Not Found fehl:** Dieser Fehler tritt auf, wenn Ihre Anwendung Apache Beam verwendet, aber nicht über die richtigen Abhängigkeiten oder Abhängigkeitsversionen verfügt. Anwendungen, die Managed Service für Apache Flink nutzen und Apache Beam verwenden, müssen die folgenden Versionen von Abhängigkeiten verwenden:
```
2.10.2
...
com.fasterxml.jackson.module
jackson-module-jaxb-annotations
2.10.2
```
Wenn Sie nicht die richtige Version von `jackson-module-jaxb-annotations` als explizite Abhängigkeit angeben, lädt Ihre Anwendung sie aus den Umgebungsabhängigkeiten, und da die Versionen nicht übereinstimmen, stürzt die Anwendung zur Laufzeit ab.
Weitere Informationen zum Verwenden von Apache Beam mit Managed Service für Apache Flink finden Sie unter [Verwenden CloudFormationErstellen einer Anwendung mit Apache Beam](examples-beam.md).
+ **Die Anwendung schlägt mit java.io fehl. IOException: Unzureichende Anzahl von Netzwerkpuffern**
Dies passiert, wenn einer Anwendung nicht genügend Speicher für Netzwerkpuffer zugewiesen ist. Netzwerkpuffer erleichtern die Kommunikation zwischen Unteraufgaben. Sie werden verwendet, um Datensätze vor der Übertragung über ein Netzwerk zu speichern und eingehende Daten zu speichern, bevor sie in Datensätze zerlegt und an Unteraufgaben übergeben werden. Die Anzahl der benötigten Netzwerkpuffer hängt direkt von der Parallelität und Komplexität Ihres Auftragsdiagramms ab. Es gibt eine Reihe von Ansätzen, um dieses Problem zu beheben:
+ Sie können einen niedrigeren Wert für `parallelismPerKpu` konfigurieren, sodass pro Unteraufgabe und Netzwerkpuffer mehr Speicher zugewiesen wird. Beachten Sie, dass eine Senkung des Werts für `parallelismPerKpu` die KPU und damit die Kosten erhöht. Um dies zu vermeiden, können Sie die gleiche Menge an KPU beibehalten, indem Sie die Parallelität um denselben Faktor verringern.
+ Sie können Ihr Auftragsdiagramm vereinfachen, indem Sie die Anzahl der Operatoren reduzieren oder sie so verketten, dass weniger Puffer benötigt werden.
+ Andernfalls können Sie sich an https://aws.amazon.com/premiumsupport/ eine benutzerdefinierte Netzwerkpufferkonfiguration wenden.
# Der Durchsatz ist zu langsam
Wenn Ihre Anwendung eingehende Streaming-Daten nicht schnell genug verarbeitet, funktioniert sie schlecht und wird instabil. In diesem Abschnitt werden Symptome und Schritte zur Behebung dieses Problems beschrieben.
## Symptome
Dieser Zustand kann folgende Symptome aufweisen:
+ Wenn die Datenquelle für Ihre Anwendung ein Kinesis-Stream ist, nimmt die `millisbehindLatest`-Metrik des Streams kontinuierlich zu.
+ Wenn es sich bei der Datenquelle für Ihre Anwendung um einen Amazon-MSK-Cluster handelt, nehmen die Verbraucherverzögerungsmetriken des Clusters kontinuierlich zu. Weitere Informationen finden Sie unter [ Verbraucherverzögerungsüberwachung](https://docs.aws.amazon.com/msk/latest/developerguide/consumer-lag.html) im [ Amazon MSK Entwicklerhandbuch](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html).
+ Wenn es sich bei der Datenquelle für Ihre Anwendung um einen anderen Service oder eine andere Quelle handelt, überprüfen Sie alle verfügbaren Verbraucherverzögerungsmetriken oder –daten.
## Ursachen und Lösungen
Es kann viele Ursachen für einen langsamen Anwendungsdurchsatz geben. Wenn Ihre Anwendung mit den Eingaben nicht Schritt hält, überprüfen Sie Folgendes:
+ Wenn die Durchsatzverzögerung stark ansteigt und dann abnimmt, überprüfen Sie, ob die Anwendung neu gestartet wird. Ihre Anwendung stoppt die Verarbeitung von Eingaben, während sie neu gestartet wird, was zu einem Anstieg der Verzögerung führt. Weitere Informationen über Anwendungsausfälle finden Sie unter [Die Anwendung wird neu gestartet](troubleshooting-rt-restarts.md).
+ Wenn die Durchsatzverzögerung konstant ist, überprüfen Sie, ob Ihre Anwendung leistungsoptimiert ist. Informationen zur Optimierung der Leistung Ihrer Anwendung finden Sie unter [Beheben Sie Leistungsprobleme](performance-troubleshooting.md).
+ Wenn die Durchsatzverzögerung nicht in die Höhe schnellt, sondern kontinuierlich zunimmt und Ihre Anwendung leistungsoptimiert ist, müssen Sie Ihre Anwendungsressourcen erhöhen. Informationen zur Erhöhung der Anwendungsressourcen finden Sie unter [Implementieren Sie Anwendungsskalierung](how-scaling.md).
+ Wenn Ihre Anwendung aus einem Kafka-Cluster in einer anderen Region liest und `FlinkKafkaConsumer` oder `KafkaSource` sich trotz hoher Verbraucherverzögerung größtenteils im Leerlauf befindet (hohe `idleTimeMsPerSecond` oder niedrige `CPUUtilization`), können Sie den Wert für `receive.buffer.byte` erhöhen, z. B. auf 2097152. Weitere Informationen finden Sie im Abschnitt zu einer Umgebung mit hoher Latenz unter [Benutzerdefinierte MSK-Konfigurationen](https://docs.aws.amazon.com/msk/latest/developerguide/msk-configuration-properties.html).
Schritte zur Problembehebung bei langsamem Durchsatz oder zunehmender Verbraucherverzögerung in der Anwendungsquelle finden Sie unter [Beheben Sie Leistungsprobleme](performance-troubleshooting.md).
# Unbegrenztes Staatswachstum
Wenn Ihre Anwendung veraltete Zustandsinformationen nicht ordnungsgemäß löscht, sammeln sich diese kontinuierlich an und führen zu Leistungs- oder Stabilitätsproblemen der Anwendung. In diesem Abschnitt werden Symptome und Schritte zur Behebung dieses Problems beschrieben.
## Symptome
Dieses Problem kann folgende Symptome aufweisen:
+ Die `lastCheckpointDuration`-Metrik nimmt allmählich zu oder steigt sprunghaft an.
+ Die `lastCheckpointSize`-Metrik nimmt allmählich zu oder steigt sprunghaft an.
## Ursachen und Lösungen
Die folgenden Bedingungen können dazu führen, dass Ihre Anwendung Zustandsdaten ansammelt:
+ In Ihrer Anwendung werden Zustandsdaten länger aufbewahrt, als sie benötigt werden.
+ Ihre Anwendung verwendet Fensterabfragen mit einer zu langen Dauer.
+ Sie haben TTL für Ihre Zustandsdaten nicht festgelegt. Weitere Informationen finden Sie unter [State Time-To-Live (TTL)](https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/dev/datastream/fault-tolerance/state/#state-time-to-live-ttl) in der Apache Flink-Dokumentation.
+ Sie führen eine Anwendung aus, die von Apache Beam Version 2.25.0 oder neuer abhängt. Sie können sich von der neuen Version der Lesetransformation abmelden, indem Sie [Ihre BeamApplicationProperties mit den wichtigsten Experimenten und Werten erweitern](https://docs.aws.amazon.com/managed-flink/latest/java/examples-beam.html#examples-beam-configure). `use_deprecated_read` Weitere Informationen finden Sie in der [Apache-Beam-Dokumentation](https://beam.apache.org/blog/beam-2.25.0/#highlights).
Manchmal sind Anwendungen mit einem stetigen Zuwachs der Zustandsgröße konfrontiert, was auf lange Sicht nicht nachhaltig ist (eine Flink-Anwendung läuft schließlich unbegrenzt). Manchmal kann dies darauf zurückgeführt werden, dass Anwendungen Daten im Zustand speichern und alte Informationen nicht ordnungsgemäß veralten lassen. Aber manchmal werden einfach unangemessene Erwartungen an das gestellt, was Flink bieten kann. Anwendungen können Aggregationen über große Zeitfenster hinweg verwenden, die sich über Tage oder sogar Wochen erstrecken. Sofern sie nicht verwendet [AggregateFunctions](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/windows/#aggregatefunction)werden, die inkrementelle Aggregationen ermöglichen, muss Flink die Ereignisse des gesamten Fensters im Status halten.
Darüber hinaus muss die Anwendung bei der Verwendung von Prozessfunktionen zur Implementierung benutzerdefinierter Operatoren Daten aus dem Zustand entfernen, die für die Geschäftslogik nicht mehr benötigt werden. In diesem Fall time-to-live kann der [Status](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/fault-tolerance/state/#state-time-to-live-ttl) verwendet werden, um Daten basierend auf der Verarbeitungszeit automatisch zu altern. Managed Service für Apache Flink verwendet inkrementelle Checkpoints, weshalb Zustand TTL auf der [RocksDB-Verdichtung](https://github.com/facebook/rocksdb/wiki/Compaction) basiert. Sie können eine tatsächliche Verringerung der Zustandsgröße (angezeigt durch die Checkpoint-Größe) erst beobachten, nachdem ein Verdichtungsvorgang durchgeführt wurde. Insbesondere bei Checkpoint-Größen unter 200 MB ist es unwahrscheinlich, dass Sie aufgrund des Ablaufs des Zustands eine Verringerung der Checkpoint-Größe feststellen. Savepoints basieren jedoch auf einer sauberen Kopie des Zustands, die keine alten Daten enthält. Sie können also in Managed Service für Apache Flink einen Snapshot auslösen, um die Entfernung eines veralteten Zustands zu erzwingen.
Zu Debugging-Zwecken kann es sinnvoll sein, inkrementelle Checkpoints zu deaktivieren, um schneller zu überprüfen, ob die Checkpoint-Größe tatsächlich abnimmt oder sich stabilisiert (und um den Effekt der Verdichtung in RocksBS zu vermeiden). Dafür ist allerdings ein Ticket an das Serviceteam erforderlich.
# E/A-gebundene Operatoren
Es empfiehlt sich, Abhängigkeiten von externen Systemen auf dem Datenpfad zu vermeiden. Es ist oft viel leistungsfähiger, einen Referenzdatensatz im Zustand zu halten, als ein externes System abzufragen, um einzelne Ereignisse anzureichern. Manchmal gibt es jedoch Abhängigkeiten, die nicht einfach in den Zustand versetzt werden können, z. B. wenn Sie Ereignisse mit einem auf Amazon Sagemaker gehosteten Machine-Learning-Modell anreichern möchten.
Operatoren, die über das Netzwerk Schnittstellen zu externen Systemen herstellen, können zu einem Engpass werden und zu Gegendruck führen. Es wird dringend empfohlen, [AsyncIO](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/asyncio/) zur Implementierung der Funktionalität zu verwenden, um die Wartezeit für einzelne Anrufe zu reduzieren und zu verhindern, dass die gesamte Anwendung langsamer wird.
Darüber hinaus kann es für Anwendungen mit I/O gebundenen Operatoren auch sinnvoll sein, die [ParallelismPerKPU-Einstellung](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_ParallelismConfiguration.html) der Anwendung Managed Service for Apache Flink zu erhöhen. Diese Konfiguration beschreibt die Anzahl der parallelen Unteraufgaben, die eine Anwendung pro Kinesis Processing Unit (KPU) ausführen kann. Wenn der Standardwert von 1 auf beispielsweise 4 erhöht wird, nutzt die Anwendung dieselben Ressourcen (und hat dieselben Kosten), kann aber auf das Vierfache der Parallelität skaliert werden. Dies funktioniert gut für I/O gebundene Anwendungen, verursacht jedoch zusätzlichen Overhead für Anwendungen, die nicht I/O gebunden sind.
# Upstream- oder Quelldrosselung aus einem Kinesis-Datenstrom
**Symptom**: Die Anwendung stößt auf `LimitExceededExceptions` aus ihrem Upstream-Kinesis-Datenstrom.
**Mögliche Ursache**: Die Standardeinstellung für den Kinesis-Konnektor der Apache-Flink-Bibliothek ist so eingestellt, dass er aus der Kinesis-Datenstromquelle liest, wobei eine sehr aggressive Standardeinstellung für die maximale Anzahl von Datensätzen gilt, die pro `GetRecords`-Aufruf abgerufen werden. Apache Flink ist standardmäßig so konfiguriert, dass 10.000 Datensätze pro `GetRecords` Aufruf abgerufen werden (dieser Aufruf erfolgt standardmäßig alle 200 ms), obwohl das Limit pro Shard nur 1.000 Datensätze beträgt.
Dieses Standardverhalten kann zu Drosselung führen, wenn versucht wird, Daten aus dem Kinesis-Datenstrom zu verbrauchen, was sich auf die Leistung und Stabilität der Anwendung auswirkt.
Sie können dies überprüfen, indem Sie die CloudWatch `ReadProvisionedThroughputExceeded` Metrik überprüfen und sich längere oder anhaltende Zeiträume ansehen, in denen diese Metrik größer als Null ist.
Sie können dies auch in den CloudWatch Protokollen Ihrer Amazon Managed Service for Apache Flink-Anwendung sehen, indem Sie anhaltende `LimitExceededException` Fehler beobachten.
**Lösung**: Sie können eines von zwei Dingen tun, um dieses Szenario zu lösen:
+ Senken Sie das Standardlimit für die Anzahl der pro `GetRecords` Anruf abgerufenen Datensätze
+ Aktivieren Sie Adaptive Reads in Ihrer Amazon Managed Service für Apache Flink-Anwendung. Weitere Informationen zum Feature Adaptive Reads finden Sie unter [SHARD\$1USE\$1ADAPTIVE\$1READS](https://nightlies.apache.org/flink/flink-docs-release-1.10/api/java/org/apache/flink/streaming/connectors/kinesis/config/ConsumerConfigConstants.html#SHARD_USE_ADAPTIVE_READS)
# Checkpoints
Checkpoints sind der Mechanismus von Flink, der sicherstellt, dass der Zustand einer Anwendung fehlertolerant ist. Dieser Mechanismus ermöglicht es Flink, den Status der Operatoren wiederherzustellen, falls der Auftrag fehlschlägt, und verleiht der Anwendung dieselbe Semantik wie bei einer fehlerfreien Ausführung. Mit Managed Service for Apache Flink wird der Status einer Anwendung in RocksDB gespeichert, einem eingebetteten key/value Speicher, der den Betriebsstatus auf der Festplatte beibehält. Wenn ein Checkpoint erreicht wird, wird der Zustand auch auf Amazon S3 hochgeladen. Selbst wenn die Festplatte verloren geht, kann der Checkpoint verwendet werden, um den Zustand der Anwendung wiederherzustellen.
Weitere Informationen finden Sie unter [Wie funktionieren Zustand-Snapshots?](https://nightlies.apache.org/flink/flink-docs-master/docs/learn-flink/fault_tolerance/#how-does-state-snapshotting-work)
## Checkpointing-Phasen
Für eine Checkpointing-Operator-Unteraufgabe in Flink gibt es 5 Hauptphasen:
+ Warten [**Startverzögerung**] – Flink verwendet Checkpoint-Barrieren, die in den Stream eingefügt werden. Die Zeit in dieser Phase ist also die Zeit, in der der Operator darauf wartet, dass die Checkpoint-Barriere sie erreicht.
+ Ausrichtung [**Ausrichtungsdauer**] – In dieser Phase hat die Unteraufgabe eine Barriere erreicht, wartet aber auf Barrieren aus anderen Eingabeströmen.
+ Sync-Checkpointing [**Sync-Dauer**] – In dieser Phase nimmt die Unteraufgabe tatsächlich einen Snapshot des Zustands des Operators auf und blockiert alle anderen Aktivitäten in der Unteraufgabe.
+ Async-Checkpointing [**Async-Dauer**] – Der Großteil dieser Phase besteht aus der Unteraufgabe, den Zustand auf Amazon S3 hochzuladen. Während dieser Phase ist die Unteraufgabe nicht mehr blockiert und kann Datensätze verarbeiten.
+ Bestätigung — In der Regel handelt es sich dabei um eine kurze Phase. Dabei handelt es sich lediglich um eine Unteraufgabe, die eine Bestätigung an die Datei sendet JobManager und auch alle Commit-Nachrichten ausführt (z. B. bei Kafka-Senken).
Jede dieser Phasen (außer Bestätigung) ist einer Dauermetrik für Checkpoints zugeordnet, die über die Flink-WebUI verfügbar ist und die dazu beitragen kann, die Ursache für den langen Checkpoint zu isolieren.
Eine genaue Definition der einzelnen für Checkpoints verfügbaren Metriken finden Sie auf der [Registerkarte Verlauf](https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/monitoring/checkpoint_monitoring/#history-tab).
## Untersuchen
Bei der Untersuchung einer langen Checkpoint-Dauer ist es am wichtigsten, den Engpass für den Checkpoint zu ermitteln, d. h. welcher Operator und welche Unteraufgabe am längsten bis zum Checkpoint benötigt und welche Phase dieser Unteraufgabe länger dauert. Dies kann mithilfe der Flink-WebUI unter der Aufgabe Aufträge Checkpoint ermittelt werden. Die Weboberfläche von Flink bietet Daten und Informationen, die bei der Untersuchung von Checkpoint-Problemen helfen. Eine vollständige Aufschlüsselung finden Sie unter [Überwachen des Checkpointing](https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/monitoring/checkpoint_monitoring/).
Als Erstes sollten Sie sich die **Gesamtdauer** jedes Operators im Auftragsdiagramm ansehen, um festzustellen, welcher Operator lange braucht, um den Checkpoint zu erreichen, und wo weitere Untersuchungen erforderlich sind. Gemäß der Flink-Dokumentation lautet die Definition der Dauer wie folgt:
*Die Dauer vom Trigger-Zeitstempel bis zur letzten Bestätigung (oder falls noch keine Bestätigung eingegangen ist). n/a Diese Gesamtdauer für einen vollständigen Checkpoint wird durch die letzte Unteraufgabe bestimmt, die den Checkpoint bestätigt. Diese Zeit ist normalerweise länger, als einzelne Teilaufgaben benötigen, um tatsächlich einen Checkpoint des Zustands zu erstellen.*
Die anderen Zeitdauerangaben für den Checkpoint geben auch detailliertere Informationen darüber, wo die Zeit verbracht wird.
Wenn die **Sync-Dauer** hoch ist, deutet dies darauf hin, dass während der Snapshot-Erstellung etwas passiert. In dieser Phase wird `snapshotState()` für Klassen aufgerufen, die die SnapshotState-Schnittstelle implementieren. Dabei kann es sich um Benutzercode handeln, sodass Thread-Dumps nützlich sein können, um dies zu untersuchen.
Eine lange **Async-Dauer** würde darauf hindeuten, dass viel Zeit für das Hochladen des Zustands auf Amazon S3 aufgewendet wird. Dies kann der Fall sein, wenn der Zustand groß ist oder wenn viele Zustandsdateien hochgeladen werden. Wenn dies der Fall ist, lohnt es sich zu untersuchen, wie der Zustand von der Anwendung verwendet wird, und sicherzustellen, dass die systemeigenen Flink-Datenstrukturen verwendet werden, wo immer dies möglich ist ([Gekennzeichneten Zustand verwenden](https://nightlies.apache.org/flink/flink-docs-master/docs/dev/datastream/fault-tolerance/state/#using-keyed-state)). Managed Service für Apache Flink konfiguriert Flink so, dass die Anzahl der Amazon-S3-Aufrufe minimiert wird, um sicherzustellen, dass diese nicht zu lang werden. Im Folgenden finden Sie ein Beispiel für die Checkpoint-Statistiken eines Operators. Es zeigt, dass die **Async-Dauer** im Vergleich zu den vorherigen Checkpoint-Statistiken für Operatoren relativ lang ist.
![\[Untersuchen des Checkpointing\]](http://docs.aws.amazon.com/de_de/managed-flink/latest/java/images/checkpoint.png)
Eine hohe **Startverzögerung** würde bedeuten, dass die meiste Zeit damit verbracht wird, darauf zu warten, dass die Checkpoint-Barriere den Operator erreicht. Dies deutet darauf hin, dass die Anwendung eine Weile benötigt, um Datensätze zu verarbeiten, was bedeutet, dass die Barriere langsam durch das Auftragsdiagramm fließt. Dies ist normalerweise der Fall, wenn der Auftrag Gegendruck erhält oder wenn ein oder mehrere Operatoren ständig beschäftigt sind. Es folgt ein Beispiel für eine, bei der der zweite Operator JobGraph beschäftigt ist. KeyedProcess
![\[Untersuchen des Checkpointing\]](http://docs.aws.amazon.com/de_de/managed-flink/latest/java/images/checkpoint2.png)
Sie können untersuchen, was so lange dauert, indem Sie entweder Flink Flame Graphs oder TaskManager Thread-Dumps verwenden. Sobald der Engpass identifiziert wurde, kann er mithilfe von Flame-Diagrammen oder Thread-Dumps weiter untersucht werden.
## Thread-Dumps
Thread-Dumps sind ein weiteres Debugging-Tool auf einer etwas niedrigeren Ebene als Flame-Diagramme. Ein Thread-Dump gibt den Ausführungszustand aller Threads zu einem bestimmten Zeitpunkt aus. Flink nimmt einen JVM-Thread-Dump, der den Ausführungszustand aller Threads innerhalb des Flink-Prozesses darstellt. Der Zustand eines Threads wird durch einen Stack-Trace des Threads sowie durch einige zusätzliche Informationen dargestellt. Flame-Diagramme werden tatsächlich aus mehreren Stack-Traces erstellt, die schnell hintereinander aufgenommen wurden. Das Diagramm ist eine aus diesen Traces erstellte Visualisierung, die es einfach macht, die gemeinsamen Codepfade zu identifizieren.
```
"KeyedProcess (1/3)#0" prio=5 Id=1423 RUNNABLE
at app//scala.collection.immutable.Range.foreach$mVc$sp(Range.scala:154)
at $line33.$read$$iw$$iw$ExpensiveFunction.processElement(>19)
at $line33.$read$$iw$$iw$ExpensiveFunction.processElement(:14)
at app//org.apache.flink.streaming.api.operators.KeyedProcessOperator.processElement(KeyedProcessOperator.java:83)
at app//org.apache.flink.streaming.runtime.tasks.OneInputStreamTask$StreamTaskNetworkOutput.emitRecord(OneInputStreamTask.java:205)
at app//org.apache.flink.streaming.runtime.io.AbstractStreamTaskNetworkInput.processElement(AbstractStreamTaskNetworkInput.java:134)
at app//org.apache.flink.streaming.runtime.io.AbstractStreamTaskNetworkInput.emitNext(AbstractStreamTaskNetworkInput.java:105)
at app//org.apache.flink.streaming.runtime.io.StreamOneInputProcessor.processInput(StreamOneInputProcessor.java:66)
...
```
Oben sehen Sie einen Ausschnitt eines Thread-Dumps aus der Flink-Benutzeroberfläche für einen einzelnen Thread. Die erste Zeile enthält einige allgemeine Informationen zu diesem Thread, darunter:
+ Der Thread-Name *KeyedProcess (1/3) \$10*
+ Priorität des Threads *prio=5*
+ Eine eindeutige Thread-ID *Id=1423*
+ Thread-Status *RUNNABLE*
Der Name eines Threads gibt normalerweise Auskunft über den allgemeinen Zweck des Threads. Operator-Threads können anhand ihres Namens identifiziert werden, da Operator-Threads denselben Namen wie der Operator haben und außerdem angeben, zu welcher Unteraufgabe sie gehören, z. B. ist der Thread *KeyedProcess (1/3) \$10* vom *KeyedProcess*Operator und von der ersten (von 3) Unteraufgabe.
Threads können sich in einem von wenigen Zuständen befinden:
+ NEW – Der Thread wurde erstellt, aber noch nicht verarbeitet
+ RUNNABLE – Der Thread wird auf der CPU ausgeführt
+ BLOCKED – Der Thread wartet darauf, dass ein anderer Thread seine Sperre freigibt
+ WAITING – Der Thread wartet mit einer `wait()`-, `join()`-, oder `park()`-Methode
+ TIMED\$1WAITING – Der Thread wartet mit einer Sleep-, Wait-, Join- oder Park-Methode, jedoch mit einer maximalen Wartezeit.
**Anmerkung**
In Flink 1.13 ist die maximale Tiefe eines einzelnen Stack-Trace im Thread-Dump auf 8 begrenzt.
**Anmerkung**
Thread-Dumps sollten das letzte Mittel zum Debuggen von Leistungsproblemen in einer Flink-Anwendung sein, da sie schwierig zu lesen sein können und die Entnahme mehrerer Stichproben und deren manuelle Analyse erfordern. Wenn möglich, ist es vorzuziehen, Flame-Diagramme zu verwenden.
### Thread-Dumps in Flink
In Flink kann ein Thread-Dump erstellt werden, indem Sie in der linken Navigationsleiste der Flink-Benutzeroberfläche die Option **Aufgabenmanager** auswählen, einen bestimmten Aufgabenmanager auswählen und dann zur Registerkarte **Thread-Dump** navigieren. Der Thread-Dump kann heruntergeladen, in Ihren bevorzugten Texteditor (oder Thread-Dump-Analysator) kopiert oder direkt in der Textansicht in der Flink-Web-UI analysiert werden (diese letzte Option kann jedoch etwas umständlich sein).
Um zu bestimmen, welcher Task Manager verwendet werden soll, kann ein Thread-Dump des **TaskManagers**Tabs verwendet werden, wenn ein bestimmter Operator ausgewählt wird. Dies zeigt, dass der Operator für verschiedene Unteraufgaben eines Operators ausgeführt wird und auf verschiedenen Aufgabenmanagern ausgeführt werden kann.
![\[Verwenden von Thread-Dumps\]](http://docs.aws.amazon.com/de_de/managed-flink/latest/java/images/checkpoint4.png)
Der Dump wird aus mehreren Stack-Traces bestehen. Bei der Untersuchung des Dumps sind jedoch diejenigen am wichtigsten, die sich auf einen Operator beziehen. Diese können leicht gefunden werden, da Operator-Threads denselben Namen wie der Operator haben und auch angeben, auf welche Unteraufgabe sie sich beziehen. Zum Beispiel stammt der folgende Stack-Trace vom *KeyedProcess*Operator und ist die erste Unteraufgabe.
```
"KeyedProcess (1/3)#0" prio=5 Id=595 RUNNABLE
at app//scala.collection.immutable.Range.foreach$mVc$sp(Range.scala:155)
at $line360.$read$$iw$$iw$ExpensiveFunction.processElement(:19)
at $line360.$read$$iw$$iw$ExpensiveFunction.processElement(:14)
at app//org.apache.flink.streaming.api.operators.KeyedProcessOperator.processElement(KeyedProcessOperator.java:83)
at app//org.apache.flink.streaming.runtime.tasks.OneInputStreamTask$StreamTaskNetworkOutput.emitRecord(OneInputStreamTask.java:205)
at app//org.apache.flink.streaming.runtime.io.AbstractStreamTaskNetworkInput.processElement(AbstractStreamTaskNetworkInput.java:134)
at app//org.apache.flink.streaming.runtime.io.AbstractStreamTaskNetworkInput.emitNext(AbstractStreamTaskNetworkInput.java:105)
at app//org.apache.flink.streaming.runtime.io.StreamOneInputProcessor.processInput(StreamOneInputProcessor.java:66)
...
```
Dies kann verwirrend werden, wenn es mehrere Operatoren mit demselben Namen gibt, aber wir können Operatoren benennen, um dies zu umgehen. Beispiel:
```
....
.process(new ExpensiveFunction).name("Expensive function")
```
## [Flame-Diagramme](https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/debugging/flame_graphs/)
Flame-Diagramme sind ein nützliches Debugging-Tool, das die Stack-Traces des Zielcodes visualisiert und so die Identifizierung der häufigsten Codepfade ermöglicht. Sie werden erstellt, indem Stack-Traces mehrmals abgetastet werden. Die X-Achse eines Flame-Diagramms zeigt die verschiedenen Stack-Profile, während die Y-Achse die Stack-Tiefe und die Aufrufe des Stack-Trace zeigt. Ein einzelnes Rechteck in einem Flame-Diagramm steht für einen Stack-Frame, und die Breite eines Frames gibt an, wie häufig es in den Stacks vorkommt. Weitere Informationen über Flame-Diagramme und deren Nutzung finden Sie unter [Flame-Diagramme](https://www.brendangregg.com/flamegraphs.html).
In Flink kann das Flame-Diagramm für einen Operator über die Weboberfläche aufgerufen werden, indem Sie einen Operator und dann die **FlameGraph**Registerkarte auswählen. Sobald genügend Proben gesammelt wurden, wird das Flame-Diagramm angezeigt. Im Folgenden finden Sie das FlameGraph für den ProcessFunction , dessen Checkpoint viel Zeit in Anspruch genommen hat.
![\[Verwenden von Flame-Diagrammen\]](http://docs.aws.amazon.com/de_de/managed-flink/latest/java/images/checkpoint3.png)
Dies ist ein sehr einfaches Flammendiagramm, das zeigt, dass die gesamte CPU-Zeit für einen Blick innerhalb `processElement` des ExpensiveFunction Bedieners aufgewendet wird. Sie erhalten auch die Zeilennummer, anhand derer Sie feststellen können, wo die Codeausführung stattfindet.
# Beim Checkpointing kommt es zu einer Zeitüberschreitung
Wenn Ihre Anwendung nicht optimiert oder ordnungsgemäß bereitgestellt ist, können Checkpoints fehlschlagen. In diesem Abschnitt werden Symptome und Schritte zur Behebung dieses Problems beschrieben.
## Symptome
Wenn Checkpoints für Ihre Anwendung fehlschlagen, ist der Wert von `numberOfFailedCheckpoints` größer als Null.
Checkpoints können entweder aufgrund direkter Fehler, wie Anwendungsfehler, oder aufgrund vorübergehender Fehler, z. B. aufgrund unzureichender Anwendungsressourcen, fehlschlagen. Überprüfen Sie Ihre Anwendungsprotokolle und Metriken auf die folgenden Symptome:
+ Fehler in Ihrem Code.
+ Fehler beim Zugriff auf die abhängigen Services Ihrer Anwendung.
+ Fehler beim Serialisieren von Daten. Wenn der Standard-Serializer Ihre Anwendungsdaten nicht serialisieren kann, schlägt die Anwendung fehl. Informationen zur Verwendung eines benutzerdefinierten Serializers in Ihrer Anwendung finden Sie unter [Datentypen und Serialisierung](https://nightlies.apache.org/flink/flink-docs-release-1.19/docs/dev/datastream/fault-tolerance/serialization/types_serialization/) in der Apache Flink-Dokumentation.
+ Fehler wegen Speichermangel.
+ Spitzen oder stetiger Anstieg der folgenden Metriken:
+ `heapMemoryUtilization`
+ `oldGenerationGCTime`
+ `oldGenerationGCCount`
+ `lastCheckpointSize`
+ `lastCheckpointDuration`
Weitere Informationen zur Überwachung von Checkpoints finden Sie unter [Monitoring Checkpointing](https://nightlies.apache.org/flink/flink-docs-release-1.19/docs/ops/monitoring/checkpoint_monitoring/) in der Apache Flink-Dokumentation.
## Ursachen und Lösungen
Die Fehlermeldungen im Anwendungsprotokoll zeigen die Ursache für direkte Fehler. Vorübergehende Fehler können folgende Ursachen haben:
+ Ihre Anwendung verfügt über eine unzureichende KPU-Bereitstellung. Informationen zur Erhöhung der Anwendungsbereitstellung finden Sie unter [Implementieren Sie Anwendungsskalierung](how-scaling.md).
+ Die Größe des Anwendungszustands ist zu hoch. Sie können die Größe Ihres Anwendungszustands anhand der `lastCheckpointSize`-Metrik überwachen.
+ Die Zustandsdaten Ihrer Anwendung sind ungleich auf die Schlüssel verteilt. Wenn Ihre Anwendung den `KeyBy`-Operator verwendet, stellen Sie sicher, dass Ihre eingehenden Daten gleichmäßig auf die Schlüssel aufgeteilt werden. Wenn die meisten Daten einem einzigen Schlüssel zugewiesen werden, entsteht ein Engpass, der zu Fehlern führt.
+ Ihre Anwendung leidet unter einem Gegendruck im Speicher oder bei der Garbage Collection. Überwachen Sie `heapMemoryUtilization`, `oldGenerationGCTime` und `oldGenerationGCCount` Ihrer Anwendung auf Spitzen oder stetig steigende Werte.
# Checkpoint-Fehler für Apache-Beam-Anwendung
Wenn Ihre Beam-Anwendung auf 0 ms konfiguriert ist, können Checkpoints möglicherweise nicht ausgelöst werden, da sich die Aufgaben im Status „ABGESCHLOSSEN“ befinden. [shutdownSourcesAfterIdleMs](https://beam.apache.org/documentation/runners/flink/#:~:text=shutdownSourcesAfterIdleMs) In diesem Abschnitt werden Symptome und Lösungen für diesen Zustand beschrieben.
## Symptom
Rufen Sie die CloudWatch Anwendungsprotokolle Ihres Managed Service for Apache Flink auf und überprüfen Sie, ob die folgende Protokollmeldung protokolliert wurde. Die folgende Protokollmeldung weist darauf hin, dass der Checkpoint nicht ausgelöst werden konnte, da einige Aufgaben abgeschlossen wurden.
```
{
"locationInformation": "org.apache.flink.runtime.checkpoint.CheckpointCoordinator.onTriggerFailure(CheckpointCoordinator.java:888)",
"logger": "org.apache.flink.runtime.checkpoint.CheckpointCoordinator",
"message": "Failed to trigger checkpoint for job your job ID since some tasks of job your job ID has been finished, abort the checkpoint Failure reason: Not all required tasks are currently running.",
"threadName": "Checkpoint Timer",
"applicationARN": your application ARN,
"applicationVersionId": "5",
"messageSchemaVersion": "1",
"messageType": "INFO"
}
```
Dies kann auch im Flink-Dashboard gefunden werden, wo einige Aufgaben den Zustand „ABGESCHLOSSEN“ erreicht haben und Checkpointing nicht mehr möglich ist.
![\[Aufgaben im Zustand „ABGESCHLOSSEN“\]](http://docs.aws.amazon.com/de_de/managed-flink/latest/java/images/beam_checkpoint_failure.png)
## Ursache
shutdownSourcesAfterIdleMs ist eine Beam-Konfigurationsvariable, die Quellen herunterfährt, die für die konfigurierte Zeit von Millisekunden inaktiv waren. Sobald eine Quelle heruntergefahren wurde, ist Checkpointing nicht mehr möglich. Dies könnte zu einem [Checkpoint-Fehler](https://issues.apache.org/jira/browse/FLINK-2491) führen.
Einer der Gründe dafür, dass Aufgaben in den Status „FINISHED“ wechseln, ist, wenn sie auf 0 ms gesetzt shutdownSourcesAfter IdleMs ist, was bedeutet, dass Aufgaben, die sich im Leerlauf befinden, sofort heruntergefahren werden.
## Lösung
Um zu verhindern, dass Aufgaben sofort in den Status „FERTIG“ wechseln, legen Sie den Wert shutdownSourcesAfter IdleMs auf LONG.MAX\$1VALUE fest. Es gibt zwei Methoden dafür:
+ Option 1: Wenn Ihre Beam-Konfiguration auf der Konfigurationsseite Ihrer Managed Service for Apache Flink-Anwendung festgelegt ist, können Sie ein neues Schlüsselwertpaar hinzufügen, um Ms wie folgt festzulegen: shutdpwnSourcesAfteridle
![\[Auf shutdownSourcesAfter IdleMs Long.MAX_Value setzen\]](http://docs.aws.amazon.com/de_de/managed-flink/latest/java/images/beam_checkpoint_failure_solution.png)
+ Option 2: Wenn Ihre Beam-Konfiguration in Ihrer JAR-Datei festgelegt ist, können Sie sie wie folgt einstellen: shutdownSourcesAfter IdleMs
```
FlinkPipelineOptions options = PipelineOptionsFactory.create().as(FlinkPipelineOptions.class); // Initialize Beam Options object
options.setShutdownSourcesAfterIdleMs(Long.MAX_VALUE); // set shutdownSourcesAfterIdleMs to Long.MAX_VALUE
options.setRunner(FlinkRunner.class);
Pipeline p = Pipeline.create(options); // attach specified options to Beam pipeline
```
# Gegendruck
Flink nutzt Gegendruck, um die Verarbeitungsgeschwindigkeit einzelner Operatoren anzupassen.
Der Operator kann aus vielen Gründen Schwierigkeiten haben, das Nachrichtenvolumen, das er empfängt, weiter zu verarbeiten. Der Vorgang benötigt möglicherweise mehr CPU-Ressourcen, als der Bediener zur Verfügung hat. Der Bediener kann warten I/O , bis der Vorgang abgeschlossen ist. Wenn ein Operator Ereignisse nicht schnell genug verarbeiten kann, entsteht ein Gegendruck bei den vorgeschalteten Operatoren, die in den langsamen Operator einspeisen. Dies führt dazu, dass die vorgelagerten Operatoren langsamer werden, wodurch sich der Gegendruck zur Quelle weiter ausbreiten kann und die Quelle sich an den Gesamtdurchsatz der Anwendung anpasst, indem sie ebenfalls langsamer wird. Eine ausführlichere Beschreibung von Gegendruck und seiner Funktionsweise finden Sie unter [So handhabt Apache Flink™ Gegendruck](https://www.ververica.com/blog/how-flink-handles-backpressure).
Wenn Sie wissen, welche Operatoren in einer Anwendung langsam sind, erhalten Sie wichtige Informationen, um die Ursache von Leistungsproblemen in der Anwendung zu verstehen. Informationen zum Gegendruck werden [über das Flink-Dashboard angezeigt](https://nightlies.apache.org/flink/flink-docs-stable/docs/ops/monitoring/back_pressure/). Um den langsamen Operator zu identifizieren, suchen Sie nach dem Operator mit einem hohen Gegendruckwert, der einer Senke am nächsten ist (im folgenden Beispiel Operator B). Der Operator, der die Langsamkeit verursacht, ist dann einer der nachgeschalteten Operatoren (im Beispiel Operator C). B könnte Ereignisse schneller verarbeiten, gerät jedoch unter Druck, da er die Ausgabe nicht an den langsamen Operator C weiterleiten kann.
```
A (backpressured 93%) -> B (backpressured 85%) -> C (backpressured 11%) -> D (backpressured 0%)
```
Sobald Sie den langsamen Operator identifiziert haben, versuchen Sie zu verstehen, warum er langsam ist. Es kann viele Gründe dafür geben, und manchmal ist nicht klar, was das Problem ist. Es kann Tage des Debuggens und Profilings erfordern, um das Problem zu lösen. Im Folgenden sind einige offensichtliche und häufigere Gründe aufgeführt, von denen einige im Folgenden näher erläutert werden:
+ Der Operator führt langsame E/A durch, z. B. Netzwerkaufrufe (erwägen Sie stattdessen die Verwendung von AsyncIO).
+ Die Daten sind verzerrt und ein Operator empfängt mehr Ereignisse als andere (überprüfen Sie dies, indem Sie sich die Anzahl der Nachrichten in/out einzelner Unteraufgaben (d. h. Instanzen desselben Operators) im Flink-Dashboard ansehen.
+ Es handelt sich um einen ressourcenintensiven Vorgang (wenn es keinen Datenversatz gibt, sollten Sie eine Skalierung bei gebundener Arbeit oder eine Erhöhung `ParallelismPerKPU` bei CPU/memory gebundener Arbeit in Betracht ziehen) I/O
+ Umfangreiche Protokollierung durch den Operator (reduzieren Sie die Protokollierung auf ein Minimum für Produktionsanwendungen oder erwägen Sie, stattdessen die Debug-Ausgabe an einen Datenstrom zu senden).
## Testen des Durchsatzes mit dem Discarding Sink
Die [Verwurfsenke](https://nightlies.apache.org/flink/flink-docs-stable/api/java/org/apache/flink/streaming/api/functions/sink/DiscardingSink.html) ignoriert einfach alle Ereignisse, die sie empfängt, während die Anwendung weiterhin ausgeführt wird (eine Anwendung ohne Senke kann nicht ausgeführt werden). Dies ist sehr nützlich für Durchsatztests, zum Profiling und um zu überprüfen, ob die Anwendung ordnungsgemäß skaliert. Es ist außerdem eine sehr pragmatische Plausibilitätsprüfung, um zu überprüfen, ob die Senken einen Gegendruck erzeugen oder die Anwendung (aber die bloße Überprüfung der Gegendruckmetriken ist oft einfacher und unkomplizierter).
Indem Sie alle Senken einer Anwendung durch eine Verwurfsenke ersetzen und eine Mock-Quelle erstellen, die Daten generiert, die Produktionsdaten ähneln, können Sie den maximalen Durchsatz der Anwendung für eine bestimmte Parallelitätseinstellung messen. Sie können dann auch die Parallelität erhöhen, um sicherzustellen, dass die Anwendung ordnungsgemäß skaliert und keinen Engpass aufweist, der erst bei höherem Durchsatz auftritt (z. B. aufgrund einer verzerrten Datenverteilung).
# Verzerrte Datenverteilung
Eine Flink-Anwendung wird auf einem Cluster verteilt ausgeführt. Um horizontal auf mehrere Knoten zu skalieren, verwendet Flink das Konzept der verschlüsselten Streams, was im Wesentlichen bedeutet, dass die Ereignisse eines Streams nach einem bestimmten Schlüssel, z. B. einer Kunden-ID, partitioniert werden und Flink dann verschiedene Partitionen auf verschiedenen Knoten verarbeiten kann. Viele der Flink-Operatoren werden dann auf der Grundlage dieser Partitionen ausgewertet, z. B. [Keyed Windows](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/windows/), [Process Functions](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/process_function/) und [Async I/O](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/asyncio/).
Die Auswahl eines Partitionsschlüssels hängt häufig von der Geschäftslogik ab. Gleichzeitig gelten viele der Best Practices für z. B. [DynamoDB](https://aws.amazon.com/dynamodb/) und Spark auch für Flink, darunter:
+ Sicherstellung einer hohen Kardinalität der Partitionsschlüssel
+ Vermeidung von Verzerrungen im Ereignisvolumen zwischen Partitionen
Sie können Verzerrungen in den Partitionen erkennen, indem Sie die Datensätze received/sent von Unteraufgaben (d. h. Instanzen desselben Operators) im Flink-Dashboard vergleichen. Darüber hinaus kann die Überwachung von Managed Service für Apache Flink so konfiguriert werden, dass Metriken auch für `numRecordsIn/Out` und `numRecordsInPerSecond/OutPerSecond` auf Unteraufgabenebene verfügbar gemacht werden.
# Zustandsverzerrung
Bei zustandsbehafteten Operatoren, d. h. Operatoren, die den Zustand für ihre Geschäftslogik verwerten, wie z. B. Fenster, führt eine Verzerrung der Datenverteilung immer zu einer Zustandsverzerrung. Einige Unteraufgaben empfangen aufgrund der Verzerrung der Datenverteilung mehr Ereignisse als andere und behalten daher auch mehr Daten im Zustand. Aber selbst bei einer Anwendung mit gleichmäßig ausgeglichenen Partitionen kann es zu Abweichungen bei der Menge der im Zustand gespeicherten Daten kommen. Beispielsweise können bei Sitzungsfenstern einige Benutzer bzw. Sitzungen viel länger sein als andere. Wenn die längeren Sitzungen zufällig Teil derselben Partition sind, kann dies zu einem Ungleichgewicht der Zustandsgröße führen, die von verschiedenen Unteraufgaben desselben Operators verwaltet wird.
Zustandsverzerrungen erhöhen nicht nur die Arbeitsspeicher- und Festplattenressourcen, die für einzelne Unteraufgaben benötigt werden, sondern sie können auch die Gesamtleistung der Anwendung verringern. Wenn eine Anwendung einen Checkpoint oder Savepoint verwendet, wird der Operatorzustand in Amazon S3 gespeichert, um den Zustand vor Knoten- oder Cluster-Fehlern zu schützen. Während dieses Vorgangs (insbesondere bei genau einer Semantik, die standardmäßig auf Managed Service for Apache Flink aktiviert ist) kommt die Verarbeitung aus externer Sicht zum Stillstand, bis der abgeschlossen ist. checkpoint/savepoint Bei einer verzerrten Datenverteilung kann die Zeit bis zum Abschluss des Vorgangs an eine einzelne Unteraufgabe gebunden sein, die eine besonders hohe Zustandsmenge angesammelt hat. In extremen Fällen checkpoints/savepoints kann der Vorgang fehlschlagen, weil eine einzelne Unteraufgabe den Status nicht beibehalten kann.
Ähnlich wie bei einer verzerrten Datenverteilung kann auch eine Zustandsverzerrung eine Anwendung erheblich verlangsamen.
Um Zustandsverzerrungen zu identifizieren, können Sie das Flink-Dashboard nutzen. Suchen Sie in den Details nach einem aktuellen Checkpoint oder Savepoint und vergleichen Sie die Datenmenge, die für einzelne Unteraufgaben gespeichert wurde.
# Integrieren Sie Ressourcen in verschiedenen Regionen
Sie können `StreamingFileSink` für das Schreiben in einen Amazon-S3-Bucket in einer von Ihrer Anwendung, die Managed Service für Apache Flink nutzt, abweichenden Region über eine Einstellung aktivieren, die für die regionsübergreifende Replikation in der Flink-Konfiguration erforderlich ist. Reichen Sie dazu ein Support-Ticket im [AWS Support Center](https://console.aws.amazon.com/support/home#/) ein.