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 bei Managed Service für Apache Flink
Die folgenden Themen können Ihnen bei der Behebung von Problemen helfen, die möglicherweise mit Amazon Managed Service für Apache Flink auftreten.
Wählen Sie das entsprechende Thema aus, um die Lösungen zu überprüfen.
**Topics**
+ [Fehlerbehebung bei der Entwicklung](troubleshooting-development.md)
+ [Fehlerbehebung während der Laufzeit](troubleshooting-runtime.md)
# Fehlerbehebung bei der Entwicklung
Dieser Abschnitt enthält Informationen zur Diagnose und Behebung von Entwicklungsproblemen mit Ihrer Managed Service for Apache Flink-Anwendung.
**Topics**
+ [Bewährte Methoden für das Rollback von Systemen](troubleshooting-system-rollback.md)
+ [Bewährte Methoden für die Hudi-Konfiguration](troubleshooting-hudi.md)
+ [Apache Flink Flame-Diagramme](troubleshooting-update-flamegraphs.md)
+ [Problem mit dem Anmeldeinformationsanbieter mit dem EFO-Connector 1.15.2](troubleshooting-credential-provider.md)
+ [Anwendungen mit nicht unterstützten Kinesis-Konnektoren](troubleshooting-unsupported-kinesis-connectors.md)
+ [Kompilierungsfehler: „Abhängigkeiten für das Projekt konnten nicht aufgelöst werden“](troubleshooting-compile.md)
+ [Ungültige Auswahl: „kinesisanalyticsv2"](troubleshooting-cli-update.md)
+ [UpdateApplication Aktion ist kein erneutes Laden des Anwendungscodes](troubleshooting-update.md)
+ [S3 StreamingFileSink FileNotFoundExceptions](troubleshooting-s3sink.md)
+ [FlinkKafkaConsumer Problem mit Stop with Savepoint](troubleshooting-FlinkKafkaConsumer.md)
+ [Flink 1.15 Async Sink Deadlock](troubleshooting-async-deadlock.md)
+ [Die Quellverarbeitung von Amazon Kinesis Kinesis-Datenstreams ist beim Re-Sharding nicht in der richtigen Reihenfolge](troubleshooting-kinesis-data-streams-processing-out-of-order.md)
+ [Häufig gestellte Fragen und Problemlösungen zum Einbetten von Vektoren in Echtzeit](troubleshooting-blueprints.md)
# Bewährte Methoden für das Rollback von Systemen
Mit den Funktionen für automatisches System-Rollback und Betriebstransparenz in Amazon Managed Service for Apache Flink können Sie Probleme mit Ihren Anwendungen identifizieren und lösen.
## System-Rollbacks
Wenn Ihr Anwendungsupdate oder Ihr Skalierungsvorgang aufgrund eines Kundenfehlers fehlschlägt, z. B. aufgrund eines Codefehlers oder eines Berechtigungsproblems, versucht Amazon Managed Service für Apache Flink automatisch, zur vorherigen laufenden Version zurückzukehren, sofern Sie sich für diese Funktion entschieden haben. Weitere Informationen finden Sie unter [Aktivieren Sie System-Rollbacks für Ihre Managed Service for Apache Flink-Anwendung](how-system-rollbacks.md). Wenn dieser automatische Rollback fehlschlägt oder Sie sich nicht angemeldet oder abgemeldet haben, wird Ihre Anwendung in den entsprechenden Status versetzt. `READY` Gehen Sie wie folgt vor, um Ihre Bewerbung zu aktualisieren: Sehen Sie in der Amazon Managed Service for Apache Flink-Konsole nach oder verwenden Sie die `DescribeApplicationOperation` API, um die Fehlerbeschreibung zu sehen, warum der Vorgang fehlgeschlagen ist. Verwenden Sie [Cloudwatch-Protokolle](https://docs.aws.amazon.com/managed-flink/latest/java/logging.html), um den vollständigen Fehlerstapel zu erhalten. Häufige Probleme sind unzureichende Berechtigungen, inkompatible Codeänderungen oder Fehlkonfigurationen der Infrastruktur. Beheben Sie das zugrunde liegende Problem. Verwenden Sie die `UpdateApplicaton` API, um Ihre neue Anwendungsversion erneut bereitzustellen.
## Manuelles Rollback
Wenn die Anwendung nicht voranschreitet und sich über einen längeren Zeitraum in einem vorübergehenden Zustand befindet oder wenn die Anwendung erfolgreich umgestellt wurde`Running`, Sie aber nachgelagerte Probleme wie Verarbeitungsfehler in einer erfolgreich aktualisierten Flink-Anwendung feststellen, können Sie sie mithilfe der API manuell rückgängig machen. `RollbackApplication`
1. Aufruf `RollbackApplication` — dadurch wird zur vorherigen laufenden Version zurückgesetzt und der vorherige Status wiederhergestellt.
1. Überwachen Sie den Rollback-Vorgang mithilfe der `DescribeApplicationOperation` API.
1. Wenn das Rollback fehlschlägt, verwenden Sie die vorherigen System-Rollback-Schritte.
## Sichtbarkeit der Abläufe
Die `ListApplicationOperations` API zeigt den Verlauf aller Kunden- und Systemvorgänge in Ihrer Anwendung.
1. Ruft die *OperationID* des fehlgeschlagenen Vorgangs aus der Liste ab.
1. Rufen Sie an `DescribeApplicationOperation` und überprüfen Sie den Status und die *statusDescription*.
1. Wenn ein Vorgang fehlgeschlagen ist, weist die Beschreibung auf einen möglichen Fehler hin, der untersucht werden muss.
**Häufige Fehler im Fehlercode:** Verwenden Sie die Rollback-Funktionen, um zur letzten funktionierenden Version zurückzukehren. Beheben Sie Fehler und versuchen Sie das Update erneut.
**Probleme mit Berechtigungen:** Verwenden Sie den`DescribeApplicationOperation`, um die erforderlichen Berechtigungen einzusehen. Aktualisieren Sie die Anwendungsberechtigungen und versuchen Sie es erneut.
**Serviceprobleme mit Amazon Managed Service für Apache Flink:** Überprüfen Sie den Support-Fall AWS Health Dashboard oder öffnen Sie einen Support-Fall.
# Bewährte Methoden für die Hudi-Konfiguration
Um Hudi-Konnektoren auf Managed Service für Apache Flink auszuführen, empfehlen wir die folgenden Konfigurationsänderungen.
Deaktivieren von `hoodie.embed.timeline.server`
Der Hudi-Connector auf Flink richtet einen eingebetteten Timeline (TM) -Server auf dem Flink Jobmanager (JM) ein, um Metadaten zwischenzuspeichern und so die Leistung bei hoher Jobparallelität zu verbessern. Wir empfehlen, diesen eingebetteten Server im Managed Service für Apache Flink zu deaktivieren, da wir die Nicht-Flink-Kommunikation zwischen JM und TM deaktivieren.
Wenn dieser Server aktiviert ist, versucht Hudi Writes zunächst, eine Verbindung zum eingebetteten Server auf JM herzustellen, und greift dann auf das Lesen von Metadaten aus Amazon S3 zurück. Das bedeutet, dass bei Hudi ein Verbindungs-Timeout auftritt, das Hudi-Schreibvorgänge verzögert und die Leistung von Managed Service for Apache Flink beeinträchtigt.
# Apache Flink Flame-Diagramme
Flame-Diagramme sind für Anwendungen in Versionen von Managed Service für Apache Flink, die Flame-Diagramme unterstützen, standardmäßig aktiviert. Flame-Diagramme können die Leistung der Anwendung beeinträchtigen, wenn Sie das Diagramm geöffnet lassen, wie in der [Flink-Dokumentation](https://nightlies.apache.org/flink/flink-docs-release-1.15//docs/ops/debugging/flame_graphs/) beschrieben.
Wenn Sie Flame-Diagramme für Ihre Anwendung deaktivieren möchten, erstellen Sie einen Fall, um die Deaktivierung für Ihren Anwendungs-ARN anzufordern. Weitere Informationen finden Sie im [AWS Support-Center](https://console.aws.amazon.com/support/home#/).
# Problem mit dem Anmeldeinformationsanbieter mit dem EFO-Connector 1.15.2
Es gibt ein [bekanntes Problem](https://issues.apache.org/jira/browse/FLINK-29205) mit EFO-Konnektor-Versionen bis 1.15.2 von Kinesis Data Streams, bei dem der `FlinkKinesisConsumer` die `Credential Provider`-Konfiguration nicht berücksichtigt. Gültige Konfigurationen werden aufgrund des Problems ignoriert, was dazu führt, dass der `AUTO`-Anmeldeinformationsanbieter verwendet wird. Dies kann zu Problemen beim kontoübergreifenden Zugriff auf Kinesis mithilfe des EFO-Konnektors führen.
Um diesen Fehler zu beheben, verwenden Sie bitte die EFO-Konnektor-Version 1.15.3 oder höher.
# Anwendungen mit nicht unterstützten Kinesis-Konnektoren
Managed Service for Apache Flink for Apache Flink Version 1.15 oder höher [lehnt automatisch den Start oder die Aktualisierung von Anwendungen ab, wenn sie nicht unterstützte Kinesis Connector-Versionen (vor Version 1.15.2) verwenden, die in Anwendungen oder](https://docs.aws.amazon.com/managed-flink/latest/java/flink-1-15-2.html) Archiven (ZIP) gebündelt sind. JARs
## Ablehnungsfehler
Sie erhalten folgende Fehlermeldung, wenn Sie Aufrufe zum Erstellen und Aktualisieren von Anwendungen übermitteln:
```
An error occurred (InvalidArgumentException) when calling the CreateApplication operation: An unsupported Kinesis connector version has been detected in the application. Please update flink-connector-kinesis to any version equal to or newer than 1.15.2.
For more information refer to connector fix: https://issues.apache.org/jira/browse/FLINK-23528
```
## Schritte zur Behebung
+ Aktualisieren Sie die Abhängigkeit der Anwendung von `flink-connector-kinesis`. Wenn Sie Maven als Build-Tool für Ihr Projekt verwenden, folgen Sie [Aktualisieren einer Maven-Abhängigkeit](#troubleshooting-unsupported-kinesis-connectors-update-maven-dependency). Wenn Sie Gradle verwenden, folgen Sie [Aktualisieren einer Gradle-Abhängigkeit](#troubleshooting-unsupported-kinesis-connectors-update-gradle-dependency).
+ Verpacken Sie die Anwendung erneut.
+ Laden Sie sie in einen Amazon-S3-Bucket hoch.
+ Reichen Sie die Anfrage zum Erstellen/Aktualisieren der Anwendung erneut mit der überarbeiteten Anwendung ein, die gerade in den Amazon-S3-Bucket hochgeladen wurde.
+ Wenn Sie weiterhin dieselbe Fehlermeldung erhalten, überprüfen Sie Ihre Anwendungsabhängigkeiten erneut. Wenn das Problem weiterhin besteht, erstellen Sie bitte ein Support-Ticket.
### Aktualisieren einer Maven-Abhängigkeit
1. Öffnen Sie die `pom.xml` des Projekts.
1. Finden Sie die Abhängigkeiten des Projekts. Sie sehen etwa so aus:
```
...
...
org.apache.flink
flink-connector-kinesis
...
...
```
1. Aktualisieren Sie `flink-connector-kinesis` auf Version 1.15.2 oder neuer. Zum Beispiel:
```
...
...
org.apache.flink
flink-connector-kinesis
1.15.2
...
...
```
### Aktualisieren einer Gradle-Abhängigkeit
1. Öffnen Sie die `build.gradle` des Projekts (oder `build.gradle.kts` für Kotlin-Anwendungen).
1. Finden Sie die Abhängigkeiten des Projekts. Sie sehen etwa so aus:
```
...
dependencies {
...
implementation("org.apache.flink:flink-connector-kinesis")
...
}
...
```
1. Aktualisieren Sie `flink-connector-kinesis` auf Version 1.15.2 oder neuer. Zum Beispiel:
```
...
dependencies {
...
implementation("org.apache.flink:flink-connector-kinesis:1.15.2")
...
}
...
```
# Kompilierungsfehler: „Abhängigkeiten für das Projekt konnten nicht aufgelöst werden“
Um die Beispielanwendungen von Managed Service für Apache Flink zu kompilieren, müssen Sie zuerst den Apache-Flink-Kinesis-Konnektor herunterladen, kompilieren und zu Ihrem lokalen Maven-Repository hinzufügen. Wenn der Konnektor nicht zu Ihrem Repository hinzugefügt wurde, wird ein Kompilierungsfehler ähnlich dem folgenden angezeigt:
```
Could not resolve dependencies for project your project name: Failure to find org.apache.flink:flink-connector-kinesis_2.11:jar:1.8.2 in https://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced
```
Um diesen Fehler zu beheben, müssen Sie den Apache Flink-Quellcode (Version 1.8.2 von [https://flink.apache.org/downloads.html](https://flink.apache.org/downloads.html)) für den Connector herunterladen. Anweisungen zum Herunterladen, Kompilieren und Installieren des Apache-Flink-Quellcodes finden Sie unter [Verwenden des Apache Flink Kinesis Streams Connectors mit früheren Apache Flink-Versionen](earlier.md#how-creating-apps-building-kinesis).
# Ungültige Auswahl: „kinesisanalyticsv2"
Um Version 2 der Managed Service für Apache Flink API zu verwenden, benötigen Sie die neueste Version von AWS Command Line Interface (AWS CLI).
*Informationen zur Aktualisierung von finden Sie unter [Installation von](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) im AWS CLI Benutzerhandbuch. AWS Command Line InterfaceAWS Command Line Interface *
# UpdateApplication Aktion ist kein erneutes Laden des Anwendungscodes
Die [UpdateApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_UpdateApplication.html)Aktion lädt den Anwendungscode mit demselben Dateinamen nicht neu, wenn keine S3-Objektversion angegeben ist. Um den Anwendungscode mit demselben Dateinamen neu zu laden, aktivieren Sie die Versionsverwaltung in Ihrem S3-Bucket und geben Sie die neue Objektversion mithilfe des Parameters `ObjectVersionUpdate` an. Weitere Informationen zur Aktivierung der Objektversionsverwaltung in einem S3-Bucket finden Sie unter [Aktivieren oder Deaktivieren der Versionsverwaltung](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/enable-versioning.html).
# S3 StreamingFileSink FileNotFoundExceptions
Anwendungen, die Managed Service für Apache Flink nutzen, können beim Starten von Snapshots auf den Fehler `FileNotFoundException` einer Teildatei in Bearbeitung stoßen, wenn eine in Bearbeitung befindliche Teildatei fehlt, auf die ihr Savepoint verweist. Wenn dieser Fehlermodus eintritt, ist der Operatorstatus der Anwendung, die Managed Service für Apache Flink nutzt, normalerweise nicht wiederherstellbar und muss ohne Verwendung eines Snapshots mittels `SKIP_RESTORE_FROM_SNAPSHOT` neu gestartet werden. Sehen Sie sich den folgenden beispielhaften Stacktrace an:
```
java.io.FileNotFoundException: No such file or directory: s3://amzn-s3-demo-bucket/pathj/INSERT/2023/4/19/7/_part-2-1234_tmp_12345678-1234-1234-1234-123456789012
at org.apache.hadoop.fs.s3a.S3AFileSystem.s3GetFileStatus(S3AFileSystem.java:2231)
at org.apache.hadoop.fs.s3a.S3AFileSystem.innerGetFileStatus(S3AFileSystem.java:2149)
at org.apache.hadoop.fs.s3a.S3AFileSystem.getFileStatus(S3AFileSystem.java:2088)
at org.apache.hadoop.fs.s3a.S3AFileSystem.open(S3AFileSystem.java:699)
at org.apache.hadoop.fs.FileSystem.open(FileSystem.java:950)
at org.apache.flink.fs.s3hadoop.HadoopS3AccessHelper.getObject(HadoopS3AccessHelper.java:98)
at org.apache.flink.fs.s3.common.writer.S3RecoverableMultipartUploadFactory.recoverInProgressPart(S3RecoverableMultipartUploadFactory.java:97)
...
```
Flink `StreamingFileSink` schreibt Datensätze in Dateisysteme, die von den [Dateisystemen](https://nightlies.apache.org/flink/flink-docs-release-1.15/docs/deployment/filesystems/overview/) unterstützt werden. Da die eingehenden Streams unbegrenzt sein können, werden die Daten in Teildateien endlicher Größe organisiert, wobei beim Schreiben der Daten neue Dateien hinzugefügt werden. Der Teil-Lebenszyklus und die Rollover-Richtlinie bestimmen den Zeitpunkt, die Größe und die Benennung der Teildateien.
Beim Checkpointing und Savepointing (Snapshotting) werden alle ausstehenden Dateien umbenannt und festgeschrieben. Teildateien, die sich in Bearbeitung befinden, werden jedoch nicht festgeschrieben, sondern umbenannt, und ihr Verweis wird in den Checkpoint- oder Savepoint-Metadaten gespeichert, die bei der Wiederherstellung von Aufträgen verwendet werden. Diese Teildateien, die sich in Bearbeitung befinden, werden irgendwann in den Status Ausstehend verschoben, umbenannt und von einem nachfolgenden Checkpoint oder Savepoint festgeschrieben.
Im Folgenden sind die Hauptursachen und Abhilfemaßnahmen für fehlende Teildateien in Bearbeitung aufgeführt:
+ Veralteter Snapshot, der zum Starten der Managed Service for Apache Flink-Anwendung verwendet wurde — nur der letzte System-Snapshot, der beim Beenden oder Aktualisieren einer Anwendung erstellt wurde, kann verwendet werden, um eine Managed Service for Apache Flink-Anwendung mit Amazon S3 zu starten. StreamingFileSink Um diese Art von Fehlern zu vermeiden, verwenden Sie den neuesten System-Snapshot.
+ Dies ist beispielsweise der Fall, wenn Sie während des Stopps oder der Aktualisierung einen Snapshot auswählen, der mit `CreateSnapshot` statt mit einem vom System ausgelösten Snapshot erstellt wurde. Der Savepoint des älteren Snapshots enthält einen out-of-date Verweis auf die in Bearbeitung befindliche Teildatei, die umbenannt und von einem nachfolgenden Checkpoint oder Savepoint übernommen wurde.
+ Dies kann auch passieren, wenn ein vom System ausgelöster Snapshot ausgewählt wird, der aufgrund eines nicht letzten Ereignisses ausgelöst wurde. Stop/Update Ein Beispiel ist eine Anwendung, bei der der System-Snapshot deaktiviert, aber `RESTORE_FROM_LATEST_SNAPSHOT` konfiguriert wurde. Im Allgemeinen StreamingFileSink sollte bei Managed Service für Apache Flink-Anwendungen mit Amazon S3 immer der System-Snapshot aktiviert und `RESTORE_FROM_LATEST_SNAPSHOT` konfiguriert sein.
+ Teildatei in Bearbeitung entfernt – Da sich die in Bearbeitung befindliche Teildatei in einem S3-Bucket befindet, kann sie von anderen Komponenten oder Akteuren, die Zugriff auf den Bucket haben, entfernt werden.
+ Dies kann passieren, wenn Sie Ihre App zu lange angehalten haben und die Datei „In Bearbeitung“, auf die sich der Savepoint Ihrer App bezieht, durch die [S3-Bucket-Lebenszyklusrichtlinie](https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpu-abort-incomplete-mpu-lifecycle-config.html) entfernt wurde. MultiPartUpload Um diese Art von Fehlern zu vermeiden, stellen Sie sicher, dass Ihre S3-Bucket-MPU-Lebenszyklusrichtlinie einen ausreichend langen Zeitraum für Ihren Anwendungsfall abdeckt.
+ Dies kann auch passieren, wenn die Teildatei in Bearbeitung manuell oder durch eine andere Komponente Ihres Systems entfernt wurde. Um diese Art von Fehlern zu vermeiden, stellen Sie bitte sicher, dass die in Bearbeitung befindlichen Teildateien nicht von anderen Akteuren oder Komponenten entfernt werden.
+ Wettlaufsituation, bei der nach dem Savepoint ein automatisierter Checkpoint ausgelöst wird – dies betrifft Versionen von Managed Service für Apache Flink bis einschließlich 1.13. Dieses Problem wurde in Managed Service für Apache Flink Version 1.15 behoben. Migrieren Sie Ihre Anwendung auf die neueste Version von Managed Service für Apache Flink, um ein erneutes Auftreten zu verhindern. Wir empfehlen auch die Migration von nach. StreamingFileSink [FileSink](https://nightlies.apache.org/flink/flink-docs-release-1.19/docs/connectors/datastream/filesystem/#file-sink)
+ Wenn Anwendungen angehalten oder aktualisiert werden, löst Managed Service für Apache Flink einen Savepoint aus und hält die Anwendung in zwei Schritten an. Wenn zwischen den beiden Schritten ein automatisierter Checkpoint ausgelöst wird, ist der Savepoint unbrauchbar, da seine in Bearbeitung befindliche Teildatei umbenannt und möglicherweise festgeschrieben würde.
# FlinkKafkaConsumer Problem mit Stop with Savepoint
Wenn Sie die FlinkKafkaConsumer Legacy-Version verwenden, besteht die Möglichkeit, dass Ihre Anwendung beim Aktualisieren, Stoppen oder Skalieren hängen bleibt, wenn Sie System-Snapshots aktiviert haben. Für dieses [Problem](https://issues.apache.org/jira/browse/FLINK-28758) ist kein veröffentlichter Fix verfügbar. Wir empfehlen Ihnen daher, auf das neue Update zu aktualisieren, [KafkaSource](https://nightlies.apache.org/flink/flink-docs-master/docs/connectors/datastream/kafka/#kafka-source)um dieses Problem zu beheben.
Wenn Sie den `FlinkKafkaConsumer` mit aktivierten Snapshots verwenden, besteht die Möglichkeit, dass, wenn der Flink-Auftrag eine API-Anfrage vom Typ Anhalten mit Savepoint verarbeitet, der `FlinkKafkaConsumer` mit einem Laufzeitfehler fehlschlägt und eine `ClosedException` meldet. Unter diesen Bedingungen bleibt die Flink-Anwendung hängen, was sich als Fehlgeschlagene Checkpoints äußert.
# Flink 1.15 Async Sink Deadlock
Es gibt ein [bekanntes Problem](https://issues.apache.org/jira/browse/FLINK-32230) mit AWS Konnektoren für die Apache AsyncSink Flink-Implementierungsschnittstelle. Dies betrifft Anwendungen, die Flink 1.15 mit den folgenden Konnektoren verwenden:
+ Für Java-Anwendungen:
+ KinesisStreamsSink – `org.apache.flink:flink-connector-kinesis`
+ KinesisStreamsSink – `org.apache.flink:flink-connector-aws-kinesis-streams`
+ KinesisFirehoseSink – `org.apache.flink:flink-connector-aws-kinesis-firehose`
+ DynamoDbSink – `org.apache.flink:flink-connector-dynamodb`
+ Flink-AnwendungenSQL/TableAPI/Python:
+ kinesis – `org.apache.flink:flink-sql-connector-kinesis`
+ kinesis – `org.apache.flink:flink-sql-connector-aws-kinesis-streams`
+ firehose – `org.apache.flink:flink-sql-connector-aws-kinesis-firehose`
+ dynamodb – `org.apache.flink:flink-sql-connector-dynamodb`
Bei betroffenen Anwendungen treten die folgenden Symptome auf:
+ Der Flink-Auftrag befindet sich im `RUNNING`-Status, verarbeitet aber keine Daten;
+ Es gibt keine Auftragsneustarts;
+ Bei Checkpoints kommt es zu Zeitüberschreitungen.
Das Problem wird durch einen [Fehler](https://github.com/aws/aws-sdk-java-v2/issues/4354) im AWS SDK verursacht, der dazu führt, dass dem Aufrufer bestimmte Fehler nicht angezeigt werden, wenn der asynchrone HTTP-Client verwendet wird. Dies führt dazu, dass die Senke während eines Checkpoint-Flush-Vorgangs auf unbestimmte Zeit darauf wartet, dass eine in Übertragung befindliche Anfrage abgeschlossen wird.
**Dieses Problem wurde im AWS SDK ab Version 2.20.144 behoben.**
Im Folgenden finden Sie Anweisungen zum Aktualisieren der betroffenen Konnektoren, um die neue Version des AWS SDK in Ihren Anwendungen zu verwenden:
**Topics**
+ [Aktualisieren der Java-Anwendungen](troubleshooting-async-deadlock-update-java-apps.md)
+ [Aktualisieren von Python-Anwendungen](troubleshooting-async-deadlock-update-python-apps.md)
# Aktualisieren der Java-Anwendungen
Gehen Sie wie folgt vor, um Java-Anwendungen zu aktualisieren:
## flink-connector-kinesis
Wenn die Anwendung `flink-connector-kinesis` verwendet:
Der Kinesis-Konnektor verwendet Shading, um einige Abhängigkeiten, einschließlich des AWS SDK, in das Connector-JAR zu packen. Gehen Sie wie folgt vor, um die AWS SDK-Version zu aktualisieren, um diese schattierten Klassen zu ersetzen:
------
#### [ Maven ]
1. Fügen Sie den Kinesis-Connector und die erforderlichen AWS SDK-Module als Projektabhängigkeiten hinzu.
1. Konfigurieren von `maven-shade-plugin`:
1. Fügen Sie einen Filter hinzu, um schattierte AWS SDK-Klassen auszuschließen, wenn der Inhalt der Kinesis-Connector-Jar kopiert wird.
1. Fügen Sie eine Relokationsregel hinzu, um aktualisierte AWS SDK-Klassen in das Paket zu verschieben, was vom Kinesis-Connector erwartet wird.
**pom.xml**
```
...
...
org.apache.flink
flink-connector-kinesis
1.15.4
software.amazon.awssdk
kinesis
2.20.144
software.amazon.awssdk
netty-nio-client
2.20.144
software.amazon.awssdk
sts
2.20.144
...
...
...
...
org.apache.maven.plugins
maven-shade-plugin
3.1.1
package
shade
...
...
org.apache.flink:flink-connector-kinesis
org/apache/flink/kinesis/shaded/software/amazon/awssdk/**
org/apache/flink/kinesis/shaded/org/reactivestreams/**
org/apache/flink/kinesis/shaded/io/netty/**
org/apache/flink/kinesis/shaded/com/typesafe/netty/**
...
...
software.amazon.awssdk
org.apache.flink.kinesis.shaded.software.amazon.awssdk
org.reactivestreams
org.apache.flink.kinesis.shaded.org.reactivestreams
io.netty
org.apache.flink.kinesis.shaded.io.netty
com.typesafe.netty
org.apache.flink.kinesis.shaded.com.typesafe.netty
...
...
...
...
```
------
#### [ Gradle ]
1. Fügen Sie den Kinesis-Connector und die erforderlichen AWS SDK-Module als Projektabhängigkeiten hinzu.
1. Anpassen der ShadowJar-Konfiguration:
1. Schließt schattierte AWS SDK-Klassen aus, wenn der Inhalt der Kinesis-Connector-Jar kopiert wird.
1. Verschieben Sie aktualisierte AWS SDK-Klassen in ein Paket, das vom Kinesis-Connector erwartet wird.
**build.gradle**
```
...
dependencies {
...
flinkShadowJar("org.apache.flink:flink-connector-kinesis:1.15.4")
flinkShadowJar("software.amazon.awssdk:kinesis:2.20.144")
flinkShadowJar("software.amazon.awssdk:sts:2.20.144")
flinkShadowJar("software.amazon.awssdk:netty-nio-client:2.20.144")
...
}
...
shadowJar {
configurations = [project.configurations.flinkShadowJar]
exclude("software/amazon/kinesis/shaded/software/amazon/awssdk/**/*")
exclude("org/apache/flink/kinesis/shaded/org/reactivestreams/**/*.class")
exclude("org/apache/flink/kinesis/shaded/io/netty/**/*.class")
exclude("org/apache/flink/kinesis/shaded/com/typesafe/netty/**/*.class")
relocate("software.amazon.awssdk", "org.apache.flink.kinesis.shaded.software.amazon.awssdk")
relocate("org.reactivestreams", "org.apache.flink.kinesis.shaded.org.reactivestreams")
relocate("io.netty", "org.apache.flink.kinesis.shaded.io.netty")
relocate("com.typesafe.netty", "org.apache.flink.kinesis.shaded.com.typesafe.netty")
}
...
```
------
## Andere betroffene Konnektoren
Wenn die Anwendung einen anderen betroffenen Konnektor verwendet:
Um die AWS SDK-Version zu aktualisieren, sollte die SDK-Version in der Build-Konfiguration des Projekts durchgesetzt werden.
------
#### [ Maven ]
Fügen Sie die AWS SDK-Stückliste (BOM) zum Abschnitt zur Abhängigkeitsverwaltung der `pom.xml` Datei hinzu, um die SDK-Version für das Projekt durchzusetzen.
**pom.xml**
```
...
...
software.amazon.awssdk
bom
2.20.144
import
pom
...
...
```
------
#### [ Gradle ]
Fügen Sie die Plattformabhängigkeit zur AWS SDK-Stückliste (BOM) hinzu, um die SDK-Version für das Projekt durchzusetzen. Dies erfordert Gradle 5.0 oder neuer:
**build.gradle**
```
...
dependencies {
...
flinkShadowJar(platform("software.amazon.awssdk:bom:2.20.144"))
...
}
...
```
------
# Aktualisieren von Python-Anwendungen
Python-Anwendungen können Konnektoren auf zwei verschiedene Arten verwenden: Konnektoren und andere Java-Abhängigkeiten als Teil eines einzelnen uber-Jars verpacken oder Konnektor-JAR direkt verwenden. Beheben von Anwendungsproblemen, die durch Async Sink-Deadlock verursacht werden:
+ Wenn die Anwendung ein uber-Jar verwendet, folgen Sie den Anweisungen für [Aktualisieren der Java-Anwendungen](troubleshooting-async-deadlock-update-java-apps.md).
+ Gehen Sie wie folgt vor, um Konnektor-Jars aus dem Quellcode neu zu erstellen:
**Erstellen von Konnektoren aus dem Quellcode:**
Voraussetzungen, ähnlich den [Build-Anforderungen](https://nightlies.apache.org/flink/flink-docs-release-1.15/docs/flinkdev/building/#build-flink) von Flink:
+ Java 11
+ Maven 3.2.5
## flink-sql-connector-kinesis
1. Herunterladen des Quellcodes für Flink 1.15.4:
```
wget https://archive.apache.org/dist/flink/flink-1.15.4/flink-1.15.4-src.tgz
```
1. Entpacken des Quellcodes:
```
tar -xvf flink-1.15.4-src.tgz
```
1. Navigieren Sie zum Kinesis-Konnektor-Verzeichnis
```
cd flink-1.15.4/flink-connectors/flink-connector-kinesis/
```
1. Kompilieren und installieren Sie Connector-Jar unter Angabe der erforderlichen AWS SDK-Version. Um den Build zu beschleunigen, verwenden Sie `-DskipTests`, um die Testausführung zu überspringen, und `-Dfast`, um zusätzliche Quellcodeprüfungen zu überspringen:
```
mvn clean install -DskipTests -Dfast -Daws.sdkv2.version=2.20.144
```
1. Navigieren Sie zum Kinesis-Konnektor-Verzeichnis
```
cd ../flink-sql-connector-kinesis
```
1. Kompilieren und installieren Sie SQL-Konnektor-JAR:
```
mvn clean install -DskipTests -Dfast
```
1. Das resultierende JAR wird verfügbar sein unter:
```
target/flink-sql-connector-kinesis-1.15.4.jar
```
## flink-sql-connector-aws-Kinesis-Streams
1. Herunterladen des Quellcodes für Flink 1.15.4:
```
wget https://archive.apache.org/dist/flink/flink-1.15.4/flink-1.15.4-src.tgz
```
1. Entpacken des Quellcodes:
```
tar -xvf flink-1.15.4-src.tgz
```
1. Navigieren Sie zum Kinesis-Konnektor-Verzeichnis
```
cd flink-1.15.4/flink-connectors/flink-connector-aws-kinesis-streams/
```
1. Kompilieren und installieren Sie Connector-JAR unter Angabe der erforderlichen SDK-Version. AWS Um den Build zu beschleunigen, verwenden Sie `-DskipTests`, um die Testausführung zu überspringen, und `-Dfast`, um zusätzliche Quellcodeprüfungen zu überspringen:
```
mvn clean install -DskipTests -Dfast -Daws.sdk.version=2.20.144
```
1. Navigieren Sie zum Kinesis-Konnektor-Verzeichnis
```
cd ../flink-sql-connector-aws-kinesis-streams
```
1. Kompilieren und installieren Sie SQL-Konnektor-JAR:
```
mvn clean install -DskipTests -Dfast
```
1. Das resultierende JAR wird verfügbar sein unter:
```
target/flink-sql-connector-aws-kinesis-streams-1.15.4.jar
```
## flink-sql-connector-aws-Kinesis-Firehose
1. Herunterladen des Quellcodes für Flink 1.15.4:
```
wget https://archive.apache.org/dist/flink/flink-1.15.4/flink-1.15.4-src.tgz
```
1. Entpacken des Quellcodes:
```
tar -xvf flink-1.15.4-src.tgz
```
1. Navigieren Sie zum Konnektor-Verzeichnis
```
cd flink-1.15.4/flink-connectors/flink-connector-aws-kinesis-firehose/
```
1. Kompilieren und installieren Sie das Connector-JAR unter Angabe der erforderlichen SDK-Version. AWS Um den Build zu beschleunigen, verwenden Sie `-DskipTests`, um die Testausführung zu überspringen, und `-Dfast`, um zusätzliche Quellcodeprüfungen zu überspringen:
```
mvn clean install -DskipTests -Dfast -Daws.sdk.version=2.20.144
```
1. Navigieren Sie zum SQL-Konnektor-Verzeichnis
```
cd ../flink-sql-connector-aws-kinesis-firehose
```
1. Kompilieren und installieren Sie SQL-Konnektor-JAR:
```
mvn clean install -DskipTests -Dfast
```
1. Das resultierende JAR wird verfügbar sein unter:
```
target/flink-sql-connector-aws-kinesis-firehose-1.15.4.jar
```
## flink-sql-connector-dynamodb
1. Herunterladen des Quellcodes für Flink 1.15.4:
```
wget https://archive.apache.org/dist/flink/flink-connector-aws-3.0.0/flink-connector-aws-3.0.0-src.tgz
```
1. Entpacken des Quellcodes:
```
tar -xvf flink-connector-aws-3.0.0-src.tgz
```
1. Navigieren Sie zum Konnektor-Verzeichnis
```
cd flink-connector-aws-3.0.0
```
1. Kompilieren und installieren Sie das Connector-JAR unter Angabe der erforderlichen AWS SDK-Version. Um den Build zu beschleunigen, verwenden Sie `-DskipTests`, um die Testausführung zu überspringen, und `-Dfast`, um zusätzliche Quellcodeprüfungen zu überspringen:
```
mvn clean install -DskipTests -Dfast -Dflink.version=1.15.4 -Daws.sdk.version=2.20.144
```
1. Das resultierende JAR wird verfügbar sein unter:
```
flink-sql-connector-dynamodb/target/flink-sql-connector-dynamodb-3.0.0.jar
```
# Die Quellverarbeitung von Amazon Kinesis Kinesis-Datenstreams ist beim Re-Sharding nicht in der richtigen Reihenfolge
Die aktuelle FlinkKinesisConsumer Implementierung bietet keine starken Ordnungsgarantien zwischen Kinesis-Shards. Dies kann zu einer out-of-order Verarbeitung beim Re-Sharding von Kinesis Stream führen, insbesondere bei Flink-Anwendungen, bei denen es zu Verarbeitungsverzögerungen kommt. Unter bestimmten Umständen, z. B. bei Windows-Operatoren, die auf Ereigniszeiten basieren, können Ereignisse aufgrund der daraus resultierenden Verspätung verworfen werden.
![\[Diagram showing shards and shard consumers with time progression and trim horizon.\]](http://docs.aws.amazon.com/de_de/managed-flink/latest/java/images/flink-ts.png)
Dies ist ein [bekanntes Problem](https://issues.apache.org/jira/browse/FLINK-6349) in Open Source Flink. Stellen Sie sicher, dass Ihre Flink-Anwendungen bei der Neupartitionierung nicht hinter Kinesis Data Streams zurückfallen, bis die Fehlerbehebung für den Konnektor verfügbar ist. Indem Sie sicherstellen, dass die Verarbeitungsverzögerung von Ihren Flink-Apps toleriert wird, können Sie die Auswirkungen der out-of-order Verarbeitung und das Risiko eines Datenverlusts minimieren.
# Häufig gestellte Fragen und Problemlösungen zum Einbetten von Vektoren in Echtzeit
Lesen Sie die folgenden Abschnitte mit häufig gestellten Fragen und zur Fehlerbehebung, um Probleme mit Blueprints zur Vektoreinbettung in Echtzeit zu beheben. Weitere Informationen zu Blueprints zum Einbetten von Vektoren in Echtzeit finden Sie unter Blueprints zum Einbetten von Vektoren [in Echtzeit](https://docs.aws.amazon.com/msk/latest/developerguide/ai-vector-embedding-integration-learn-more.html).
[Informationen zur allgemeinen Problembehandlung bei Managed Service für Apache Flink-Anwendungen finden Sie unter -runtime.html. https://docs.aws.amazon.com/managed-flink/ latest/java/troubleshooting](https://docs.aws.amazon.com/managed-flink/latest/java/troubleshooting-runtime.html)
**Topics**
+ [Blueprints zum Einbetten von Vektoren in Echtzeit — Häufig gestellte Fragen](troubleshooting-blueprints-FAQ.md)
+ [Blueprints zum Einbetten von Vektoren in Echtzeit — Problembehebung](troubleshooting-blueprints-TS.md)
# Blueprints zum Einbetten von Vektoren in Echtzeit — Häufig gestellte Fragen
Lesen Sie die folgenden häufig gestellten Fragen zu Blueprints zum Einbetten von Vektoren in Echtzeit. Weitere Informationen über Blueprints zum Einbetten von Vektoren in Echtzeit finden Sie unter Blueprints zum Einbetten von Vektoren [in Echtzeit](https://docs.aws.amazon.com/msk/latest/developerguide/ai-vector-embedding-integration-learn-more.html).
**Topics**
+ [Welche AWS Ressourcen schafft dieser Blueprint?](#troubleshooting-blueprints-1)
+ [Was sind meine Aktionen, nachdem die AWS CloudFormation Stack-Bereitstellung abgeschlossen ist?](#troubleshooting-blueprints-2)
+ [Wie sollten die Daten in den Amazon MSK-Quellthemen strukturiert sein?](#troubleshooting-blueprints-3)
+ [Kann ich Teile einer Nachricht angeben, die eingebettet werden sollen?](#troubleshooting-blueprints-4)
+ [Kann ich Daten aus mehreren Amazon MSK-Themen lesen?](#troubleshooting-blueprints-5)
+ [Kann ich Regex verwenden, um Amazon MSK-Themennamen zu konfigurieren?](#troubleshooting-blueprints-6)
+ [Was ist die maximale Größe einer Nachricht, die aus einem Amazon MSK-Thema gelesen werden kann?](#troubleshooting-blueprints-7)
+ [Welcher Typ wird unterstützt? OpenSearch](#troubleshooting-blueprints-8)
+ [Warum muss ich eine Vektorsuchsammlung und einen Vektorindex verwenden und meiner OpenSearch serverlosen Sammlung ein Vektorfeld hinzufügen?](#troubleshooting-blueprints-9)
+ [Was sollte ich als Dimension für mein Vektorfeld festlegen?](#troubleshooting-blueprints-10)
+ [Wie sieht die Ausgabe im konfigurierten OpenSearch Index aus?](#troubleshooting-blueprints-11)
+ [Kann ich Metadatenfelder angeben, die dem im OpenSearch Index gespeicherten Dokument hinzugefügt werden sollen?](#troubleshooting-blueprints-12)
+ [Muss ich mit doppelten Einträgen im OpenSearch Index rechnen?](#troubleshooting-blueprints-13)
+ [Kann ich Daten an mehrere Indizes senden? OpenSearch](#troubleshooting-blueprints-14)
+ [Kann ich mehrere Echtzeit-Vektor-Einbettungsanwendungen in einer einzigen bereitstellen? AWS-Konto](#troubleshooting-blueprints-15)
+ [Können mehrere Anwendungen zur Vektoreinbettung in Echtzeit dieselbe Datenquelle oder Datensenke verwenden?](#troubleshooting-blueprints-16)
+ [Unterstützt die Anwendung kontenübergreifende Konnektivität?](#troubleshooting-blueprints-17)
+ [Unterstützt die Anwendung regionsübergreifende Konnektivität?](#troubleshooting-blueprints-18)
+ [Können sich mein Amazon MSK-Cluster und meine OpenSearch Sammlung in verschiedenen VPCs Subnetzen befinden?](#troubleshooting-blueprints-19)
+ [Welche Einbettungsmodelle werden von der Anwendung unterstützt?](#troubleshooting-blueprints-20)
+ [Kann ich die Leistung meiner Anwendung auf der Grundlage meiner Arbeitslast optimieren?](#troubleshooting-blueprints-21)
+ [Welche Amazon MSK-Authentifizierungstypen werden unterstützt?](#troubleshooting-blueprints-22)
+ [Was ist `sink.os.bulkFlushIntervalMillis` und wie stelle ich es ein?](#troubleshooting-blueprints-23)
+ [Wenn ich meine Managed Service for Apache Flink-Anwendung bereitstelle, ab welchem Punkt im Amazon MSK-Thema beginnt sie, Nachrichten zu lesen?](#troubleshooting-blueprints-24)
+ [Wie verwende ich`source.msk.starting.offset`?](#troubleshooting-blueprints-25)
+ [Welche Chunking-Strategien werden unterstützt?](#troubleshooting-blueprints-26)
+ [Wie lese ich Datensätze in meinem Vektordatenspeicher?](#troubleshooting-blueprints-27)
+ [Wo finde ich neue Updates für den Quellcode?](#troubleshooting-blueprints-28)
+ [Kann ich die AWS CloudFormation Vorlage ändern und die Anwendung Managed Service for Apache Flink aktualisieren?](#troubleshooting-blueprints-29)
+ [Wird die Anwendung in meinem Namen AWS überwacht und gewartet?](#troubleshooting-blueprints-30)
+ [Verschiebt diese Anwendung meine Daten außerhalb meiner AWS-Konto?](#troubleshooting-blueprints-31)
## Welche AWS Ressourcen schafft dieser Blueprint?
Um die in Ihrem Konto bereitgestellten Ressourcen zu finden, navigieren Sie zur AWS CloudFormation Konsole und identifizieren Sie den Stack-Namen, der mit dem Namen beginnt, den Sie für Ihre Managed Service for Apache Flink-Anwendung angegeben haben. Wählen Sie die Registerkarte **Ressourcen**, um die Ressourcen zu überprüfen, die als Teil des Stacks erstellt wurden. Im Folgenden sind die wichtigsten Ressourcen aufgeführt, die der Stack erstellt:
+ Managed Service zur Vektoreinbettung in Echtzeit für die Apache Flink-Anwendung
+ Amazon S3 S3-Bucket zum Speichern des Quellcodes für die Echtzeit-Vektor-Einbettungsanwendung
+ CloudWatch Protokollgruppe und Protokollstream zum Speichern von Protokollen
+ Lambda-Funktionen zum Abrufen und Erstellen von Ressourcen
+ IAM-Rollen und -Richtlinien für Lambdas, Managed Service für die Apache Flink-Anwendung und den Zugriff auf Amazon Bedrock und Amazon Service OpenSearch
+ Datenzugriffsrichtlinie für Amazon OpenSearch Service
+ VPC-Endpunkte für den Zugriff auf Amazon Bedrock und Amazon Service OpenSearch
## Was sind meine Aktionen, nachdem die AWS CloudFormation Stack-Bereitstellung abgeschlossen ist?
Rufen Sie nach Abschluss der AWS CloudFormation Stack-Bereitstellung die Managed Service for Apache Flink-Konsole auf und suchen Sie nach Ihrer Blueprint-Anwendung Managed Service for Apache Flink. Wählen Sie die Registerkarte „**Konfigurieren**“ und vergewissern Sie sich, dass alle Runtime-Eigenschaften korrekt eingerichtet sind. Sie werden möglicherweise zur nächsten Seite weitergeleitet. Wenn Sie mit den Einstellungen vertraut sind, wählen Sie **Ausführen**. Die Anwendung beginnt, Nachrichten aus Ihrem Thema aufzunehmen.
Informationen zur Suche nach neuen Versionen finden Sie unter [https://github.com/awslabs/real-time-vectorization-of-streaming-data/releases](https://github.com/awslabs/real-time-vectorization-of-streaming-data/releases).
## Wie sollten die Daten in den Amazon MSK-Quellthemen strukturiert sein?
Wir unterstützen derzeit strukturierte und unstrukturierte Quelldaten.
+ Unstrukturierte Daten werden mit in gekennzeichnet. `STRING` `source.msk.data.type` Die Daten werden so gelesen, wie sie aus der eingehenden Nachricht stammen.
+ Wir unterstützen derzeit strukturierte JSON-Daten, die mit in gekennzeichnet `JSON` sind. `source.msk.data.type` Die Daten müssen immer im JSON-Format vorliegen. Wenn die Anwendung ein falsch formatiertes JSON empfängt, schlägt die Anwendung fehl.
+ Wenn Sie JSON als Quelldatentyp verwenden, stellen Sie sicher, dass jede Nachricht in allen Quellthemen ein gültiges JSON ist. Wenn Sie mit dieser Einstellung ein oder mehrere Themen abonnieren, die keine JSON-Objekte enthalten, schlägt die Anwendung fehl. Wenn ein oder mehrere Themen eine Mischung aus strukturierten und unstrukturierten Daten enthalten, empfehlen wir, die Quelldaten in der Anwendung Managed Service for Apache Flink als unstrukturiert zu konfigurieren.
## Kann ich Teile einer Nachricht angeben, die eingebettet werden sollen?
+ Wo sind unstrukturierte Eingabedaten`source.msk.data.type`? `STRING` Die Anwendung bettet immer die gesamte Nachricht ein und speichert die gesamte Nachricht im konfigurierten OpenSearch Index.
+ Bei strukturierten Eingabedaten (where `source.msk.data.type` is) können Sie so konfigurieren`JSON`, `embed.input.config.json.fieldsToEmbed` dass angegeben wird, welches Feld im JSON-Objekt für die Einbettung ausgewählt werden soll. Dies funktioniert nur für JSON-Felder der obersten Ebene und nicht für verschachtelte Nachrichten JSONs und für Nachrichten, die ein JSON-Array enthalten. Verwenden Sie .\$1, um das gesamte JSON einzubetten.
## Kann ich Daten aus mehreren Amazon MSK-Themen lesen?
Ja, mit dieser Anwendung können Sie Daten aus mehreren Amazon MSK-Themen lesen. Daten aus allen Themen müssen vom gleichen Typ sein (entweder STRING oder JSON). Andernfalls kann die Anwendung fehlschlagen. Daten aus allen Themen werden immer in einem einzigen OpenSearch Index gespeichert.
## Kann ich Regex verwenden, um Amazon MSK-Themennamen zu konfigurieren?
`source.msk.topic.names`unterstützt keine Liste von Regex. Wir unterstützen entweder eine durch Kommas getrennte Liste von Themennamen oder reguläre Ausdrücke, um alle Themen `.*` einzubeziehen.
## Was ist die maximale Größe einer Nachricht, die aus einem Amazon MSK-Thema gelesen werden kann?
Die maximale Größe einer Nachricht, die verarbeitet werden kann, ist durch das Amazon InvokeModel Bedrock-Textlimit begrenzt, das derzeit auf 25.000.000 festgelegt ist. Weitere Informationen finden Sie unter [InvokeModel](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_InvokeModel.html#API_runtime_InvokeModel_RequestBody).
## Welcher Typ wird unterstützt? OpenSearch
Wir unterstützen sowohl OpenSearch Domains als auch Sammlungen. Wenn Sie eine OpenSearch Sammlung verwenden, stellen Sie sicher, dass Sie eine Vektorsammlung verwenden, und erstellen Sie einen Vektorindex, der für diese Anwendung verwendet werden soll. Auf diese Weise können Sie die Funktionen der OpenSearch Vektordatenbank für die Abfrage Ihrer Daten verwenden. Weitere Informationen finden Sie unter [Erläuterung der Vektordatenbankfunktionen von Amazon OpenSearch Service](https://aws.amazon.com/blogs/big-data/amazon-opensearch-services-vector-database-capabilities-explained/).
## Warum muss ich eine Vektorsuchsammlung und einen Vektorindex verwenden und meiner OpenSearch serverlosen Sammlung ein Vektorfeld hinzufügen?
Der Sammlungstyp der *Vektorsuche* in OpenSearch Serverless bietet eine skalierbare und leistungsstarke Ähnlichkeitssuche. Es vereinfacht die Entwicklung moderner, erweiterter Sucherlebnisse für maschinelles Lernen (ML) und generativer Anwendungen für künstliche Intelligenz (KI). Weitere Informationen finden Sie unter [Arbeiten mit Sammlungen zur Vektorsuche](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-vector-search.html?icmpid=docs_console_unmapped).
## Was sollte ich als Dimension für mein Vektorfeld festlegen?
Stellen Sie die Dimension des Vektorfeldes auf der Grundlage des Einbettungsmodells ein, das Sie verwenden möchten. Sehen Sie sich die folgende Tabelle an und bestätigen Sie diese Werte aus der jeweiligen Dokumentation.
**Abmessungen des Vektorfeldes**
| Modellname zum Einbetten von Amazon Bedrock-Vektoren | Das Modell bietet Unterstützung für Ausgabedimensionen |
| --- | --- |
| Amazon Titan Texteinbettungen V1 | 1 536 |
| Amazon Titan Text Embeddings V2 | 1.024 (Standard), 384, 256 |
| Amazon Titan Multimodal Embeddings G1 | 1.024 (Standard), 384, 256 |
| Cohere Embed English | 1,024 |
| Cohere Embed Multilingual | 1,024 |
## Wie sieht die Ausgabe im konfigurierten OpenSearch Index aus?
Jedes Dokument im OpenSearch Index enthält folgende Felder:
+ **original\$1data: Die Daten**, die zur Generierung von Einbettungen verwendet wurden. Beim Typ STRING ist es die gesamte Nachricht. Bei JSON-Objekten ist es das JSON-Objekt, das für Einbettungen verwendet wurde. Es kann sich um das gesamte JSON in der Nachricht oder um bestimmte Felder im JSON handeln. Wenn der Name beispielsweise so ausgewählt wurde, dass er in eingehende Nachrichten eingebettet werden soll, würde die Ausgabe wie folgt aussehen:
```
"original_data": "{\"name\":\"John Doe\"}"
```
+ **embedded\$1data**: Ein Vektor-Float-Array von Einbettungen, die von Amazon Bedrock generiert wurden
+ **Datum**: UTC-Zeitstempel, in dem das Dokument gespeichert wurde OpenSearch
## Kann ich Metadatenfelder angeben, die dem im OpenSearch Index gespeicherten Dokument hinzugefügt werden sollen?
Nein, derzeit unterstützen wir nicht das Hinzufügen zusätzlicher Felder zum endgültigen, im OpenSearch Index gespeicherten Dokument.
## Muss ich mit doppelten Einträgen im OpenSearch Index rechnen?
Je nachdem, wie Sie Ihre Anwendung konfiguriert haben, werden möglicherweise doppelte Nachrichten im Index angezeigt. Ein häufiger Grund ist der Neustart der Anwendung. Die Anwendung ist standardmäßig so konfiguriert, dass sie ab der ersten Nachricht im Quellthema mit dem Lesen beginnt. Wenn Sie die Konfiguration ändern, wird die Anwendung neu gestartet und verarbeitet alle Nachrichten im Thema erneut. Um eine erneute Verarbeitung zu vermeiden, lesen Sie in der Dokumentation zur Verwendung von source.msk.starting.offset nach und legen Sie den Startversatz für Ihre Anwendung korrekt fest.
## Kann ich Daten an mehrere Indizes senden? OpenSearch
Nein, die Anwendung unterstützt das Speichern von Daten in einem einzigen OpenSearch Index. Um die Vektorisierungsausgabe für mehrere Indizes einzurichten, müssen Sie einen separaten Managed Service für Apache Flink-Anwendungen bereitstellen.
## Kann ich mehrere Echtzeit-Vektor-Einbettungsanwendungen in einer einzigen bereitstellen? AWS-Konto
Ja, Sie können mehrere Managed Service für Apache Flink-Anwendungen zur Echtzeit-Vektoreinbettung in einer einzigen Anwendung bereitstellen, AWS-Konto sofern jede Anwendung einen eindeutigen Namen hat.
## Können mehrere Anwendungen zur Vektoreinbettung in Echtzeit dieselbe Datenquelle oder Datensenke verwenden?
Ja, Sie können mehrere Managed Services für Apache Flink-Anwendungen zur Echtzeit-Vektoreinbettung erstellen, die Daten aus demselben Thema lesen oder Daten im selben Index speichern.
## Unterstützt die Anwendung kontenübergreifende Konnektivität?
Nein, damit die Anwendung erfolgreich ausgeführt werden kann, müssen sich der Amazon MSK-Cluster und die OpenSearch Sammlung dort befinden, AWS-Konto wo Sie versuchen, Ihre Managed Service for Apache Flink-Anwendung einzurichten.
## Unterstützt die Anwendung regionsübergreifende Konnektivität?
Nein, mit der Anwendung können Sie nur eine Managed Service for Apache Flink-Anwendung mit einem Amazon MSK-Cluster und einer OpenSearch Sammlung in derselben Region wie die Managed Service for Apache Flink-Anwendung bereitstellen.
## Können sich mein Amazon MSK-Cluster und meine OpenSearch Sammlung in verschiedenen VPCs Subnetzen befinden?
Ja, wir unterstützen Amazon MSK-Cluster und OpenSearch -Sammlung in verschiedenen VPCs Subnetzen, sofern sie sich in denselben befinden. AWS-Konto Weitere Informationen finden Sie unter (Allgemeine MSF-Fehlerbehebung), um sicherzustellen, dass Ihre Einrichtung korrekt ist.
## Welche Einbettungsmodelle werden von der Anwendung unterstützt?
Derzeit unterstützt die Anwendung alle Modelle, die von Bedrock unterstützt werden. Dazu zählen:
+ Amazon Titan Embeddings G1 – Text
+ Amazon Titan Text Embeddings V2
+ Amazon Titan Multimodal Embeddings G1
+ Cohere Embed English
+ Cohere Embed Multilingual
## Kann ich die Leistung meiner Anwendung auf der Grundlage meiner Arbeitslast optimieren?
Ja. Der Durchsatz der Anwendung hängt von einer Reihe von Faktoren ab, die alle von den Kunden gesteuert werden können:
1. **AWS MSF KPUs**: Die Anwendung wird mit dem Standard-Parallelitätsfaktor 2 und Parallelität pro KPU 1 bereitgestellt, wobei die automatische Skalierung aktiviert ist. Wir empfehlen jedoch, die Skalierung für die Anwendung Managed Service for Apache Flink entsprechend Ihren Workloads zu konfigurieren. Weitere Informationen finden Sie unter [Überprüfen der Anwendungsressourcen für Managed Service für Apache Flink](https://docs.aws.amazon.com/managed-flink/latest/java/how-resources.html).
1. **Amazon Bedrock**: Je nach dem ausgewählten Amazon Bedrock On-Demand-Modell können unterschiedliche Kontingente gelten. Sehen Sie sich die Service-Kontingente in Bedrock an, um zu sehen, welche Arbeitslast der Service bewältigen kann. Weitere Informationen finden Sie unter [Kontingente für Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/quotas.html).
1. **Amazon OpenSearch Service**: Darüber hinaus stellen Sie in einigen Situationen möglicherweise fest, dass dies der Engpass in Ihrer Pipeline OpenSearch ist. Informationen zur Skalierung finden Sie unter OpenSearch Skalierung der [Größe von Amazon OpenSearch Service-Domains](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/sizing-domains.html).
## Welche Amazon MSK-Authentifizierungstypen werden unterstützt?
Wir unterstützen nur den Authentifizierungstyp IAM MSK.
## Was ist `sink.os.bulkFlushIntervalMillis` und wie stelle ich es ein?
Beim Senden von Daten an Amazon OpenSearch Service ist das Bulk-Flush-Intervall das Intervall, in dem die Bulk-Anfrage ausgeführt wird, unabhängig von der Anzahl der Aktionen oder der Größe der Anfrage. Der Standardwert ist auf 1 Millisekunde festgelegt.
Die Festlegung eines Aktualisierungsintervalls kann zwar dazu beitragen, sicherzustellen, dass Daten rechtzeitig indexiert werden, kann aber auch zu einem erhöhten Overhead führen, wenn es zu niedrig eingestellt ist. Berücksichtigen Sie bei der Auswahl eines Aktualisierungsintervalls Ihren Anwendungsfall und die Bedeutung einer zeitnahen Indizierung.
## Wenn ich meine Managed Service for Apache Flink-Anwendung bereitstelle, ab welchem Punkt im Amazon MSK-Thema beginnt sie, Nachrichten zu lesen?
Die Anwendung beginnt mit dem Lesen von Nachrichten aus dem Amazon MSK-Thema an dem Offset, das durch die in der `source.msk.starting.offset` Laufzeitkonfiguration der Anwendung festgelegte Konfiguration festgelegt wurde. Wenn dies nicht explizit festgelegt `source.msk.starting.offset` ist, beginnt die Anwendung standardmäßig mit dem Lesen ab der frühesten verfügbaren Nachricht im Thema.
## Wie verwende ich`source.msk.starting.offset`?
Setzt s je `ource.msk.starting.offset` nach gewünschtem Verhalten explizit auf einen der folgenden Werte:
+ FRÜHEST: Die Standardeinstellung, bei der vom ältesten Offset in der Partition ausgegangen wird. Dies ist vor allem dann eine gute Wahl, wenn:
+ Sie haben neu Amazon MSK-Themen und Verbraucheranwendungen erstellt.
+ Sie müssen Daten erneut abspielen, damit Sie den Status erstellen oder rekonstruieren können. Dies ist relevant, wenn Sie das Muster für die Ereignisbeschaffung implementieren oder wenn Sie einen neuen Service initialisieren, für den eine vollständige Ansicht des Datenverlaufs erforderlich ist.
+ AKTUELL: Die Anwendung Managed Service for Apache Flink liest Nachrichten vom Ende der Partition. Wir empfehlen diese Option, wenn Sie nur daran interessiert sind, dass neue Nachrichten erstellt werden, und wenn Sie keine historischen Daten verarbeiten müssen. In dieser Einstellung ignoriert der Verbraucher die vorhandenen Nachrichten und liest nur neue Nachrichten, die vom ursprünglichen Hersteller veröffentlicht wurden.
+ COMMITTED: Die Anwendung Managed Service for Apache Flink beginnt, Nachrichten aus dem festgeschriebenen Offset der konsumierenden Gruppe zu konsumieren. Wenn der festgeschriebene Offset nicht existiert, wird die EARLEOST-Reset-Strategie verwendet.
## Welche Chunking-Strategien werden unterstützt?
Wir verwenden die [Langchain-Bibliothek](https://js.langchain.com/v0.1/docs/get_started/introduction/), um Eingaben zu teilen. Das Chunking wird nur angewendet, wenn die Länge der Eingabe größer als die gewählte ist. `maxSegmentSizeInChars` Wir unterstützen die folgenden fünf Chunking-Typen:
+ `SPLIT_BY_CHARACTER`: Passt so viele Zeichen wie möglich in jeden Chunk, wobei die Länge jedes Chunks nicht größer als ist. maxSegmentSize InChars Leerzeichen sind ihm egal, daher können Wörter abgeschnitten werden.
+ `SPLIT_BY_WORD`: Findet Whitespace-Zeichen zum Abteilen. Es werden keine Wörter abgeschnitten.
+ `SPLIT_BY_SENTENCE`: Satzgrenzen werden mithilfe der Apache OpenNLP-Bibliothek mit dem englischen Satzmodell erkannt.
+ `SPLIT_BY_LINE`: Findet neue Zeilenzeichen zum Abteilen.
+ `SPLIT_BY_PARAGRAPH`: Findet aufeinanderfolgende neue Zeilenzeichen, nach denen aufgeteilt werden kann.
Bei den Splitting-Strategien wird auf die vorherige Reihenfolge zurückgegriffen, während bei den größeren Chunking-Strategien eher `SPLIT_BY_PARAGRAPH` zurückgegriffen wird. `SPLIT_BY_CHARACTER` Wenn beispielsweise eine Zeile zu lang ist`SPLIT_BY_LINE`, wird die Zeile satzweise unterteilt, wobei jeder Abschnitt in so viele Sätze wie möglich passt. Wenn es Sätze gibt, die zu lang sind, werden sie auf Wortebene aufgeteilt. Wenn ein Wort zu lang ist, wird es nach Zeichen aufgeteilt.
## Wie lese ich Datensätze in meinem Vektordatenspeicher?
1. Wann ist `source.msk.data.type` `STRING`
+ **original\$1data**: Die gesamte Originalzeichenfolge aus der Amazon MSK-Nachricht.
+ **embedded\$1data**: Einbettungsvektor, der erstellt wurde, `chunk_data` wenn er nicht leer ist (Chunking angewendet), oder der erstellt wurde, wenn kein Chunking angewendet wurde. `original_data`
+ **chunk\$1data**: Nur vorhanden, wenn die Originaldaten aufgeteilt wurden. Enthält den Teil der ursprünglichen Nachricht, der zur Erstellung der Einbettung in verwendet wurde. `embedded_data`
1. Wann ist `source.msk.data.type` `JSON`
+ **original\$1data**: Das gesamte ursprüngliche JSON aus der Amazon MSK-Nachricht, *nachdem* die JSON-Schlüsselfilterung angewendet wurde.
+ **embedded\$1data**: Einbettungsvektor, der erstellt wurde, `chunk_data` wenn er nicht leer ist (Chunking angewendet), oder erstellt, wenn kein Chunking angewendet wurde. `original_data`
+ **chunk\$1key**: Nur vorhanden, wenn die Originaldaten aufgeteilt wurden. Enthält den JSON-Schlüssel, aus dem der Chunk stammt. `original_data` Zum Beispiel kann es wie `jsonKey1.nestedJsonKeyA` bei verschachtelten Schlüsseln oder *Metadaten* aussehen. `original_data`
+ **chunk\$1data**: Nur vorhanden, wenn die Originaldaten aufgeteilt wurden. Enthält den Teil der ursprünglichen Nachricht, der zur Erstellung der Einbettung in verwendet wurde. `embedded_data`
Ja, mit dieser Anwendung können Sie Daten aus mehreren Amazon MSK-Themen lesen. Daten aus allen Themen müssen vom gleichen Typ sein (entweder STRING oder JSON). Andernfalls kann die Anwendung fehlschlagen. Daten aus allen Themen werden immer in einem einzigen OpenSearch Index gespeichert.
## Wo finde ich neue Updates für den Quellcode?
Gehe zu [https://github.com/awslabs/real-time-vectorization-of-streaming-data/releases, um nach neuen Versionen zu suchen](https://github.com/awslabs/real-time-vectorization-of-streaming-data/releases).
## Kann ich die AWS CloudFormation Vorlage ändern und die Anwendung Managed Service for Apache Flink aktualisieren?
Nein, durch eine Änderung an der AWS CloudFormation Vorlage wird die Anwendung Managed Service for Apache Flink nicht aktualisiert. Jede neue Änderung AWS CloudFormation bedeutet, dass ein neuer Stack bereitgestellt werden muss.
## Wird die Anwendung in meinem Namen AWS überwacht und gewartet?
Nein, AWS ich werde diese Anwendung nicht in Ihrem Namen überwachen, skalieren, aktualisieren oder patchen.
## Verschiebt diese Anwendung meine Daten außerhalb meiner AWS-Konto?
Alle Daten, die von der Anwendung Managed Service for Apache Flink gelesen und gespeichert werden, verbleiben in Ihrem Konto AWS-Konto und verlassen Ihr Konto niemals.
# Blueprints zum Einbetten von Vektoren in Echtzeit — Problembehebung
Lesen Sie die folgenden Themen zur Problembehebung zu Blueprints für das Einbetten von Vektoren in Echtzeit. Weitere Informationen zu Blueprints zum Einbetten von Vektoren in Echtzeit finden Sie unter Blueprints zum Einbetten von Vektoren [in Echtzeit](https://docs.aws.amazon.com/msk/latest/developerguide/ai-vector-embedding-integration-learn-more.html).
**Topics**
+ [Meine CloudFormation Stack-Bereitstellung ist fehlgeschlagen oder wurde rückgängig gemacht. Was kann ich tun, um das Problem zu beheben?](#troubleshooting-blueprints-deployment)
+ [Ich möchte nicht, dass meine Anwendung ab dem Beginn der Amazon MSK-Themen Nachrichten liest. Was soll ich tun?](#troubleshooting-blueprints-beginning)
+ [Woher weiß ich, ob es ein Problem mit meiner Managed Service for Apache Flink-Anwendung gibt, und wie kann ich es debuggen?](#troubleshooting-blueprints-debug)
+ [Was sind die wichtigsten Kennzahlen, die ich für meine Managed Service for Apache Flink-Anwendung überwachen sollte?](#troubleshooting-blueprints-metrics)
## Meine CloudFormation Stack-Bereitstellung ist fehlgeschlagen oder wurde rückgängig gemacht. Was kann ich tun, um das Problem zu beheben?
+ Gehen Sie zu Ihrem CFN-Stack und finden Sie den Grund für den Stack-Ausfall. Dies könnte unter anderem mit fehlenden Berechtigungen und Kollisionen bei AWS Ressourcennamen zusammenhängen. Korrigieren Sie die Hauptursache des Bereitstellungsfehlers. Weitere Informationen finden Sie in der [Anleitung CloudWatch zur Fehlerbehebung](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#basic-ts-guide).
+ [Optional] Es kann nur einen VPC-Endpunkt pro Service pro VPC geben. Wenn Sie mehrere Echtzeit-Vektoreinbettungs-Blueprints zum Schreiben in die Amazon OpenSearch Service-Sammlungen in derselben VPC bereitgestellt haben, teilen sich diese möglicherweise VPC-Endpunkte. Diese sind entweder bereits in Ihrem Konto für die VPC vorhanden, oder der erste Blueprint-Stack zur Vektoreinbettung in Echtzeit erstellt VPC-Endpunkte für Amazon Bedrock und Amazon OpenSearch Service, die von allen anderen in Ihrem Konto bereitgestellten Stacks verwendet werden. Wenn ein Stack ausfällt, überprüfen Sie, ob dieser Stack VPC-Endpunkte für Amazon Bedrock und Amazon OpenSearch Service erstellt hat, und löschen Sie sie, wenn sie an keiner anderen Stelle in Ihrem Konto verwendet werden. Schritte zum Löschen von VPC-Endpunkten finden Sie in der Dokumentation zum sicheren Löschen Ihrer Anwendung.
+ Möglicherweise gibt es andere Dienste oder Anwendungen in Ihrem Konto, die den VPC-Endpunkt verwenden. Wenn Sie ihn löschen, kann dies zu Netzwerkunterbrechungen für andere Dienste führen. Gehen Sie beim Löschen dieser Endpunkte vorsichtig vor.
## Ich möchte nicht, dass meine Anwendung ab dem Beginn der Amazon MSK-Themen Nachrichten liest. Was soll ich tun?
Sie müssen je `source.msk.starting.offset` nach gewünschtem Verhalten explizit einen der folgenden Werte angeben:
+ **Frühester Offset**: Der älteste Offset in der Partition.
+ **Letzter Offset**: Verbraucher werden Nachrichten vom Ende der Partition lesen.
+ **Offset festgeschrieben**: Liest aus der letzten Nachricht, die der Verbraucher innerhalb einer Partition verarbeitet hat.
## Woher weiß ich, ob es ein Problem mit meiner Managed Service for Apache Flink-Anwendung gibt, und wie kann ich es debuggen?
Verwenden Sie den [Leitfaden zur Fehlerbehebung bei Managed Service for Apache Flink, um Probleme](https://docs.aws.amazon.com/managed-flink/latest/java/troubleshooting-runtime.html) im Zusammenhang mit Managed Service for Apache Flink mit Ihrer Anwendung zu debuggen.
## Was sind die wichtigsten Kennzahlen, die ich für meine Managed Service for Apache Flink-Anwendung überwachen sollte?
+ Alle Metriken, die für eine reguläre Managed Service for Apache Flink-Anwendung verfügbar sind, können Ihnen bei der Überwachung Ihrer Anwendung helfen. Weitere Informationen finden Sie unter [Metriken und Dimensionen in Managed Service für Apache Flink](https://docs.aws.amazon.com/managed-flink/latest/java/metrics-dimensions.html).
+ Informationen zur Überwachung der Amazon Bedrock-Metriken finden Sie unter [ CloudWatch Amazon-Metriken für Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/monitoring.html#runtime-cloudwatch-metrics).
+ Wir haben zwei neue Metriken zur Leistungsüberwachung bei der Generierung von Einbettungen hinzugefügt. Sie finden sie unter dem Namen der `EmbeddingGeneration` Operation in. CloudWatch Die beiden Metriken sind:
+ **BedrockTitanEmbeddingTokenCount**: Anzahl der Token, die in einer einzigen Anfrage an Amazon Bedrock vorhanden sind.
+ **BedrockEmbeddingGenerationLatencyMs**: Gibt die Zeit in Millisekunden an, die benötigt wurde, um eine Antwort von Amazon Bedrock zu senden und zu empfangen, um Einbettungen zu generieren.
+ Für serverlose Sammlungen von Amazon OpenSearch Service können Sie Metriken wie `IngestionDataRate` `IngestionDocumentErrors` und andere verwenden. Weitere Informationen finden Sie unter [ OpenSearch Serverless Monitoring with Amazon CloudWatch](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/monitoring-cloudwatch.html).
+ OpenSearch Bereitgestellte Metriken finden Sie unter [Überwachen von OpenSearch Cluster-Metriken mit Amazon CloudWatch](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/managedomains-cloudwatchmetrics.html).
# 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.