Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Risoluzione dei problemi relativi al servizio gestito per Apache Flink
I seguenti argomenti possono aiutarti a risolvere i problemi che potresti riscontrare con Amazon Managed Service for Apache Flink.
Scegli l'argomento appropriato per esaminare le soluzioni.
**Topics**
+ [Risoluzione dei problemi di sviluppo](troubleshooting-development.md)
+ [Risoluzione dei problemi di runtime](troubleshooting-runtime.md)
# Risoluzione dei problemi di sviluppo
Questa sezione contiene informazioni sulla diagnosi e la risoluzione dei problemi di sviluppo con l'applicazione Managed Service for Apache Flink.
**Topics**
+ [Le migliori pratiche per il rollback del sistema](troubleshooting-system-rollback.md)
+ [Le migliori pratiche di configurazione di Hudi](troubleshooting-hudi.md)
+ [Grafici a candela di Apache Flink](troubleshooting-update-flamegraphs.md)
+ [Problema con il provider di credenziali con il connettore EFO 1.15.2](troubleshooting-credential-provider.md)
+ [Applicazioni con connettori Kinesis non supportati](troubleshooting-unsupported-kinesis-connectors.md)
+ [Errore di compilazione: «Impossibile risolvere le dipendenze per il progetto»](troubleshooting-compile.md)
+ [Scelta non valida: «kinesisanalyticsv2"](troubleshooting-cli-update.md)
+ [UpdateApplication l'azione non consiste nel ricaricare il codice dell'applicazione](troubleshooting-update.md)
+ [S3 StreamingFileSink FileNotFoundExceptions](troubleshooting-s3sink.md)
+ [FlinkKafkaConsumer problema con stop with savepoint](troubleshooting-FlinkKafkaConsumer.md)
+ [Blocco di Async sink per Flink 1.15](troubleshooting-async-deadlock.md)
+ [L'elaborazione del codice sorgente dei flussi di dati di Amazon Kinesis non funziona correttamente durante il re-sharding](troubleshooting-kinesis-data-streams-processing-out-of-order.md)
+ [Domande frequenti e risoluzione dei problemi relativi ai progetti di incorporamento vettoriale in tempo reale](troubleshooting-blueprints.md)
# Le migliori pratiche per il rollback del sistema
Con il rollback automatico del sistema e le funzionalità di visibilità delle operazioni in Amazon Managed Service for Apache Flink, puoi identificare e risolvere i problemi con le tue applicazioni.
## Rollback del sistema
Se l'operazione di aggiornamento o ridimensionamento dell'applicazione non riesce a causa di un errore del cliente, ad esempio un bug nel codice o un problema di autorizzazione, Amazon Managed Service for Apache Flink tenta automaticamente di ripristinare la versione precedente in esecuzione se hai attivato questa funzionalità. Per ulteriori informazioni, consulta [Abilita i rollback di sistema per la tua applicazione Managed Service for Apache Flink](how-system-rollbacks.md). Se l'autorollback fallisce o se non hai effettuato l'attivazione o l'annullamento del consenso, l'applicazione verrà inserita nello stato. `READY` Per aggiornare la tua applicazione, completa i seguenti passaggi: Controlla la console Amazon Managed Service for Apache Flink o utilizza l'`DescribeApplicationOperation`API per visualizzare la descrizione dell'errore e spiegare il motivo per cui l'operazione non è riuscita. [Per lo stack completo degli errori, usa i log di Cloudwatch.](https://docs.aws.amazon.com/managed-flink/latest/java/logging.html) I problemi più comuni sono le autorizzazioni insufficienti, le modifiche al codice incompatibili o le configurazioni errate dell'infrastruttura. Risolvi il problema di fondo. Utilizza l'`UpdateApplicaton`API per ridistribuire la nuova versione dell'applicazione.
## Rollback manuale
Se l'applicazione non procede ed è in uno stato transitorio da molto tempo, o se l'applicazione è passata correttamente`Running`, ma si riscontrano problemi a valle come errori di elaborazione in un'applicazione Flink aggiornata correttamente, è possibile ripristinarla manualmente utilizzando l'API. `RollbackApplication`
1. Chiama`RollbackApplication`: questa operazione ripristinerà la versione precedente in esecuzione e ripristinerà lo stato precedente.
1. Monitora l'operazione di rollback utilizzando l'`DescribeApplicationOperation`API.
1. Se il rollback fallisce, utilizza i passaggi precedenti di rollback del sistema.
## Visibilità delle operazioni
L'`ListApplicationOperations`API mostra la cronologia di tutte le operazioni dei clienti e del sistema sull'applicazione.
1. Ottieni l'*OperationID* dell'operazione non riuscita dall'elenco.
1. Chiama `DescribeApplicationOperation` e controlla lo stato e lo *StatusDescription*.
1. Se un'operazione non è riuscita, la descrizione indica un potenziale errore da esaminare.
**Bug comuni relativi ai codici di errore:** utilizzate le funzionalità di rollback per ripristinare l'ultima versione funzionante. Risolvi i bug e riprova l'aggiornamento.
**Problemi di autorizzazione:** utilizza il `DescribeApplicationOperation` per visualizzare le autorizzazioni richieste. Aggiorna le autorizzazioni dell'applicazione e riprova.
**Problemi relativi al servizio Amazon Managed Service for Apache Flink:** verifica Dashboard AWS Health o apri una richiesta di supporto.
# Le migliori pratiche di configurazione di Hudi
Per eseguire i connettori Hudi su Managed Service for Apache Flink, consigliamo le seguenti modifiche alla configurazione.
Disabilitazione di `hoodie.embed.timeline.server`
Il connettore Hudi su Flink configura un server timeline (TM) incorporato sul Flink jobmanager (JM) per memorizzare nella cache i metadati per migliorare le prestazioni quando il parallelismo dei lavori è elevato. Ti consigliamo di disabilitare questo server incorporato su Managed Service for Apache Flink perché disabilitiamo la comunicazione non Flink tra JM e TM.
Se questo server è abilitato, Hudi write tenterà prima di connettersi al server integrato su JM, quindi tornerà alla lettura dei metadati da Amazon S3. Ciò significa che Hudi subisce un timeout di connessione che ritarda le scritture di Hudi e causa un impatto sulle prestazioni del servizio gestito per Apache Flink.
# Grafici a candela di Apache Flink
I grafici a candela sono abilitati per impostazione predefinita nelle applicazioni nelle versioni di servizio gestito per Apache Flink che li supportano. I grafici a candela possono influire sulle prestazioni dell'applicazione se rimangono aperti, come indicato nella [documentazione di Flink](https://nightlies.apache.org/flink/flink-docs-release-1.15//docs/ops/debugging/flame_graphs/).
Per disabilitare i grafici a candela per l’applicazione è sufficiente creare un caso e richiederne la disabilitazione per l'ARN dell’applicazione. Per ulteriori informazioni, consulta il [Centro di supporto AWS](https://console.aws.amazon.com/support/home#/).
# Problema con il provider di credenziali con il connettore EFO 1.15.2
Esiste un [problema noto](https://issues.apache.org/jira/browse/FLINK-29205) con le versioni del connettore EFO del flusso di dati Kinesis fino alla 1.15.2, in cui `FlinkKinesisConsumer` non rispetta la configurazione `Credential Provider`. Le configurazioni valide vengono ignorate a causa del problema, che comporta l'utilizzo del provider di credenziali `AUTO`. Ciò può causare problemi nell'utilizzo dell'accesso multi-account a Kinesis tramite il connettore EFO.
Per risolvere questo errore, è sufficiente utilizzare la versione 1.15.3 o successiva del connettore EFO.
# Applicazioni con connettori Kinesis non supportati
Managed Service for Apache Flink per Apache Flink versione 1.15 o successiva [rifiuterà automaticamente l'avvio o l'aggiornamento delle applicazioni se utilizzano versioni di Kinesis Connector](https://docs.aws.amazon.com/managed-flink/latest/java/flink-1-15-2.html) non supportate (precedenti alla versione 1.15.2) incluse in applicazioni o archivi (ZIP). JARs
## Errore di rifiuto
Verrà visualizzato il seguente errore quando si inviano chiamate di creazione/aggiornamento all'applicazione tramite:
```
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
```
## Come risolvere il problema
+ Aggiorna la dipendenza dell'applicazione da `flink-connector-kinesis`. Se utilizzi Maven come strumento di compilazione del progetto, segui [Aggiorna una dipendenza da Maven](#troubleshooting-unsupported-kinesis-connectors-update-maven-dependency). Se utilizzi Gradle, segui [Aggiorna una dipendenza da Gradle](#troubleshooting-unsupported-kinesis-connectors-update-gradle-dependency).
+ Crea di nuovo un pacchetto con l'applicazione.
+ Carica oggetti in un bucket Amazon S3.
+ Invia nuovamente la richiesta di creazione/aggiornamento con l'applicazione modificata appena caricata nel bucket Amazon S3.
+ Se il messaggio di errore continua a ripresentarsi, controlla nuovamente le dipendenze dell'applicazione. Crea un ticket per richiedere assistenza nel caso in cui il problema persista.
### Aggiorna una dipendenza da Maven
1. Apri il file `pom.xml` del progetto.
1. Individua le dipendenze del progetto. Hanno questo aspetto:
```
...
...
org.apache.flink
flink-connector-kinesis
...
...
```
1. Aggiorna `flink-connector-kinesis` a una versione uguale o successiva alla 1.15.2. Per esempio:
```
...
...
org.apache.flink
flink-connector-kinesis
1.15.2
...
...
```
### Aggiorna una dipendenza da Gradle
1. Apri il `build.gradle` del progetto (o `build.gradle.kts` per le applicazioni Kotlin).
1. Individua le dipendenze del progetto. Hanno questo aspetto:
```
...
dependencies {
...
implementation("org.apache.flink:flink-connector-kinesis")
...
}
...
```
1. Aggiorna `flink-connector-kinesis` a una versione uguale o successiva alla 1.15.2. Per esempio:
```
...
dependencies {
...
implementation("org.apache.flink:flink-connector-kinesis:1.15.2")
...
}
...
```
# Errore di compilazione: «Impossibile risolvere le dipendenze per il progetto»
Per compilare il servizio gestito per le applicazioni di esempio di Apache Flink, è necessario scaricare e compilare il connettore Kinesis di Apache Flink e aggiungerlo al repository locale di Maven. Se il connettore non è stato aggiunto al repository verrà visualizzato un errore di compilazione simile al seguente:
```
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
```
Per risolvere questo errore, è necessario scaricare il codice sorgente di Apache Flink (dalla versione 1.8.2) per il connettore. [https://flink.apache.org/downloads.html](https://flink.apache.org/downloads.html) Per istruzioni su come scaricare, compilare e installare il codice sorgente di Apache Flink, consulta [Utilizzo del connettore Apache Flink Kinesis Streams con versioni precedenti di Apache Flink](earlier.md#how-creating-apps-building-kinesis).
# Scelta non valida: «kinesisanalyticsv2"
Per utilizzare l'API v2 del servizio gestito per Apache Flink è necessaria la versione più recente di AWS Command Line Interface (AWS CLI).
[https://docs.aws.amazon.com/cli/latest/userguide/installing.html](https://docs.aws.amazon.com/cli/latest/userguide/installing.html)
# UpdateApplication l'azione non consiste nel ricaricare il codice dell'applicazione
L'[UpdateApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_UpdateApplication.html)azione non ricaricherà il codice dell'applicazione con lo stesso nome di file se non viene specificata la versione dell'oggetto S3. Per ricaricare il codice dell'applicazione con lo stesso nome di file, è necessario abilitare il controllo delle versioni sul bucket S3 e specificare la nuova versione dell'oggetto utilizzando il parametro `ObjectVersionUpdate`. Per ulteriori informazioni sul controllo delle versioni degli oggetti in un bucket S3, consulta [Abilitazione e sospensione del controllo delle versioni](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/enable-versioning.html).
# S3 StreamingFileSink FileNotFoundExceptions
Le applicazioni del servizio gestito per Apache Flink possono essere eseguite in un file delle parti in corso `FileNotFoundException` quando si parte da snapshot se manca un file delle parti in corso a cui fa riferimento il relativo savepoint. Quando si verifica questa modalità di errore, lo stato dell'operatore dell'applicazione di servizio gestito per Apache Flink non è in genere ripristinabile e deve essere riavviato senza utilizzare uno snapshot `SKIP_RESTORE_FROM_SNAPSHOT`. Vedi il seguente esempio di stack trace:
```
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` scrive i record su file system supportati dai File System.](https://nightlies.apache.org/flink/flink-docs-release-1.15/docs/deployment/filesystems/overview/) Dato che i flussi in entrata possono essere illimitati, i dati vengono organizzati in file delle parti di dimensioni limitate; man mano che i dati vengono scritti, i nuovi file sono aggiunti. Il ciclo di vita delle parti e la politica di rollover determinano le tempistiche, la dimensione e la denominazione dei file delle parti.
Durante il checkpoint e il savepoint (cattura degli snapshot), tutti i file in sospeso vengono rinominati e salvati. Tuttavia, i file delle parti in corso non sono salvati, ma rinominati; il riferimento viene mantenuto nei metadati del checkpoint o del savepoint, in modo da poter essere utilizzato durante il ripristino dei processi. I file delle parti in corso verranno infine contrassegnati come in sospeso, rinominati e salvati da un checkpoint o savepoint successivi.
Di seguito sono riportate le cause principali e le misure di mitigazione nel caso in cui manchino i file delle parti in corso:
+ Istantanea obsoleta utilizzata per avviare l'applicazione Managed Service for Apache Flink: solo l'ultima istantanea del sistema scattata quando un'applicazione viene arrestata o aggiornata può essere utilizzata per avviare un'applicazione Managed Service for Apache Flink con Amazon S3. StreamingFileSink Per evitare questa classe di errori è consigliabile utilizzare lo snapshot di sistema più recente.
+ Ciò accade ad esempio quando si sceglie uno snapshot creato utilizzando `CreateSnapshot` invece di uno innescato dal sistema durante l'arresto o l'aggiornamento. Il punto di salvataggio della vecchia istantanea conserva un out-of-date riferimento al file di parte in corso che è stato rinominato e salvato dal checkpoint o dal punto di salvataggio successivo.
+ Ciò può verificarsi anche quando viene selezionata un'istantanea attivata dal sistema relativa a un evento non più recente. Stop/Update Un esempio è un'applicazione con lo snapshot del sistema disabilitato ma `RESTORE_FROM_LATEST_SNAPSHOT` configurato. In genere, le applicazioni Managed Service for Apache Flink con Amazon StreamingFileSink S3 devono sempre avere lo snapshot di sistema abilitato e configurato. `RESTORE_FROM_LATEST_SNAPSHOT`
+ File delle parti In corso rimosso: poiché il file delle parti In corso si trova in un bucket S3, può essere rimosso da altri componenti o attori che hanno accesso al bucket.
+ [Ciò può accadere quando l'app è stata interrotta per troppo tempo e il file di parte in corso a cui fa riferimento il punto di salvataggio dell'app è stato rimosso dalla politica del ciclo di vita del bucket S3. MultiPartUpload](https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpu-abort-incomplete-mpu-lifecycle-config.html) Per evitare questa classe di errori, assicurarsi che la politica sul ciclo di vita del bucket MPU S3 si estenda su un periodo sufficientemente ampio per il caso d'utilizzo.
+ Ciò può accadere anche quando il file delle parti In corso è stato rimosso manualmente o da un altro componente del sistema. Per evitare questa classe di errori, assicurarsi che i file delle parti In corso non vengano rimossi da altri attori o componenti.
+ Condizione di competizione in cui viene innescato un checkpoint automatico dopo il checkpoint: ciò influisce sulle versioni di servizio gestito per Apache Flink fino alla 1.13 inclusa. Questo problema è stato risolto nella versione 1.15 di Managed Service for Apache Flink. Esegui la migrazione dell'applicazione alla versione più recente di Managed Service for Apache Flink per evitare che si verifichino recidive. Ti suggeriamo anche di migrare da a. StreamingFileSink [FileSink](https://nightlies.apache.org/flink/flink-docs-release-1.19/docs/connectors/datastream/filesystem/#file-sink)
+ Quando le applicazioni vengono arrestate o aggiornate, il servizio gestito per Apache Flink innesca un savepoint e arresta l'applicazione in due passaggi. Se tra i due passaggi si innesca un checkpoint automatico il savepoint sarà inutilizzabile, in quanto il relativo file delle parti in corso verrebbe rinominato e potenzialmente salvato.
# FlinkKafkaConsumer problema con stop with savepoint
Quando si utilizza la versione precedente FlinkKafkaConsumer , è possibile che l'applicazione rimanga bloccata in UPDATING, STOP o SCALING, se sono abilitate le istantanee di sistema. Non è disponibile alcuna correzione pubblicata per questo [problema](https://issues.apache.org/jira/browse/FLINK-28758), pertanto si consiglia di eseguire l'aggiornamento alla nuova versione per [KafkaSource](https://nightlies.apache.org/flink/flink-docs-master/docs/connectors/datastream/kafka/#kafka-source)mitigare il problema.
Se si utilizza `FlinkKafkaConsumer` con gli snapshot abilitati, esiste la possibilità che, quando il processo Flink elabora un arresto con una richiesta di savepoint API, `FlinkKafkaConsumer` possa non riuscire e mostrare un errore di runtime che segnala un `ClosedException`. In queste condizioni l'applicazione Flink si blocca e dà luogo a checkpoint non riusciti.
# Blocco di Async sink per Flink 1.15
Esiste un [problema noto](https://issues.apache.org/jira/browse/FLINK-32230) con i AWS connettori per l'interfaccia di implementazione di Apache Flink. AsyncSink Ciò riguarda le applicazioni che utilizzano Flink 1.15 con i seguenti connettori:
+ Per applicazioni Java:
+ 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`
+ Applicazioni Flink: SQL/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`
Le applicazioni interessate presenteranno le seguenti caratteristiche:
+ il processo di Flink è nello stato`RUNNING`, ma non elabora i dati;
+ non si verificano riavvii del processo;
+ I checkpoint sono in fase di interruzione.
Il problema è causato da un [bug](https://github.com/aws/aws-sdk-java-v2/issues/4354) nell' AWS SDK che impedisce la visualizzazione di alcuni errori al chiamante quando utilizza il client HTTP asincrono. Il risultato è che il sink continuerà ad attendere il completamento di una "richiesta in corso" durante un'operazione di pulizia del checkpoint.
**Questo problema è stato risolto in AWS SDK a partire dalla versione 2.20.144.**
Di seguito sono riportate le istruzioni su come aggiornare i connettori interessati per utilizzare la nuova versione di AWS SDK nelle applicazioni:
**Topics**
+ [Aggiornamento dell'applicazione Java.](troubleshooting-async-deadlock-update-java-apps.md)
+ [Aggiornamento di applicazioni Python](troubleshooting-async-deadlock-update-python-apps.md)
# Aggiornamento dell'applicazione Java.
Per aggiornare le applicazioni Java è sufficiente seguire il seguente procedimento:
## flink-connector-kinesis
Se l'applicazione utilizza `flink-connector-kinesis`:
Il connettore Kinesis utilizza lo shading per impacchettare alcune dipendenze, incluso l' AWS SDK, nella barra dei connettori. Per aggiornare la versione AWS SDK, utilizza la seguente procedura per sostituire queste classi ombreggiate:
------
#### [ Maven ]
1. Aggiungi il connettore Kinesis e i moduli AWS SDK richiesti come dipendenze del progetto.
1. Configurare `maven-shade-plugin`:
1. Aggiungi un filtro per escludere le classi AWS SDK ombreggiate durante la copia del contenuto del jar del connettore Kinesis.
1. Aggiungi la regola di riposizionamento per spostare le classi AWS SDK aggiornate nel pacchetto, prevista dal connettore Kinesis.
**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. Aggiungi il connettore Kinesis e i moduli AWS SDK richiesti come dipendenze del progetto.
1. Modificare la configurazione di shadowJar:
1. Escludi le classi AWS SDK ombreggiate quando copi il contenuto del jar del connettore Kinesis.
1. Trasferisci le classi AWS SDK aggiornate in un pacchetto previsto dal connettore Kinesis.
**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")
}
...
```
------
## Altri connettori interessati
Se l'applicazione utilizza un altro connettore interessato:
Per aggiornare la versione SDK, la versione AWS SDK deve essere applicata nella configurazione di build del progetto.
------
#### [ Maven ]
Aggiungi la distinta base AWS SDK (BOM) alla sezione di gestione delle dipendenze del `pom.xml` file per applicare la versione SDK per il progetto.
**pom.xml**
```
...
...
software.amazon.awssdk
bom
2.20.144
import
pom
...
...
```
------
#### [ Gradle ]
Aggiungi la dipendenza della piattaforma dalla distinta base (BOM) dell' AWS SDK per applicare la versione SDK per il progetto. Sarà necessaria la versione Gradle 5.0 o versioni successive:
**build.gradle**
```
...
dependencies {
...
flinkShadowJar(platform("software.amazon.awssdk:bom:2.20.144"))
...
}
...
```
------
# Aggiornamento di applicazioni Python
Le applicazioni Python possono utilizzare i connettori in due maniere diverse: per impacchettare connettori e altre dipendenze Java come parte di un singolo uber jar o utilizzare direttamente il connettore jar. Per correggere le applicazioni interessate dal blocco di Async sink:
+ Se l'applicazione utilizza un uber jar, seguire le istruzioni per [Aggiornamento dell'applicazione Java.](troubleshooting-async-deadlock-update-java-apps.md).
+ Per ricostruire i connettori jar dalla sorgente, seguire i passaggi seguenti:
**Creazione di connettori dalla fonte:**
Prerequisiti, simili ai [requisiti per la costruzione](https://nightlies.apache.org/flink/flink-docs-release-1.15/docs/flinkdev/building/#build-flink) di Flink:
+ Java 11
+ Maven 3.2.5
## flink-sql-connector-kinesis
1. Scarica il codice sorgente per Flink 1.15.4:
```
wget https://archive.apache.org/dist/flink/flink-1.15.4/flink-1.15.4-src.tgz
```
1. Decomprimi il codice sorgente:
```
tar -xvf flink-1.15.4-src.tgz
```
1. Vai alla directory del connettore Kinesis
```
cd flink-1.15.4/flink-connectors/flink-connector-kinesis/
```
1. Compila e installa il connettore jar, specificando la versione SDK richiesta. AWS Per velocizzare la compilazione, usa `-DskipTests` per saltare l'esecuzione dei test e `-Dfast` per saltare i controlli aggiuntivi del codice sorgente:
```
mvn clean install -DskipTests -Dfast -Daws.sdkv2.version=2.20.144
```
1. Vai alla directory del connettore Kinesis
```
cd ../flink-sql-connector-kinesis
```
1. Compilare e installare il connettore jar sql:
```
mvn clean install -DskipTests -Dfast
```
1. Il jar risultante sarà disponibile all'indirizzo:
```
target/flink-sql-connector-kinesis-1.15.4.jar
```
## flink-sql-connector-aws-kinesis-stream
1. Scarica il codice sorgente per Flink 1.15.4:
```
wget https://archive.apache.org/dist/flink/flink-1.15.4/flink-1.15.4-src.tgz
```
1. Decomprimi il codice sorgente:
```
tar -xvf flink-1.15.4-src.tgz
```
1. Vai alla directory del connettore Kinesis
```
cd flink-1.15.4/flink-connectors/flink-connector-aws-kinesis-streams/
```
1. Compila e installa il connector jar, specificando la versione SDK richiesta. AWS Per velocizzare la compilazione, usa `-DskipTests` per saltare l'esecuzione dei test e `-Dfast` per saltare i controlli aggiuntivi del codice sorgente:
```
mvn clean install -DskipTests -Dfast -Daws.sdk.version=2.20.144
```
1. Vai alla directory del connettore Kinesis
```
cd ../flink-sql-connector-aws-kinesis-streams
```
1. Compilare e installare il connettore jar sql:
```
mvn clean install -DskipTests -Dfast
```
1. Il jar risultante sarà disponibile all'indirizzo:
```
target/flink-sql-connector-aws-kinesis-streams-1.15.4.jar
```
## flink-sql-connector-aws-kinesis-firehose
1. Scarica il codice sorgente per Flink 1.15.4:
```
wget https://archive.apache.org/dist/flink/flink-1.15.4/flink-1.15.4-src.tgz
```
1. Decomprimi il codice sorgente:
```
tar -xvf flink-1.15.4-src.tgz
```
1. Accedi alla directory del connettore
```
cd flink-1.15.4/flink-connectors/flink-connector-aws-kinesis-firehose/
```
1. Compila e installa il connettore jar, specificando la versione SDK richiesta. AWS Per velocizzare la compilazione, usa `-DskipTests` per saltare l'esecuzione dei test e `-Dfast` per saltare i controlli aggiuntivi del codice sorgente:
```
mvn clean install -DskipTests -Dfast -Daws.sdk.version=2.20.144
```
1. Accedi alla directory del connettore sql
```
cd ../flink-sql-connector-aws-kinesis-firehose
```
1. Compilare e installare il connettore jar sql:
```
mvn clean install -DskipTests -Dfast
```
1. Il jar risultante sarà disponibile all'indirizzo:
```
target/flink-sql-connector-aws-kinesis-firehose-1.15.4.jar
```
## flink-sql-connector-dynamodb
1. Scarica il codice sorgente per 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. Decomprimi il codice sorgente:
```
tar -xvf flink-connector-aws-3.0.0-src.tgz
```
1. Accedi alla directory del connettore
```
cd flink-connector-aws-3.0.0
```
1. Compila e installa il connettore jar, specificando la versione SDK richiesta. AWS Per velocizzare la compilazione, usa `-DskipTests` per saltare l'esecuzione dei test e `-Dfast` per saltare i controlli aggiuntivi del codice sorgente:
```
mvn clean install -DskipTests -Dfast -Dflink.version=1.15.4 -Daws.sdk.version=2.20.144
```
1. Il jar risultante sarà disponibile all'indirizzo:
```
flink-sql-connector-dynamodb/target/flink-sql-connector-dynamodb-3.0.0.jar
```
# L'elaborazione del codice sorgente dei flussi di dati di Amazon Kinesis non funziona correttamente durante il re-sharding
L' FlinkKinesisConsumer implementazione attuale non fornisce forti garanzie di ordinamento tra gli shard Kinesis. Ciò può comportare l' out-of-orderelaborazione durante la ripartizione di Kinesis Stream, in particolare per le applicazioni Flink che presentano ritardi di elaborazione. In alcune circostanze, ad esempio gli operatori delle finestre basati sugli orari degli eventi, gli eventi potrebbero essere eliminati a causa del ritardo che ne deriva.
![\[Diagram showing shards and shard consumers with time progression and trim horizon.\]](http://docs.aws.amazon.com/it_it/managed-flink/latest/java/images/flink-ts.png)
Si tratta di un [problema noto](https://issues.apache.org/jira/browse/FLINK-6349) in Open source di Flink. Fino a quando non sarà disponibile la correzione del connettore, è fondamentale assicurarsi che le applicazioni Flink non accumulino ritardi rispetto al flusso di dati Kinesis nel corso del partizionamento. Assicurandoti che il ritardo di elaborazione sia tollerato dalle tue app Flink, puoi ridurre al minimo l'impatto dell'elaborazione e il rischio di perdita dei out-of-order dati.
# Domande frequenti e risoluzione dei problemi relativi ai progetti di incorporamento vettoriale in tempo reale
Consulta le seguenti domande frequenti e le sezioni sulla risoluzione dei problemi relativi ai blueprint di incorporamento vettoriale in tempo reale. [Per ulteriori informazioni sui blueprint di incorporamento vettoriale in tempo reale, consulta Blueprint di incorporamento vettoriale in tempo reale.](https://docs.aws.amazon.com/msk/latest/developerguide/ai-vector-embedding-integration-learn-more.html)
[Per la risoluzione generale dei problemi relativi all'applicazione Managed Service for Apache Flink, consulta -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**
+ [Progetti di incorporamento vettoriale in tempo reale - Domande frequenti](troubleshooting-blueprints-FAQ.md)
+ [Blueprint di incorporamento vettoriale in tempo reale: risoluzione dei problemi](troubleshooting-blueprints-TS.md)
# Progetti di incorporamento vettoriale in tempo reale - Domande frequenti
Consulta le seguenti domande frequenti sui progetti di incorporamento vettoriale in tempo reale. [Per ulteriori informazioni sui blueprint di incorporamento vettoriale in tempo reale, consulta Blueprint di incorporamento vettoriale in tempo reale.](https://docs.aws.amazon.com/msk/latest/developerguide/ai-vector-embedding-integration-learn-more.html)
**Topics**
+ [Quali risorse crea AWS questo modello?](#troubleshooting-blueprints-1)
+ [Quali sono le mie azioni una volta completata l'implementazione dello AWS CloudFormation stack?](#troubleshooting-blueprints-2)
+ [Quale dovrebbe essere la struttura dei dati negli argomenti di origine di Amazon MSK?](#troubleshooting-blueprints-3)
+ [Posso specificare parti di un messaggio da incorporare?](#troubleshooting-blueprints-4)
+ [Posso leggere dati da più argomenti di Amazon MSK?](#troubleshooting-blueprints-5)
+ [Posso usare regex per configurare i nomi degli argomenti di Amazon MSK?](#troubleshooting-blueprints-6)
+ [Qual è la dimensione massima di un messaggio che può essere letto da un argomento di Amazon MSK?](#troubleshooting-blueprints-7)
+ [Che tipo di è supportato? OpenSearch](#troubleshooting-blueprints-8)
+ [Perché devo utilizzare una raccolta di ricerca vettoriale, un indice vettoriale e aggiungere un campo vettoriale nella mia raccolta Serverless? OpenSearch](#troubleshooting-blueprints-9)
+ [Cosa devo impostare come dimensione per il mio campo vettoriale?](#troubleshooting-blueprints-10)
+ [Che aspetto ha l'output nell'indice OpenSearch configurato?](#troubleshooting-blueprints-11)
+ [Posso specificare campi di metadati da aggiungere al documento memorizzato nell'indice? OpenSearch](#troubleshooting-blueprints-12)
+ [Devo aspettarmi voci duplicate nell' OpenSearch indice?](#troubleshooting-blueprints-13)
+ [Posso inviare dati a più indici? OpenSearch](#troubleshooting-blueprints-14)
+ [Posso implementare più applicazioni di incorporamento vettoriale in tempo reale in un'unica applicazione? Account AWS](#troubleshooting-blueprints-15)
+ [Più applicazioni di incorporamento vettoriale in tempo reale possono utilizzare la stessa fonte di dati o lo stesso sink?](#troubleshooting-blueprints-16)
+ [L'applicazione supporta la connettività tra account?](#troubleshooting-blueprints-17)
+ [L'applicazione supporta la connettività tra regioni?](#troubleshooting-blueprints-18)
+ [Il mio cluster e la mia OpenSearch raccolta Amazon MSK possono trovarsi in VPCs sottoreti diverse?](#troubleshooting-blueprints-19)
+ [Quali modelli di incorporamento sono supportati dall'applicazione?](#troubleshooting-blueprints-20)
+ [Posso ottimizzare le prestazioni della mia applicazione in base al mio carico di lavoro?](#troubleshooting-blueprints-21)
+ [Quali tipi di autenticazione Amazon MSK sono supportati?](#troubleshooting-blueprints-22)
+ [Cos'è `sink.os.bulkFlushIntervalMillis` e come posso impostarlo?](#troubleshooting-blueprints-23)
+ [Quando distribuisco la mia applicazione Managed Service for Apache Flink, da quale punto dell'argomento Amazon MSK inizierà a leggere i messaggi?](#troubleshooting-blueprints-24)
+ [Come posso usare`source.msk.starting.offset`?](#troubleshooting-blueprints-25)
+ [Quali strategie di suddivisione in blocchi sono supportate?](#troubleshooting-blueprints-26)
+ [Come faccio a leggere i record nel mio datastore vettoriale?](#troubleshooting-blueprints-27)
+ [Dove posso trovare nuovi aggiornamenti al codice sorgente?](#troubleshooting-blueprints-28)
+ [Posso apportare una modifica al AWS CloudFormation modello e aggiornare l'applicazione Managed Service for Apache Flink?](#troubleshooting-blueprints-29)
+ [AWS Monitorerà e gestirà l'applicazione per mio conto?](#troubleshooting-blueprints-30)
+ [Questa applicazione sposta i miei dati al di fuori del mio Account AWS?](#troubleshooting-blueprints-31)
## Quali risorse crea AWS questo modello?
Per trovare le risorse distribuite nel tuo account, accedi alla AWS CloudFormation console e identifica il nome dello stack che inizia con il nome che hai fornito per l'applicazione Managed Service for Apache Flink. Scegli la scheda **Risorse** per controllare le risorse che sono state create come parte dello stack. Le seguenti sono le risorse chiave create dallo stack:
+ Servizio gestito di incorporamento vettoriale in tempo reale per l'applicazione Apache Flink
+ Bucket Amazon S3 per contenere il codice sorgente per l'applicazione di incorporamento vettoriale in tempo reale
+ CloudWatch gruppo di log e flusso di log per l'archiviazione dei log
+ Funzioni Lambda per il recupero e la creazione di risorse
+ Ruoli e policy IAM per Lambdas, Managed Service for Apache Flink e accesso ad Amazon Bedrock e Amazon Service OpenSearch
+ Politica di accesso ai dati per Amazon OpenSearch Service
+ Endpoint VPC per accedere ad Amazon Bedrock e Amazon Service OpenSearch
## Quali sono le mie azioni una volta completata l'implementazione dello AWS CloudFormation stack?
Una volta completata la distribuzione AWS CloudFormation dello stack, accedi alla console Managed Service for Apache Flink e trova l'applicazione blueprint Managed Service for Apache Flink. Scegli la scheda **Configura** e conferma che tutte le proprietà di runtime siano configurate correttamente. Potrebbero passare alla pagina successiva. Quando sei sicuro delle impostazioni, scegli **Esegui**. L'applicazione inizierà a importare i messaggi dal tuo argomento.
[Per verificare la presenza di nuove versioni, https://github.com/awslabs/ real-time-vectorization-of consulta -streaming-data/releases.](https://github.com/awslabs/real-time-vectorization-of-streaming-data/releases)
## Quale dovrebbe essere la struttura dei dati negli argomenti di origine di Amazon MSK?
Al momento supportiamo dati di origine strutturati e non strutturati.
+ I dati non strutturati sono indicati con in. `STRING` `source.msk.data.type` I dati vengono letti così come sono dal messaggio in arrivo.
+ Attualmente supportiamo i dati JSON strutturati, indicati con in. `JSON` `source.msk.data.type` I dati devono essere sempre in formato JSON. Se l'applicazione riceve un codice JSON non valido, l'applicazione fallirà.
+ Quando utilizzi JSON come tipo di dati di origine, assicurati che ogni messaggio in tutti gli argomenti di origine sia un JSON valido. Se sottoscrivi uno o più argomenti che non contengono oggetti JSON con questa impostazione, l'applicazione avrà esito negativo. Se uno o più argomenti contengono una combinazione di dati strutturati e non strutturati, si consiglia di configurare i dati di origine come non strutturati nell'applicazione Managed Service for Apache Flink.
## Posso specificare parti di un messaggio da incorporare?
+ Per i `source.msk.data.type` dati di input non strutturati`STRING`, l'applicazione incorporerà sempre l'intero messaggio e memorizzerà l'intero messaggio nell'indice configurato. OpenSearch
+ Per i dati di input strutturati where `source.msk.data.type` is`JSON`, è possibile configurare in modo `embed.input.config.json.fieldsToEmbed` da specificare quale campo dell'oggetto JSON deve essere selezionato per l'incorporamento. Funziona solo per i campi JSON di primo livello e non funziona con i messaggi annidati JSONs e contenenti un array JSON. Usa .\$1 per incorporare l'intero JSON.
## Posso leggere dati da più argomenti di Amazon MSK?
Sì, con questa applicazione puoi leggere dati da più argomenti di Amazon MSK. I dati di tutti gli argomenti devono essere dello stesso tipo (STRING o JSON), altrimenti l'applicazione potrebbe fallire. I dati di tutti gli argomenti vengono sempre archiviati in un unico OpenSearch indice.
## Posso usare regex per configurare i nomi degli argomenti di Amazon MSK?
`source.msk.topic.names`non supporta un elenco di espressioni regolari. Supportiamo un elenco separato da virgole di nomi di argomenti o `.*` espressioni regolari per includere tutti gli argomenti.
## Qual è la dimensione massima di un messaggio che può essere letto da un argomento di Amazon MSK?
La dimensione massima di un messaggio che può essere elaborato è limitata dal limite di InvokeModel corpi di Amazon Bedrock, attualmente impostato su 25.000.000. Per ulteriori informazioni, consulta [InvokeModel](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_InvokeModel.html#API_runtime_InvokeModel_RequestBody).
## Che tipo di è supportato? OpenSearch
Supportiamo sia i OpenSearch domini che le raccolte. Se utilizzi una OpenSearch raccolta, assicurati di utilizzare una raccolta vettoriale e di creare un indice vettoriale da utilizzare per questa applicazione. Questo vi permetterà di utilizzare le funzionalità del database OpenSearch vettoriale per interrogare i vostri dati. Per ulteriori informazioni, consulta la [spiegazione delle funzionalità dei database vettoriali di Amazon OpenSearch Service](https://aws.amazon.com/blogs/big-data/amazon-opensearch-services-vector-database-capabilities-explained/).
## Perché devo utilizzare una raccolta di ricerca vettoriale, un indice vettoriale e aggiungere un campo vettoriale nella mia raccolta Serverless? OpenSearch
Il tipo di raccolta di *ricerca vettoriale* in OpenSearch Serverless offre una funzionalità di ricerca per similarità scalabile e ad alte prestazioni. Semplifica la creazione di moderne esperienze di ricerca aumentata di machine learning (ML) e applicazioni generative di intelligenza artificiale (AI). Per ulteriori informazioni, consulta [Lavorare con le raccolte di ricerca vettoriale](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-vector-search.html?icmpid=docs_console_unmapped).
## Cosa devo impostare come dimensione per il mio campo vettoriale?
Imposta la dimensione del campo vettoriale in base al modello di incorporamento che desideri utilizzare. Fate riferimento alla tabella seguente e confermate questi valori dalla rispettiva documentazione.
**Dimensioni dei campi vettoriali**
| Nome del modello di incorporamento vettoriale Amazon Bedrock | Supporto per le dimensioni di output offerto dal modello |
| --- | --- |
| Incorporamenti di testo Amazon Titan V1 | 1.536 |
| Embedding di testo Amazon Titan V2 | 1.024 (impostazione predefinita), 384, 256 |
| Amazon Titan Multimodal Embeddings G1 | 1.024 (impostazione predefinita), 384, 256 |
| Cohere Embed English | 1,024 |
| Cohere Embed Multilingual | 1,024 |
## Che aspetto ha l'output nell'indice OpenSearch configurato?
Ogni documento dell' OpenSearch indice contiene i seguenti campi:
+ **original\$1data: i dati** utilizzati per generare gli incorporamenti. Per il tipo STRING, è l'intero messaggio. Per l'oggetto JSON, è l'oggetto JSON utilizzato per gli incorporamenti. Potrebbe essere l'intero JSON nel messaggio o i campi specificati nel JSON. Ad esempio, se il nome fosse selezionato per essere incorporato nei messaggi in arrivo, l'output sarebbe il seguente:
```
"original_data": "{\"name\":\"John Doe\"}"
```
+ **embedded\$1data**: una matrice vettoriale float di incorporamenti generata da Amazon Bedrock
+ **data: timestamp** UTC in cui il documento è stato archiviato OpenSearch
## Posso specificare campi di metadati da aggiungere al documento memorizzato nell'indice? OpenSearch
No, al momento non supportiamo l'aggiunta di campi aggiuntivi al documento finale memorizzato nell' OpenSearch indice.
## Devo aspettarmi voci duplicate nell' OpenSearch indice?
A seconda di come è stata configurata l'applicazione, è possibile che nell'indice vengano visualizzati messaggi duplicati. Uno dei motivi più comuni è il riavvio dell'applicazione. L'applicazione è configurata per impostazione predefinita per iniziare a leggere dal primo messaggio nell'argomento di origine. Quando si modifica la configurazione, l'applicazione si riavvia ed elabora nuovamente tutti i messaggi dell'argomento. Per evitare la rielaborazione, consultate la documentazione su come utilizzare source.msk.starting.offset e impostate correttamente l'offset iniziale per l'applicazione.
## Posso inviare dati a più indici? OpenSearch
No, l'applicazione supporta l'archiviazione dei dati in un unico OpenSearch indice. Per configurare l'output di vettorizzazione su più indici, è necessario distribuire un servizio gestito separato per le applicazioni Apache Flink.
## Posso implementare più applicazioni di incorporamento vettoriale in tempo reale in un'unica applicazione? Account AWS
Sì, puoi distribuire più servizi gestiti di incorporamento vettoriale in tempo reale per applicazioni Apache Flink in un'unica Account AWS applicazione se ogni applicazione ha un nome univoco.
## Più applicazioni di incorporamento vettoriale in tempo reale possono utilizzare la stessa fonte di dati o lo stesso sink?
Sì, puoi creare più servizi gestiti di incorporamento vettoriale in tempo reale per applicazioni Apache Flink che leggono i dati dallo stesso argomento o archiviano i dati nello stesso indice.
## L'applicazione supporta la connettività tra account?
No, affinché l'applicazione funzioni correttamente, il cluster Amazon MSK e la OpenSearch raccolta devono trovarsi nello stesso Account AWS punto in cui stai tentando di configurare l'applicazione Managed Service for Apache Flink.
## L'applicazione supporta la connettività tra regioni?
No, l'applicazione consente solo di distribuire un'applicazione Managed Service for Apache Flink con un cluster Amazon MSK e una OpenSearch raccolta nella stessa regione dell'applicazione Managed Service for Apache Flink.
## Il mio cluster e la mia OpenSearch raccolta Amazon MSK possono trovarsi in VPCs sottoreti diverse?
Sì, supportiamo il cluster e la OpenSearch raccolta Amazon MSK in diverse VPCs sottoreti, purché si trovino nella stessa. Account AWS Vedi (Risoluzione dei problemi generali di MSF) per verificare che la configurazione sia corretta.
## Quali modelli di incorporamento sono supportati dall'applicazione?
Attualmente, l'applicazione supporta tutti i modelli supportati da Bedrock. Ciò include:
+ Titan Embeddings G1 - Text
+ Embedding di testo Amazon Titan V2
+ Amazon Titan Multimodal Embeddings G1
+ Cohere Embed English
+ Cohere Embed Multilingual
## Posso ottimizzare le prestazioni della mia applicazione in base al mio carico di lavoro?
Sì. La velocità effettiva dell'applicazione dipende da una serie di fattori, tutti controllabili dai clienti:
1. **AWS MSF KPUs**: L'applicazione viene distribuita con fattore di parallelismo predefinito 2 e parallelismo per KPU 1, con ridimensionamento automatico attivato. Tuttavia, ti consigliamo di configurare la scalabilità per l'applicazione Managed Service for Apache Flink in base ai tuoi carichi di lavoro. Per ulteriori informazioni, consulta [Review Managed Service for Apache](https://docs.aws.amazon.com/managed-flink/latest/java/how-resources.html) Flink application Resources.
1. **Amazon Bedrock**: in base al modello on-demand di Amazon Bedrock selezionato, potrebbero essere applicate quote diverse. Controlla le quote di servizio in Bedrock per vedere il carico di lavoro che il servizio sarà in grado di gestire. Per ulteriori informazioni, consulta [Quotas for Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/quotas.html).
1. **Amazon OpenSearch Service**: inoltre, in alcune situazioni, potresti notare che questo OpenSearch è il collo di bottiglia nella tua pipeline. Per informazioni sulla scalabilità, consulta OpenSearch [Ridimensionamento dei domini OpenSearch Amazon Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/sizing-domains.html).
## Quali tipi di autenticazione Amazon MSK sono supportati?
Supportiamo solo il tipo di autenticazione IAM MSK.
## Cos'è `sink.os.bulkFlushIntervalMillis` e come posso impostarlo?
Quando si inviano dati ad Amazon OpenSearch Service, l'intervallo di trasferimento in blocco è l'intervallo in cui viene eseguita la richiesta in blocco, indipendentemente dal numero di azioni o dalla dimensione della richiesta. Il valore predefinito è impostato su 1 millisecondo.
L'impostazione di un intervallo di lavaggio può aiutare a garantire che i dati vengano indicizzati tempestivamente, ma può anche comportare un aumento del sovraccarico se impostato su un valore troppo basso. Considerate il vostro caso d'uso e l'importanza di un'indicizzazione tempestiva quando scegliete un intervallo di flush.
## Quando distribuisco la mia applicazione Managed Service for Apache Flink, da quale punto dell'argomento Amazon MSK inizierà a leggere i messaggi?
L'applicazione inizierà a leggere i messaggi dall'argomento Amazon MSK all'offset specificato dalla `source.msk.starting.offset` configurazione impostata nella configurazione di runtime dell'applicazione. Se non `source.msk.starting.offset` è impostato in modo esplicito, il comportamento predefinito dell'applicazione consiste nell'iniziare a leggere dal primo messaggio disponibile nell'argomento.
## Come posso usare`source.msk.starting.offset`?
Imposta esplicitamente s `ource.msk.starting.offset` su uno dei seguenti valori, in base al comportamento desiderato:
+ EARLEST: L'impostazione predefinita, che legge dall'offset più vecchio nella partizione. Questa è una buona scelta soprattutto se:
+ Hai appena creato argomenti e applicazioni consumer di Amazon MSK.
+ È necessario riprodurre i dati, in modo da poter creare o ricostruire lo stato. Ciò è importante quando si implementa il pattern di approvvigionamento degli eventi o quando si inizializza un nuovo servizio che richiede una visualizzazione completa della cronologia dei dati.
+ ULTIMO: L'applicazione Managed Service for Apache Flink leggerà i messaggi dalla fine della partizione. Ti consigliamo questa opzione se ti interessa solo la produzione di nuovi messaggi e non hai bisogno di elaborare dati storici. In questa impostazione, il consumatore ignorerà i messaggi esistenti e leggerà solo i nuovi messaggi pubblicati dal produttore originale.
+ COMMITTED: L'applicazione Managed Service for Apache Flink inizierà a consumare i messaggi provenienti dall'offset impegnato del gruppo di consumatori. Se l'offset confermato non esiste, verrà utilizzata la strategia di ripristino EARLIEST.
## Quali strategie di suddivisione in blocchi sono supportate?
Stiamo usando la libreria [langchain](https://js.langchain.com/v0.1/docs/get_started/introduction/) per suddividere gli input. Il chunking viene applicato solo se la lunghezza dell'input è maggiore di quella scelta. `maxSegmentSizeInChars` Supportiamo i seguenti cinque tipi di chunking:
+ `SPLIT_BY_CHARACTER`: Inserirà il maggior numero di caratteri possibile in ogni blocco in cui la lunghezza di ogni blocco non è maggiore di. maxSegmentSize InChars Non gli interessa lo spazio bianco, quindi può tagliare le parole.
+ `SPLIT_BY_WORD`: troverà i caratteri di spaziatura in base ai quali suddividere. Nessuna parola viene interrotta.
+ `SPLIT_BY_SENTENCE`: I limiti delle frasi vengono rilevati utilizzando la libreria Apache OpenNLP con il modello di frase in inglese.
+ `SPLIT_BY_LINE`: troverà nuovi caratteri di riga in base ai quali suddividere.
+ `SPLIT_BY_PARAGRAPH`: troverà nuovi caratteri di riga consecutivi in base ai quali suddividere in blocchi.
Le strategie di suddivisione rientrano nell'ordine precedente, a cui ricorrono le strategie di suddivisione in blocchi più grandi. `SPLIT_BY_PARAGRAPH` `SPLIT_BY_CHARACTER` Ad esempio, quando si utilizza`SPLIT_BY_LINE`, se una riga è troppo lunga, la riga verrà suddivisa in blocchi per frase, dove ogni blocco può contenere quante più frasi possibile. Se ci sono frasi troppo lunghe, verranno suddivise in blocchi a livello di parola. Se una parola è troppo lunga, verrà divisa per carattere.
## Come faccio a leggere i record nel mio datastore vettoriale?
1. Quando è `source.msk.data.type` `STRING`
+ **original\$1data**: l'intera stringa originale del messaggio Amazon MSK.
+ **embedded\$1data**: vettore di incorporamento creato se non è vuoto (suddivisione in blocchi applicata) o creato da `chunk_data` se non è stato applicato alcun chunking. `original_data`
+ **chunk\$1data: presente solo quando i dati originali sono stati suddivisi in blocchi**. Contiene la parte del messaggio originale che è stata utilizzata per creare l'incorporamento. `embedded_data`
1. Quando è `source.msk.data.type` `JSON`
+ **original\$1data**: l'intero codice JSON originale del messaggio Amazon MSK *dopo l'applicazione del filtro delle chiavi JSON*.
+ **embedded\$1data**: vettore di incorporamento creato se non è vuoto (suddivisione in blocchi applicata) o creato da `chunk_data` se non è stata applicata alcuna suddivisione in blocchi. `original_data`
+ **chunk\$1key: presente solo quando i dati originali erano suddivisi in blocchi**. Contiene la chiave JSON da cui proviene il blocco. `original_data` Ad esempio, può assomigliare alle chiavi o `jsonKey1.nestedJsonKeyA` ai *metadati* annidati nell'esempio di. `original_data`
+ **chunk\$1data: presente solo quando i dati** originali erano suddivisi in blocchi. Contiene la parte del messaggio originale che è stata utilizzata per creare l'incorporamento. `embedded_data`
Sì, con questa applicazione puoi leggere dati da più argomenti di Amazon MSK. I dati di tutti gli argomenti devono essere dello stesso tipo (STRING o JSON), altrimenti l'applicazione potrebbe fallire. I dati di tutti gli argomenti vengono sempre archiviati in un unico OpenSearch indice.
## Dove posso trovare nuovi aggiornamenti al codice sorgente?
Vai a [https://github.com/awslabs/real-time-vectorization-of-streaming-data/releases](https://github.com/awslabs/real-time-vectorization-of-streaming-data/releases) per verificare la presenza di nuove versioni.
## Posso apportare una modifica al AWS CloudFormation modello e aggiornare l'applicazione Managed Service for Apache Flink?
No, apportare una modifica al AWS CloudFormation modello non aggiorna l'applicazione Managed Service for Apache Flink. Qualsiasi nuova modifica AWS CloudFormation implica la necessità di implementare un nuovo stack.
## AWS Monitorerà e gestirà l'applicazione per mio conto?
No, non AWS monitorerà, ridimensionerà, aggiornerà o applicherà patch a questa applicazione per tuo conto.
## Questa applicazione sposta i miei dati al di fuori del mio Account AWS?
Tutti i dati letti e archiviati dall'applicazione Managed Service for Apache Flink rimangono all'interno dell'utente Account AWS e non escono mai dal suo account.
# Blueprint di incorporamento vettoriale in tempo reale: risoluzione dei problemi
Consulta i seguenti argomenti di risoluzione dei problemi relativi ai blueprint di incorporamento vettoriale in tempo reale. [Per ulteriori informazioni sui blueprint di incorporamento vettoriale in tempo reale, consulta Blueprint di incorporamento vettoriale in tempo reale.](https://docs.aws.amazon.com/msk/latest/developerguide/ai-vector-embedding-integration-learn-more.html)
**Topics**
+ [La mia distribuzione CloudFormation dello stack non è riuscita o è stata ripristinata. Cosa posso fare per risolvere il problema?](#troubleshooting-blueprints-deployment)
+ [Non voglio che la mia applicazione inizi a leggere i messaggi dall'inizio degli argomenti di Amazon MSK. Cosa devo fare?](#troubleshooting-blueprints-beginning)
+ [Come faccio a sapere se c'è un problema con la mia applicazione Managed Service for Apache Flink e come posso eseguirne il debug?](#troubleshooting-blueprints-debug)
+ [Quali sono le metriche chiave che devo monitorare per la mia applicazione Managed Service for Apache Flink?](#troubleshooting-blueprints-metrics)
## La mia distribuzione CloudFormation dello stack non è riuscita o è stata ripristinata. Cosa posso fare per risolvere il problema?
+ Vai al tuo stack CFN e trova il motivo dell'errore dello stack. Potrebbe essere correlato alla mancanza di autorizzazioni, alle collisioni tra i nomi AWS delle risorse, tra le altre cause. Risolvi la causa principale dell'errore di distribuzione. Per ulteriori informazioni, consulta la [guida alla CloudWatch risoluzione dei problemi](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#basic-ts-guide).
+ [Facoltativo] Può esserci un solo endpoint VPC per servizio per VPC. Se hai distribuito più blueprint di incorporamento vettoriale in tempo reale per scrivere nelle raccolte di Amazon OpenSearch Service nello stesso VPC, è possibile che condividano gli endpoint VPC. Questi potrebbero essere già presenti nel tuo account per il VPC oppure il primo stack di blueprint di incorporamento vettoriale in tempo reale creerà endpoint VPC per Amazon Bedrock e Amazon OpenSearch Service che verranno utilizzati da tutti gli altri stack distribuiti nel tuo account. Se uno stack fallisce, controlla se quello stack ha creato endpoint VPC per Amazon Bedrock e Amazon OpenSearch Service ed eliminali se non vengono utilizzati in nessun'altra parte del tuo account. Per i passaggi per eliminare gli endpoint VPC, consulta la documentazione su come eliminare l'applicazione in modo sicuro.
+ Potrebbero esserci altri servizi o applicazioni nel tuo account che utilizzano l'endpoint VPC. La sua eliminazione potrebbe causare interruzioni della rete per altri servizi. Fai attenzione nell'eliminare questi endpoint.
## Non voglio che la mia applicazione inizi a leggere i messaggi dall'inizio degli argomenti di Amazon MSK. Cosa devo fare?
È necessario impostare `source.msk.starting.offset` esplicitamente uno dei seguenti valori, a seconda del comportamento desiderato:
+ **Offset più** antico: l'offset più vecchio nella partizione.
+ **Ultimo offset**: i consumatori leggeranno i messaggi dalla fine della partizione.
+ **Offset confermato**: legge l'ultimo messaggio che il consumatore ha elaborato all'interno di una partizione.
## Come faccio a sapere se c'è un problema con la mia applicazione Managed Service for Apache Flink e come posso eseguirne il debug?
Utilizza la [guida alla risoluzione dei problemi relativi a Managed Service for Apache Flink per eseguire il debug dei problemi relativi](https://docs.aws.amazon.com/managed-flink/latest/java/troubleshooting-runtime.html) a Managed Service for Apache Flink con la tua applicazione.
## Quali sono le metriche chiave che devo monitorare per la mia applicazione Managed Service for Apache Flink?
+ Tutte le metriche disponibili per una normale applicazione Managed Service for Apache Flink possono aiutarti a monitorare la tua applicazione. Per ulteriori informazioni, consulta [Metriche e dimensioni in Managed Service](https://docs.aws.amazon.com/managed-flink/latest/java/metrics-dimensions.html) for Apache Flink.
+ Per monitorare i parametri di Amazon Bedrock, consulta i parametri Amazon [ CloudWatch per Amazon](https://docs.aws.amazon.com/bedrock/latest/userguide/monitoring.html#runtime-cloudwatch-metrics) Bedrock.
+ Abbiamo aggiunto due nuove metriche per il monitoraggio delle prestazioni di generazione di incorporamenti. Li trovi sotto il nome dell'`EmbeddingGeneration`operazione in. CloudWatch Le due metriche sono:
+ **BedrockTitanEmbeddingTokenCount**: numero di token presenti in una singola richiesta ad Amazon Bedrock.
+ **BedrockEmbeddingGenerationLatencyMs**: riporta il tempo impiegato per inviare e ricevere una risposta da Amazon Bedrock per la generazione di incorporamenti, in millisecondi.
+ Per le raccolte serverless di Amazon OpenSearch Service, puoi utilizzare metriche come `IngestionDocumentErrors` e `IngestionDataRate` altre. Per ulteriori informazioni, consulta [Monitoring OpenSearch Serverless with Amazon CloudWatch](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/monitoring-cloudwatch.html).
+ Per i OpenSearch parametri assegnati, consulta [Monitoraggio dei parametri OpenSearch del cluster con Amazon](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/managedomains-cloudwatchmetrics.html). CloudWatch
# Risoluzione dei problemi di runtime
Questa sezione contiene informazioni sulla diagnosi e la risoluzione dei problemi di runtime relativi al servizio gestito per l'applicazione Apache Flink.
**Topics**
+ [Strumenti per la risoluzione dei problemi](#troubleshooting-tools)
+ [Problemi relativi all'applicazione](troubleshooting-symptoms.md)
+ [L'applicazione si sta riavviando](troubleshooting-rt-restarts.md)
+ [La velocità effettiva è troppo lenta](troubleshooting-rt-throughput.md)
+ [Crescita statale illimitata](troubleshooting-rt-stateleaks.md)
+ [Operatori vincolati all'I/O](troubleshooting-io-bound-operators.md)
+ [Limitazione della larghezza di banda della rete in upstream o all'origine da un flusso di dati Kinesis](troubleshooting-source-throttling.md)
+ [Checkpoint](troubleshooting-checkpoints.md)
+ [Il checkpoint è in fase di interruzione](troubleshooting-chk-timeout.md)
+ [Errorei del checkpoint per l'applicazione Apache Beam](troubleshooting-chk-failure-beam.md)
+ [Contropressione](troubleshooting-backpressure.md)
+ [Disallineamento dei dati](troubleshooting-data-skew.md)
+ [Disallineamento dello stato](troubleshooting-state-skew.md)
+ [Integrazione con risorse di diverse regioni](troubleshooting-resources-in-different-regions.md)
## Strumenti per la risoluzione dei problemi
Lo strumento principale per rilevare i problemi delle applicazioni sono gli CloudWatch allarmi. Utilizzando gli CloudWatch allarmi, è possibile impostare soglie per le CloudWatch metriche che indicano condizioni di errore o di collo di bottiglia nell'applicazione. Per informazioni sugli allarmi consigliati, consulta. CloudWatch [Usa gli CloudWatch allarmi con Amazon Managed Service per Apache Flink](monitoring-metrics-alarms.md)
# Problemi relativi all'applicazione
Questa sezione contiene soluzioni per le situazioni di errore che possono verificarsi con il servizio gestito per l'applicazione Apache Flink.
**Topics**
+ [L'applicazione è bloccata in uno stato transitorio](#troubleshooting-rt-stuck)
+ [La creazione di istantanee non riesce](#troubleshooting-rt-snapshots)
+ [Impossibile accedere alle risorse in un VPC](#troubleshooting-rt-vpc)
+ [I dati vengono persi durante la scrittura su un bucket Amazon S3](#troubleshooting-rt-s3)
+ [L'applicazione è nello stato RUNNING ma non sta elaborando dati](#troubleshooting-rt-processing)
+ [Istantanea, aggiornamento dell'applicazione o errore di interruzione dell'applicazione: InvalidApplicationConfigurationException](#troubleshooting-rt-appconfigexception)
+ [java.nio.file. NoSuchFileException:/usr/local/openjdk-8/lib/security/cacerts](#troubleshooting-rt-fnf)
## L'applicazione è bloccata in uno stato transitorio
Se l'applicazione rimane in uno stato transitorio (`STARTING`,,`UPDATING`, o`AUTOSCALING`)`STOPPING`, è possibile interromperla utilizzando l'[StopApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_StopApplication.html)azione con il `Force` parametro impostato su. `true` Non è possibile forzare l'interruzione di un'applicazione che si trovi nello stato `DELETING`. In alternativa, se l'applicazione si trova nello stato `UPDATING` o `AUTOSCALING`, è possibile ripristinarla alla versione precedente. Quando si esegue il rollback di un'applicazione, vengono caricati i dati sullo stato dell'ultimo snapshot scattato con successo. Se l'applicazione non dispone di snapshot, il servizio gestito per Apache Flink rifiuta la richiesta di ripristino. Per ulteriori informazioni sul rollback di un'applicazione, vedi [RollbackApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_RollbackApplication.html)azione.
**Nota**
L'arresto forzato dell'applicazione può causare la perdita o la duplicazione dei dati. Consigliamo di scattare snapshot con frequenza, per evitare di perdere o duplicare i dati mentre l'applicazione viene riavviata.
Le applicazioni possono bloccarsi a causa delle seguenti ragioni:
+ **Dimensioni eccessive dello stato dell'applicazione:** se lo stato dell'applicazione è troppo grande o troppo ingombrante può causare il blocco dell'applicazione durante un'operazione di checkpoint o di snapshot. Controlla le metriche `lastCheckpointDuration` e `lastCheckpointSize` dell'applicazione, alla ricerca di valori in costante aumento o eccessivamente alti.
+ **Il codice dell'applicazione è troppo pesante:** verifica che il file JAR dell'applicazione non superi 512 MB. I file JAR di dimensioni superiori a 512 MB non sono supportati.
+ **Generazione di snapshot nell'applicazione non riuscita:** il servizio gestito per Apache Flink scatta uno snapshot dell'applicazione nel corso di una richiesta [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) o [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). In seguito, il servizio utilizza lo stato di snapshot e ripristina l'applicazione utilizzandone la configurazione aggiornata per fornire semantiche di elaborazione *exactly-once*. Se la creazione automatica di snapshot non riesce, consulta quanto [La creazione di istantanee non riesce](#troubleshooting-rt-snapshots) segue:
+ **Ripristino da uno snapshot non riuscito:** rimuovendo o modificando un operatore in un aggiornamento dell'applicazione e tentando il ripristino da uno snapshot, quest'ultimo avrà esito negativo per impostazione predefinita se l'istantanea contiene dati sullo stato dell'operatore mancante. Inoltre, l'applicazione rimarrà bloccata nello status `STOPPED` o `UPDATING`. Per modificare questo comportamento e consentire il corretto ripristino, modifica il *AllowNonRestoredState*parametro dell'applicazione [FlinkRunConfiguration](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_FlinkRunConfiguration.html)in`true`. Ciò consentirà all'operazione di ripristino di ignorare i dati sullo stato che non possono essere mappati al nuovo programma.
+ **L'inizializzazione dell'applicazione richiede più tempo:** servizio gestito per Apache Flink utilizza un timeout interno di 5 minuti (impostazione graduale) mentre attende l'avvio di un processo Flink. Se il processo non viene avviato entro questo timeout, verrà visualizzato un CloudWatch registro come segue:
```
Flink job did not start within a total timeout of 5 minutes for application: %s under account: %s
```
l'errore precedentemente descritto si verifica quando le operazioni definite nel metodo `main` del processo Flink impiegano più di 5 minuti, causando il timeout della creazione del processo Flink sul servizio gestito per Apache Flink. Ti consigliamo di controllare **JobManager**i log di Flink e il codice dell'applicazione per vedere se questo ritardo nel `main` metodo è previsto. In caso contrario, è necessario adottare misure per risolvere il problema, in modo che il procedimento richieda meno di 5 minuti.
Per controllare lo status dell'applicazione è sufficiente utilizzare le azioni [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) o [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).
## La creazione di istantanee non riesce
Il servizio gestito per Apache Flink non può scattare uno snapshot nelle seguenti circostanze:
+ l'applicazione ha superato il limite di snapshot; il limite è di mille unità. Per ulteriori informazioni, consulta [Gestisci i backup delle applicazioni utilizzando le istantanee](how-snapshots.md).
+ L'applicazione non dispone delle autorizzazioni per accedere alla fonte o al sink.
+ Il codice dell'applicazione non funziona correttamente.
+ L'applicazione presenta altri problemi di configurazione.
Se si verifica un'eccezione durante l'acquisizione di uno snapshot durante l'aggiornamento o l'arresto di un'applicazione, imposta la proprietà `SnapshotsEnabled` del [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) dell'applicazione su `false` e prova a eseguire nuovamente la richiesta.
Gli snapshot possono non andare a buon fine se gli operatori dell'applicazione non sono allocati correttamente. Per informazioni sull'ottimizzazione delle prestazioni degli operatori, consulta [Dimensionamento degli operatori](performance-improving.md#performance-improving-scaling-op).
Dopo che l'applicazione è tornata a uno stato integro, si consiglia di impostare la proprietà `SnapshotsEnabled` dell'applicazione su `true`.
## Impossibile accedere alle risorse in un VPC
Se l'applicazione utilizza un VPC in esecuzione su Amazon VPC, è possibile verificare che l'applicazione riesca ad accedere alle proprie risorse eseguendo i passaggi seguenti:
+ Controlla i CloudWatch log per verificare la presenza del seguente errore. Questo errore indica che l'applicazione non riesce ad accedere alle risorse nel VPC:
```
org.apache.kafka.common.errors.TimeoutException: Failed to update metadata after 60000 ms.
```
Se visualizzi questo errore, verifica che le tabelle di routing siano configurate correttamente e le impostazioni di connessione dei connettori siano corrette.
Per informazioni sulla configurazione e l'analisi dei CloudWatch log, consulta. [Registrazione e monitoraggio in Amazon Managed Service per Apache Flink](monitoring-overview.md)
## I dati vengono persi durante la scrittura su un bucket Amazon S3
Potrebbe verificarsi una perdita di dati nel corso della scrittura dell'output su un bucket Amazon S3 utilizzando la versione 1.6.2 di Apache Flink. Quando si usa Amazon S3 per l'output diretto è consigliabile utilizzare l'ultima versione supportata di Apache Flink. Per scrivere su un bucket Amazon S3 utilizzando Apache Flink 1.6.2, consigliamo di utilizzare Firehose. Per ulteriori informazioni sull'utilizzo di Firehose with Managed Service for Apache Flink, vedere. [Lavello Firehose](earlier.md#get-started-exercise-fh)
## L'applicazione è nello stato RUNNING ma non sta elaborando dati
È possibile controllare lo stato dell'applicazione utilizzando le azioni [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) o [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). Se la tua applicazione entra nello `RUNNING` stato ma non sta scrivendo dati sul tuo sink, puoi risolvere il problema aggiungendo un flusso di CloudWatch log Amazon alla tua applicazione. Per ulteriori informazioni, consulta [Utilizzate le opzioni di CloudWatch registrazione delle applicazioni](cloudwatch-logs.md#adding_cloudwatch). Il flusso di log contiene messaggi che consentono di risolvere eventuali problemi relativi alle applicazioni.
## Istantanea, aggiornamento dell'applicazione o errore di interruzione dell'applicazione: InvalidApplicationConfigurationException
Un errore di questo tipo potrebbe verificarsi nel corso di uno snapshot o un'operazione che ne crea uno, come l'aggiornamento o l'arresto di un'applicazione:
```
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
```
tale errore ha luogo, quindi, quando l'applicazione non è in grado di creare uno snapshot.
Ecco come procedere se l'errore si verifica mentre scatti uno snapshot o svolgi un'operazione che ne crea uno:
+ disattiva gli snapshot per l'applicazione; È possibile eseguire questa operazione nella console Managed Service for Apache Flink o utilizzando il `SnapshotsEnabledUpdate` parametro dell'azione. [UpdateApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_UpdateApplication.html)
+ prova a comprendere perché è impossibile creare gli snapshot; Per ulteriori informazioni, consulta [L'applicazione è bloccata in uno stato transitorio](#troubleshooting-rt-stuck).
+ Quando l'applicazione torna a funzionare sarà possibile riattivare gli snapshot.
## java.nio.file. NoSuchFileException:/usr/local/openjdk-8/lib/security/cacerts
La posizione del truststore SSL è stata aggiornata in una precedente implementazione. Per il parametro `ssl.truststore.location` sono invece da prediligere i seguenti parametri:
```
/usr/lib/jvm/java-11-amazon-corretto/lib/security/cacerts
```
# L'applicazione si sta riavviando
Se l'applicazione non è integra, il processo Apache Flink non riesce e si riavvia continuamente. Questa sezione descrive i sintomi e le procedure di risoluzione dei problemi relativi a questa condizione.
## Caratteristiche
Questa condizione può avere i seguenti sintomi:
+ La metrica `FullRestarts` non è zero. Questa metrica rappresenta il numero di volte in cui il lavoro dell'applicazione è stato riavviato dall'avvio dell'applicazione.
+ La metrica `Downtime` non è zero. Questa metrica rappresenta il numero di millisecondi in cui l'applicazione si trova nello stato `FAILING` o `RESTARTING`.
+ Il log dell'applicazione contiene le modifiche allo stato `RESTARTING` o `FAILED`. È possibile interrogare il registro dell'applicazione per queste modifiche di stato utilizzando la seguente query CloudWatch Logs Insights:. [Analizza gli errori: errori relativi alle attività dell'applicazione](cloudwatch-logs-reading.md#cloudwatch-logs-reading-apps)
## Cause e soluzioni
Le seguenti condizioni possono causare l'instabilità e il riavvio ripetuto dell'applicazione:
+ **L'operatore genera un'eccezione:** se un'eccezione in un operatore dell'applicazione non viene gestita, l'applicazione fallisce (interpretando che l'errore non può essere gestito dall'operatore). L'applicazione si riavvia dal checkpoint più recente per mantenere la semantica di elaborazione singola. Di conseguenza, `Downtime` non è zero durante questi periodi di riavvio. Per evitare che ciò accada, si consiglia di gestire eventuali eccezioni riutilizzabili nel codice dell'applicazione.
È possibile esaminare le cause di questa condizione interrogando i log dell'applicazione per verificare eventuali modifiche allo stato dell'applicazione da `RUNNING` a `FAILED`. Per ulteriori informazioni, consulta [Analizza gli errori: errori relativi alle attività dell'applicazione](cloudwatch-logs-reading.md#cloudwatch-logs-reading-apps).
+ Il **provisioning dei flussi di dati Kinesis non è corretto:** se una fonte o un sink per l'applicazione è un flusso di dati Kinesis, controlla le [metriche relative](https://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.html) allo stream per verificare la presenza di errori. `ReadProvisionedThroughputExceeded` `WriteProvisionedThroughputExceeded`
Se visualizzi questi errori, puoi aumentare il throughput disponibile per il flusso Kinesis aumentando il numero di partizioni del flusso. Per ulteriori informazioni, consulta [Come posso modificare il numero di partizioni aperte nei flussi di dati Kinesis?](https://aws.amazon.com/premiumsupport/knowledge-center/kinesis-data-streams-open-shards/)
+ **Altre origini o sink non vengono forniti correttamente o non sono disponibili:** verifica che l'applicazione stia fornendo correttamente origini e sink. Verifica che tutte le fonti o i sink utilizzati nell'applicazione (come altri AWS servizi o fonti o destinazioni esterne) siano ben forniti, che non siano soggetti a limitazioni di lettura o scrittura o che non siano periodicamente non disponibili.
Se riscontri problemi relativi al throughput con i servizi dipendenti, aumenta le risorse disponibili per tali servizi o investiga la causa di eventuali errori o indisponibilità.
+ **Gli operatori non vengono forniti correttamente:** se il carico di lavoro sui thread di uno degli operatori dell'applicazione non è distribuito correttamente, l'operatore può sovraccaricarsi e l'applicazione può arrestarsi in modo anomalo. Per informazioni sulla regolazione del parallelismo degli operatori, consulta [Gestire correttamente il dimensionamento degli operatori](performance-improving.md#performance-improving-scaling-op).
+ **L'applicazione fallisce con DaemonException:** questo errore viene visualizzato nel registro dell'applicazione se si utilizza una versione di Apache Flink precedente alla 1.11. Potrebbe essere necessario eseguire l'aggiornamento a una versione successiva di Apache Flink in modo da utilizzare una versione KPL 0.14 o successiva.
+ **L'applicazione fallisce con TimeoutException FlinkException, o RemoteTransportException:** Questi errori possono comparire nel registro dell'applicazione se i task manager si bloccano. Se l'applicazione è sovraccarica, i task manager possono subire un carico eccessivo sulla CPU o sulle risorse di memoria, con conseguenti errori.
Questi errori possono essere simili ai seguenti:
+ `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`
Per risolvere questa condizione, verifica quanto segue:
+ Controlla le tue CloudWatch metriche per rilevare picchi insoliti nell'utilizzo della CPU o della memoria.
+ Controlla se l'applicazione presenta problemi di throughput. Per ulteriori informazioni, consulta [Risolvi i problemi relativi alle prestazioni](performance-troubleshooting.md).
+ Esamina il log dell'applicazione per individuare eventuali eccezioni non gestite che il codice della tua applicazione sta generando.
+ **L'applicazione fallisce con l'errore JaxbAnnotationModule Not Found:** questo errore si verifica se l'applicazione utilizza Apache Beam, ma non ha le dipendenze o le versioni di dipendenza corrette. Le applicazioni del servizio gestito Apache Flink che utilizzano Apache Beam devoni utilizzare le seguenti versioni delle dipendenze:
```
2.10.2
...
com.fasterxml.jackson.module
jackson-module-jaxb-annotations
2.10.2
```
Se non fornisci la versione corretta di `jackson-module-jaxb-annotations` come dipendenza esplicita, l'applicazione la carica dalle dipendenze dell'ambiente e, poiché le versioni non corrispondono, l'applicazione si blocca in fase di runtime.
Per maggiori informazioni sull'utilizzo di Apache Beam con il servizio gestito per Apache Flink, consulta [Usa CloudFormationCreazione di un'applicazione utilizzando Apache Beam](examples-beam.md).
+ **L'applicazione fallisce con java.io. IOException: numero insufficiente di buffer di rete**
Ciò accade quando un'applicazione non dispone di memoria sufficiente per i buffer di rete. I buffer di rete facilitano la comunicazione tra le sottoattività. Vengono utilizzati per archiviare i record prima della trasmissione su una rete e per archiviare i dati in entrata prima di suddividerli in record e consegnarli a sottoattività. Il numero di buffer di rete richiesti varia direttamente in base al parallelismo e alla complessità del grafico di processo. Esistono diversi approcci per mitigare questo problema:
+ È possibile configurarne un `parallelismPerKpu` più basso in modo da aumentare le memoria allocata per sottoattività e buffer di rete. Tieni presente che una riduzione `parallelismPerKpu` aumenterà la KPU e quindi i costi. Per evitare ciò, puoi mantenere la stessa quantità di KPU riducendo il parallelismo per uno stesso fattore.
+ È possibile semplificare il grafico di processo riducendo il numero di operatori o concatenandoli in modo da ridurre il numero di buffer necessari.
+ Altrimenti, puoi contattare https://aws.amazon.com/premiumsupport/ per una configurazione personalizzata del buffer di rete.
# La velocità effettiva è troppo lenta
Se l'applicazione non elabora i dati di streaming in entrata abbastanza velocemente, le prestazioni non saranno ottimali e l'applicazione poco stabile. Questa sezione descrive le caratteristiche e le procedure di risoluzione dei problemi relativi a questa problematica.
## Caratteristiche
Questa situazione può presentare i seguenti sintomi:
+ Se l'origine dati per l'applicazione è un flusso Kinesis, la metrica `millisbehindLatest` del flusso aumenta in maniera continua.
+ Se l'origine dati per l'applicazione è un cluster Amazon MSK, le metriche del cluster relative al ritardo per l'utente aumentano in modo continuo. Per ulteriori informazioni, è possibile consultare [Monitoraggio del ritardo per l'utente](https://docs.aws.amazon.com/msk/latest/developerguide/consumer-lag.html) nella [Guida per gli sviluppatori Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html).
+ Se l'origine dati per l'applicazione è un servizio o una fonte diversa, è consigliabile controllare le metriche o i dati disponibili in materia di ritardi per l'utente.
## Cause e soluzioni
Le cause del rallentamento della velocità di trasmissione effettiva delle applicazioni possono essere molteplici. Se l'applicazione non riesce ad adeguarsi agli input, verifica gli aspetti seguenti:
+ Se il ritardo nella velocità di trasmissione effettiva aumenta e poi si riduce, controlla se l'applicazione è in fase di riavvio. L'applicazione interromperà l'elaborazione dell'input durante il riavvio, causando un aumento dei ritardi. Per ulteriori informazioni sugli errori all'interno dell'applicazione, consulta [L'applicazione si sta riavviando](troubleshooting-rt-restarts.md).
+ Se il ritardo nella velocità di trasmissione effettiva è costante, verifica che le prestazioni dell'applicazione siano ottimizzate. Per informazioni sull'ottimizzazione delle prestazioni dell'applicazione, consulta [Risolvi i problemi relativi alle prestazioni](performance-troubleshooting.md).
+ Se il ritardo nella velocità di trasmissione effettiva aumenta in maniera costante ma non improvvisa e le prestazioni dell'applicazione sono ottimizzate, è necessario potenziare le risorse dell'applicazione. Per informazioni sull'aumento delle risorse dell'applicazione, consulta [Implementa la scalabilità delle applicazioni](how-scaling.md).
+ Se l'applicazione legge da un cluster Kafka in un'altra regione e `FlinkKafkaConsumer` e `KafkaSource` sono per lo più inattivi (livelli alti di `idleTimeMsPerSecond` o bassi di `CPUUtilization`) nonostante il forte ritardo per l'utente, è possibile aumentare il valore di `receive.buffer.byte`, per esempio 2097152. Per ulteriori informazioni consigliamo di consultare la sezione Ambiente ad alta latenza nelle [configurazioni MSK personalizzate](https://docs.aws.amazon.com/msk/latest/developerguide/msk-configuration-properties.html).
Per le procedure di risoluzione dei problemi relativi a rallentamenti nella velocità di trasmissione effettiva o all'aumento del ritardo per l'utente nell'origine dell'applicazione, consulta [Risolvi i problemi relativi alle prestazioni](performance-troubleshooting.md).
# Crescita statale illimitata
Se l'applicazione non elimina correttamente le informazioni obsolete sullo stato, tali informazioni accumuleranno continuamente e causeranno problemi di prestazioni o stabilità delle applicazioni. Questa sezione descrive i sintomi e le procedure di risoluzione dei problemi relativi a questa condizione.
## Caratteristiche
Questa condizione può avere i seguenti sintomi:
+ La metrica `lastCheckpointDuration` sta aumentando gradualmente o mostra un picco.
+ La metrica `lastCheckpointSize` sta aumentando gradualmente o mostra un picco.
## Cause e soluzioni
Le seguenti condizioni possono causare l'accumulo di dati sullo stato dell'applicazione:
+ L'applicazione mantiene i dati sullo stato più a lungo del necessario.
+ L'applicazione utilizza query a finestra con una durata troppo lunga.
+ Non hai impostato il TTL per i tuoi dati di stato. Per ulteriori informazioni, consulta [State Time-To-Live (TTL) nella documentazione](https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/dev/datastream/fault-tolerance/state/#state-time-to-live-ttl) di Apache Flink.
+ Stai eseguendo un'applicazione che dipende dalla versione 2.25.0 o successiva di Apache Beam. Puoi disattivare la nuova versione della trasformazione di lettura [estendendo i tuoi](https://docs.aws.amazon.com/managed-flink/latest/java/examples-beam.html#examples-beam-configure) esperimenti e il BeamApplicationProperties valore chiave. `use_deprecated_read` Per ulteriori informazioni, consulta la [documentazione di Apache Beam](https://beam.apache.org/blog/beam-2.25.0/#highlights).
A volte le applicazioni devono far fronte a una crescita continua delle dimensioni degli stati, il che non è sostenibile a lungo termine (dopotutto un'applicazione Flink viene eseguita indefinitamente). A volte, ciò può essere ricondotto al fatto che le applicazioni archiviano i dati in uno stato indeterminato e non eseguono correttamente il processo di invecchiamento delle vecchie informazioni. Ma altre volte ci sono solo aspettative irragionevoli su ciò che Flink può offrire. Le applicazioni possono utilizzare aggregazioni su ampie finestre temporali, che coprono giorni o addirittura settimane. A meno che non [AggregateFunctions](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/windows/#aggregatefunction)vengano utilizzati, che consentono aggregazioni incrementali, Flink deve mantenere invariati gli eventi dell'intera finestra.
Inoltre, quando si utilizzano funzioni di processo per implementare operatori personalizzati, l'applicazione deve rimuovere dallo stato i dati che non sono più necessari per la logica di business. In tal caso, [lo stato time-to-live](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/fault-tolerance/state/#state-time-to-live-ttl) può essere utilizzato per invecchiare automaticamente i dati in base al tempo di elaborazione. Il servizio gestito per Apache Flink utilizza checkpoint incrementali e quindi il TTL dello stato si basa sulla [compattazione RocksDB.](https://github.com/facebook/rocksdb/wiki/Compaction) È possibile osservare una riduzione effettiva delle dimensioni dello stato (indicata dalla dimensione del checkpoint) solo in seguito a un'operazione di compattazione. In particolare per i checkpoint di dimensioni inferiori a 200 MB, è improbabile che si verifichi una riduzione delle dimensioni dei checkpoint a causa della scadenza dello stato. Tuttavia, i savepoint si basano su una copia pulita dello stato che non contiene dati obsoleti, quindi è possibile attivare uno snapshot nel servizio gestito per Apache Flink per forzare la rimozione dello stato obsoleto.
A scopo di debug, può essere utile disabilitare i checkpoint incrementali per verificare più rapidamente che la dimensione del checkpoint diminuisca o si stabilizzi (ed evitare l'effetto della compattazione in RocksBS). Tuttavia, per farlo occorre inoltrare un ticket al team di assistenza.
# Operatori vincolati all'I/O
È meglio evitare dipendenze da sistemi esterni sul percorso dei dati. Spesso è molto più efficace mantenere invariato un set di dati di riferimento piuttosto che effettuare query verso un sistema esterno per arricchire singoli eventi. Tuttavia, a volte ci sono dipendenze che non possono essere facilmente trasferite allo stato, ad esempio se si desidera arricchire gli eventi con un modello di machine learning hostato su Amazon Sagemaker.
Gli operatori che si interfacciano con sistemi esterni tramite la rete possono diventare un collo di bottiglia e generare una congestione. Si consiglia vivamente di utilizzare [AsyncIO](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/asyncio/) per implementare la funzionalità, ridurre i tempi di attesa delle singole chiamate ed evitare il rallentamento dell'intera applicazione.
Inoltre, per le applicazioni con operatori I/O associati può essere utile aumentare l'impostazione [ParallelismPerKPU](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_ParallelismConfiguration.html) dell'applicazione Managed Service for Apache Flink. Questa configurazione descrive il numero di sottoattività parallele che un'applicazione è in grado di eseguire per ogni KPU (Kinesis Processing Unit). Aumentando il valore dal valore predefinito di 1 a, ad esempio, 4, l'applicazione sfrutta le stesse risorse (e ha lo stesso costo) ma può dimensionare a fino a 4 volte il parallelismo. Funziona bene per le applicazioni I/O associate, ma causa un sovraccarico aggiuntivo per le applicazioni che non lo sono. I/O
# Limitazione della larghezza di banda della rete in upstream o all'origine da un flusso di dati Kinesis
**Sintomo**: l'applicazione riscontra `LimitExceededExceptions` dal suo flusso di dati Kinesis di origine in upstream.
**Causa potenziale**: l'impostazione predefinita per il connettore Kinesis della libreria di Apache Flink per la lettura dall'origine del flusso di dati Kinesis è configurata su un'impostazione predefinita molto aggressiva per il numero massimo di record recuperati per chiamata `GetRecords`. Apache Flink è configurato per impostazione predefinita per recuperare 10.000 record per `GetRecords` chiamata (questa chiamata viene effettuata di default ogni 200 ms), sebbene il limite per shard sia di soli 1.000 record.
Questo comportamento predefinito può portare a una limitazione della larghezza di banda della rete quando si tenta di utilizzare dati dal flusso di dati Kinesis, il che influisce sulle prestazioni e sulla stabilità dell'applicazione.
Puoi confermarlo controllando la CloudWatch `ReadProvisionedThroughputExceeded` metrica e visualizzando i periodi prolungati o sostenuti in cui questa metrica è maggiore di zero.
Puoi anche visualizzarlo nei CloudWatch log della tua applicazione Amazon Managed Service for Apache Flink osservando gli errori continui. `LimitExceededException`
**Risoluzione**: puoi fare una delle due cose per risolvere questo scenario:
+ Ridurre il limite predefinito per il numero di record recuperati per chiamata `GetRecords`
+ Abilita Adaptive Reads nella tua applicazione Amazon Managed Service for Apache Flink. Per ulteriori informazioni sulla funzionalità Adaptive Reads, consultare [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)
# Checkpoint
I checkpoint rappresentano il meccanismo di Flink per garantire che lo stato di un'applicazione sia in grado di tollerare eventuali errori. Questo meccanismo consente a Flink di ripristinare lo stato degli operatori in caso di errori del processo, nonché di fornire all'applicazione le semantiche di un'esecuzione senza errori. Con Managed Service for Apache Flink, lo stato di un'applicazione viene archiviato in RockSDB, un key/value archivio integrato che mantiene lo stato di funzionamento su disco. Quando viene eseguito un checkpoint, lo stato viene caricato anche su Amazon S3: anche se il disco viene perso, pertanto, il checkpoint può essere utilizzato per ripristinare lo stato delle applicazioni.
Per ulteriori informazioni consulta la sezione [Come funzionano gli snapshot dello stato?](https://nightlies.apache.org/flink/flink-docs-master/docs/learn-flink/fault_tolerance/#how-does-state-snapshotting-work).
## Fasi di checkpoint
Le fasi principali di un'attività secondaria per effettuare il checkpoint di un operatore in Flink sono 5:
+ In attesa [**Ritardo di avvio**]: Flink utilizza le barriere di checkpoint inserite nel flusso: in questa fase, pertanto, il tempo è il periodo di attesa dell'operatore prima che la barriera del checkpoint lo raggiunga.
+ Allineamento [**Durata dell'allineamento**]: in questa fase l'attività secondaria ha raggiunto una barriera ma è in attesa delle barriere provenienti da altri flussi di input.
+ Sincronizzazione del checkpoint [**Durata della sincronizzazione**]: in questa fase l'attività secondaria effetto uno snapshot dello stato dell'operatore e blocca tutte le altre attività presenti sulla'attività secondaria.
+ Checkpoint asincrono [**Durata asincrona**]: questa fase consiste in gran parte caricamento dello stato su Amazon S3 da parte dell'attività secondaria. Durante questa fase, l'attività secondaria non è più bloccata e può elaborare i record.
+ Riconoscimento: di solito si tratta di una fase breve e consiste semplicemente nell'invio di un riconoscimento e nell'esecuzione di eventuali messaggi di commit (ad esempio con i JobManager sinks di Kafka).
Ciascuna di queste fasi (esclusa Riconoscimento) corrisponde a un parametro di durata per i checkpoint disponibile nell'interfaccia utente Web di Flink, che può aiutare a individuare la causa del prolungamento delle tempistiche del checkpoint.
Per vedere la definizione esatta di ciascuna delle metriche disponibili sui checkpoint, visita la scheda [Cronologia](https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/monitoring/checkpoint_monitoring/#history-tab).
## Analisi
Quando si esamina la durata prolungata di un checkpoint, l'elemento più importante da determinare è il collo di bottiglia del checkpoint, vale a dire quale operatore e attività secondaria impiega la quantità maggiore di tempo ad arrivare al checkpoint e quale fase di tale attività secondaria richiede un periodo di tempo prolungato. Può essere determinato utilizzando l'interfaccia utente Web di Flink nell'attività di checkpoint dei processi. L'interfaccia web di Flink fornisce dati e informazioni che aiutano a risolvere le problematiche relative ai checkpoint. Per un'analisi completa, consulta [Monitoraggio dei checkpoint](https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/monitoring/checkpoint_monitoring/).
Per determinare quale operatore richiede una quantità di tempo prolungata per arrivare al checkpoint e merita approfondimenti, il primo elemento da esaminare è la **durata end-to-end** di ogni operatore nel grafico del processo. Conformemente alla documentazione di Flink, la definizione della durata è:
*La durata dal timestamp del trigger fino all'ultima conferma (o se non è ancora stata ricevuta alcuna conferma). n/a La durata end-to-end di un checkpoint completo è determinata dall'ultima attività secondaria che riconosce il checkpoint. Tale periodo è generalmente superiore a quello di cui le attività secondarie necessitano per effettuare la verifica dello stato.*
Le diverse durate della verifica forniscono inoltre informazioni più dettagliate relativamente agli aspetti che richiedono più tempo.
Una **durata della sincronizzazione** elevata indica problematiche nel corso dello scatto dello snapshot. In questa fase `snapshotState()` è attivato per le classi che implementano l'interfaccia snapshotState; può trattarsi di codice utente, quindi i thread dump possono essere utili per indagare su questo aspetto.
Una **durata asincrona** prolungata suggerirebbe che il caricamento dello stato su Amazon S3 richiede una quantità di tempo prolungata. Ciò può verificarsi se le dimensioni dello stato sono importanti o se vengono caricati diversi file di stato. In tal caso, è consigliabile analizzare l'utilizzo dello stato da parte dall'applicazione, nonché assicurarsi che, dove possibile, vengano utilizzate le strutture di dati native di Flink ([Utilizzare Keyed State](https://nightlies.apache.org/flink/flink-docs-master/docs/dev/datastream/fault-tolerance/state/#using-keyed-state)). Il servizio gestito per Apache Flink configura Flink in modo tale da ridurre al minimo il numero di chiamate Amazon S3, garantendone l'ottimizzazione. Di seguito è riportato un esempio di statistiche sulle verifiche di un operatore, che rivela quanto la **durata asincrona** sia relativamente lunga rispetto alle precedenti statistiche di verifica dell'operatore.
![\[Analisi delle verifiche\]](http://docs.aws.amazon.com/it_it/managed-flink/latest/java/images/checkpoint.png)
Un **ritardo di avvio** elevato indicherebbe che la maggior parte del tempo viene impiegata ad aspettare che la barriera del checkpoint raggiunga l'operatore. Ciò indica che l'applicazione impiega un periodo di tempo superiore per elaborare i record, il che significa che la barriera scorre lentamente attraverso il grafico del processo. Tale situazione si verficia se il processo è soggetto a contropressione o se uno o più operatori sono costantemente occupati. Di seguito è riportato un esempio di un caso in JobGraph cui il secondo operatore è occupato. KeyedProcess
![\[Analisi delle verifiche\]](http://docs.aws.amazon.com/it_it/managed-flink/latest/java/images/checkpoint2.png)
Puoi indagare su cosa sta impiegando così tanto tempo utilizzando Flink Flame Graphs o TaskManager i thread dump. Una volta identificata la problematica, è possibile analizzarla ulteriormente utilizzando i grafici a fiamma o i thread dump.
## Thread dump
I thread dump sono uno strumento di debug che si trova a un livello leggermente inferiore rispetto ai grafici a fiamma. Un thread dump restituisce lo stato di esecuzione di tutti i thread in un determinato momento. Flink esegue un thread dump JVM, ossia uno stato di esecuzione di tutti i thread all'interno del processo Flink. Lo stato di un thread è rappresentato da una traccia dello stack del thread, insieme ad alcune informazioni aggiuntive. I grafici a fiamma vengono creati utilizzando diverse stack trace in rapida successione. Il grafico è una visualizzazione composta dalle stack trace, che semplifica l'identificazione dei percorsi di codice comuni.
```
"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)
...
```
Qui sopra è riportato un frammento di un thread dump tratto dall'interfaccia utente di Flink per un singolo thread. La prima riga contiene alcune informazioni generali su questo thread, tra cui:
+ *Il nome KeyedProcess del thread (1/3) \$10*
+ *Priorità del thread prio=5*
+ *Un thread unico Id = 1423*
+ Stato del thread *ESEGUIBILE*
Il nome di un thread solitamente fornisce informazioni sul suo scopo generale. I thread degli operatori possono essere identificati dal loro nome poiché i thread dell'operatore hanno lo stesso nome dell'operatore, oltre all'indicazione della sottoattività a cui sono correlati, ad esempio, il thread *KeyedProcess (1/3) \$10* proviene dall'*KeyedProcess*operatore e proviene dalla prima sottoattività (su 3).
I thread possono trovarsi in uno dei seguenti stati:
+ NUOVO: il thread è stato creato ma non è ancora stato elaborato
+ ESEGUIBILE: il thread è in esecuzione sulla CPU
+ BLOCCATO: il thread è in attesa che un altro thread rilasci il blocco
+ IN ATTESA: il thread è in attesa e utilizza un metodo `wait()`, `join()` o `park()`
+ ATTESA\$1A TEMPO: il thread è in attesa con un metodo di sospensione, attesa, collegamento o prenotazione, ma con un tempo di attesa massimo.
**Nota**
La profondità massima di un singolo stacktrace nel thread dump su Flink 1.13 è limitata a 8.
**Nota**
I thread dump dovrebbero rappresentare l'ultima soluzione per il debug dei problemi relativi alle prestazioni in un'applicazione Flink, poiché possono essere complessi da leggere, richiedono l'acquisizione di più campioni e l'analisi manuale. Ove possibile, è preferibile utilizzare i grafici a fiamma.
### Thread dump su Flink
Su Flink è possibile eseguire un thread dump scegliendo l'opzione **Task Manager** nella barra di navigazione a sinistra dell'interfaccia utente di Flink, selezionando un determinato task manager e accedendo alla scheda **Thread dump**. Il thread dump può essere scaricato, copiato in un editor di testo (o in un analizzatore di thread dump) o analizzato direttamente all'interno della visualizzazione di testo nell'interfaccia utente Web di Flink; quest'ultima opzione, però, potrebbe risultare macchinosa.
Per determinare quale Task Manager utilizzare, è possibile utilizzare un thread dump della **TaskManagers**scheda quando si sceglie un particolare operatore. Ciò dimostra che l'operatore è in esecuzione su diverse attività secondarie di un operatore e può essere eseguito su diversi Task Manager.
![\[Utilizzo dei thread dump\]](http://docs.aws.amazon.com/it_it/managed-flink/latest/java/images/checkpoint4.png)
Il dump sarà composto da diverse stack trace. Quando si esamina il dump, tuttavia, i più importanti sono quelli relativi a un operatore. Possono essere individuati facilmente, poiché i thread degli operatori hanno lo stesso nome dell'operatore, oltre a un'indicazione dell'attività secondaria a cui sono legati. Ad esempio, la seguente traccia dello stack proviene dall'*KeyedProcess*operatore ed è la prima sottoattività.
```
"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)
...
```
Questo può creare confusione se ci sono più operatori con lo stesso nome, tuttavia per aggirare il problema è possibile rinominare gli operatori. Per esempio:
```
....
.process(new ExpensiveFunction).name("Expensive function")
```
## [Grafici a fiamma](https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/debugging/flame_graphs/)
I grafici a fiamma sono uno strumento per il debug che consente di visualizzare le stack trace del codice di destinazione, il che consente di identificare i percorsi di codice più frequenti. Vengono creati campionando più volte le stack trace. L'asse x di un grafico a fiamma mostra i diversi profili dello stack, mentre l'asse y mostra la profondità dello stack e ne richiama la stack trace. Un rettangolo in un grafico a fiamma rappresenta uno stack frame, mentre la larghezza di un riquadro mostra la frequenza con cui compare negli stack. Per ulteriori dettagli sui grafici a fiamma e su come usarli, consulta [Grafici a fiamma](https://www.brendangregg.com/flamegraphs.html).
In Flink, è possibile accedere al grafico a fiamma di un operatore tramite l'interfaccia utente Web selezionando un operatore e quindi scegliendo la scheda. **FlameGraph** Una volta raccolto un numero sufficiente di campioni, verrà visualizzato il grafico a fiamma. Di seguito è riportato il messaggio ProcessFunction che ha impiegato molto tempo FlameGraph per arrivare al checkpoint.
![\[Utilizzo dei Flame graph\]](http://docs.aws.amazon.com/it_it/managed-flink/latest/java/images/checkpoint3.png)
Questo è un grafico a fiamma molto semplice e mostra che tutto il tempo impiegato dalla CPU viene speso in un'unica occhiata all'interno `processElement` dell'operatore. ExpensiveFunction È inoltre possibile ottenere il numero di riga, per determinare la posizione esatta in cui avviene l'esecuzione del codice.
# Il checkpoint è in fase di interruzione
Se l'applicazione non è correttamente ottimizzata o predisposta, i checkpoint possono non riuscire. Questa sezione descrive le caratteristiche e le procedure di risoluzione dei problemi relativi alla problematica precedentemente analizzata.
## Caratteristiche
Se l'applicazione non riesce ad effettuare i checkpoint, `numberOfFailedCheckpoints` sarà maggiore di zero.
I checkpoint possono non riuscire a causa di errori diretti (per esempio errori delle applicazioni) o di errori temporanei (per esempio l'esaurirsi delle risorse dell'applicazione). Verifica i log e i parametri dell'applicazione, alla ricerca delle seguenti caratteristiche:
+ errori nel codice;
+ errori di accesso ai servizi dipendenti dell'applicazione;
+ errori nella serializzazione dei dati. Se il serializzatore predefinito non è in grado di serializzare i dati dell'applicazione, l'applicazione cesserà di funzionare. Per informazioni sull'utilizzo di un serializzatore personalizzato nell'applicazione, consulta [Tipi di dati e serializzazione](https://nightlies.apache.org/flink/flink-docs-release-1.19/docs/dev/datastream/fault-tolerance/serialization/types_serialization/) nella documentazione di Apache Flink.
+ errori relativi all'esaurimento della memoria;
+ picchi o aumenti costanti nelle seguenti metriche:
+ `heapMemoryUtilization`
+ `oldGenerationGCTime`
+ `oldGenerationGCCount`
+ `lastCheckpointSize`
+ `lastCheckpointDuration`
Per ulteriori informazioni sul monitoraggio dei checkpoint, consulta Monitoring Checkpointing nella documentazione di Apache [Flink](https://nightlies.apache.org/flink/flink-docs-release-1.19/docs/ops/monitoring/checkpoint_monitoring/).
## Cause e soluzioni
I messaggi di errore del log delle applicazioni mostrano la causa degli errori diretti. Gli errori temporanei possono essere provocati dalle seguenti cause:
+ Le KPU fornite dall'applicazione non sono sufficienti. Per ulteriori informazioni su come aumentarne la quantità, consulta [Implementa la scalabilità delle applicazioni](how-scaling.md).
+ La dimensione dello stato dell'applicazione è troppo grande. È possibile monitorare le dimensioni dello stato dell'applicazione utilizzando la metrica `lastCheckpointSize`.
+ I dati sullo stato dell'applicazione sono distribuiti in modo non uniforme tra le chiavi. Se l'applicazione utilizza l'operatore `KeyBy`, assicurati che i dati in entrata siano divisi equamente tra le chiavi. Assegnare la maggior parte dei dati a un'unica chiave implica la creazione di un collo di bottiglia, che provocherà errori.
+ L'applicazione subisce una contropressione della memoria o della rimozione di oggetti inutili (garbage collection). Consigliamo di monitorare `heapMemoryUtilization`, `oldGenerationGCTime` e `oldGenerationGCCount` dell'applicazione, per rilevare eventuali picchi o valori in aumento costante.
# Errorei del checkpoint per l'applicazione Apache Beam
Se l'applicazione Beam è configurata con l'[shutdownSourcesAfterIdleMs](https://beam.apache.org/documentation/runners/flink/#:~:text=shutdownSourcesAfterIdleMs)impostazione impostata su 0ms, i checkpoint potrebbero non essere attivati perché le attività sono nello stato «FINITO». La presente sezione descrive le caratteristiche e le soluzioni relative a questa situazione.
## Caratteristiche
Vai ai CloudWatch log dell'applicazione Managed Service for Apache Flink e controlla se il seguente messaggio di registro è stato registrato. Il seguente messaggio di log indica che il checkpoint non è andato a buon fine, poiché alcune attività sono state completate.
```
{
"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"
}
```
Ciò può accadere anche nella dashboard di Flink, dove alcune attività sono passate allo stato "FINITO" e il checkpoint non è più possibile.
![\[L'attività si trova nello stato "FINITO"\]](http://docs.aws.amazon.com/it_it/managed-flink/latest/java/images/beam_checkpoint_failure.png)
## Causa
shutdownSourcesAfterIdleMs è una variabile di configurazione di Beam che spegne le sorgenti che sono rimaste inattive per il tempo configurato di millisecondi. Il checkpoint non è più possibile quando una fonte viene chiusa. La conseguenza potrebbe essere un [checkpoint non riuscito](https://issues.apache.org/jira/browse/FLINK-2491).
Uno dei motivi per cui le attività passano allo stato «FINITO» è quando shutdownSourcesAfter IdleMs è impostato su 0 ms, il che significa che le attività inattive verranno chiuse immediatamente.
## Soluzione
Per evitare che le attività entrino immediatamente nello stato «FINITO», imposta su Long.MAX\$1VALUE. shutdownSourcesAfter IdleMs Esistono due maniere per assicurarsene:
+ Opzione 1: se la configurazione di beam è impostata nella pagina di configurazione dell'applicazione Managed Service for Apache Flink, puoi aggiungere una nuova coppia di valori chiave per impostare Ms come segue: shutdpwnSourcesAfteridle
![\[shutdownSourcesAfterIdleMs Impostato su Long.max_value\]](http://docs.aws.amazon.com/it_it/managed-flink/latest/java/images/beam_checkpoint_failure_solution.png)
+ Opzione 2: se la configurazione di beam è impostata nel file JAR, puoi impostare come segue: 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
```
# Contropressione
Flink utilizza la contropressione per adattare la velocità di elaborazione dei singoli operatori.
L'operatore può avere difficoltà a continuare a elaborare il volume di messaggi che riceve per diverse ragioni. L'operazione può richiedere più risorse della CPU di quante ne abbia a disposizione l'operatore. L'operatore può attendere il completamento I/O delle operazioni. Se un operatore non è in grado di elaborare rapidamente gli eventi, crea una contropressione negli operatori a monte che alimentano l'operatore lento. Ciò causa un rallentamento degli operatori a monte, il che può propagare ulteriormente la contropressione alla fonte e far sì che la sorgente si adatti alla velocità di trasmissione effettiva complessiva dell'applicazione, rallentando anche quest'ultima. Per una descrizione più approfondita della contropressione e del suo funzionamento, consulta [Come Apache Flink™ gestisce la contropressione](https://www.ververica.com/blog/how-flink-handles-backpressure).
Individuare gli operatori più lenti all'interno di un'applicazione consente di ottenere informazioni fondamentali per comprendere la causa principale dei problemi di prestazioni dell'applicazione. Le informazioni relative alla contropressione sono [rese visibili tramite la dashboard di Flink](https://nightlies.apache.org/flink/flink-docs-stable/docs/ops/monitoring/back_pressure/). Per identificare l'operatore lento è sufficiente individuare quello con un valore di contropressione elevato più vicino a un sink (l'operatore B, nell'esempio seguente). L'operatore responsabile dei rallentamenti è uno degli operatori a valle (l'operatore C nell'esempio). A causa della contropressione l'operatore B non è in grado di inoltrare l'output a C, l'operatore lento a causa del quale non riesce a elaborare gli eventi in maniera rapida.
```
A (backpressured 93%) -> B (backpressured 85%) -> C (backpressured 11%) -> D (backpressured 0%)
```
Una volta identificato l'operatore lento, prova a individuare i motivi di tale fenomeno. Talvolta le ragioni potrebbero essere molteplici e l'individuazione del problema rivelarsi complessa, tanto da richiedere diversi giorni dedicati ad attività di debugging e profilazione. Di seguito sono riportati alcune delle cause più ovvie e comuni, alcune delle quali sono ulteriormente descritte di seguito:
+ l'operatore esegue un I/O lento, ad esempio chiamate di rete (valuta di ricorrere all'utilizzo di AsyncIO);
+ C'è un'inclinazione nei dati e un operatore riceve più eventi degli altri (verifica esaminando il numero di messaggi in/out delle singole sottoattività (ad esempio, istanze dello stesso operatore) nella dashboard di Flink.
+ Si tratta di un'operazione che richiede molte risorse (se non vi è alcuna distorsione dei dati, è consigliabile utilizzare la scalabilità orizzontale per il lavoro legato o l'aumento per il lavoro CPU/memory legato) `ParallelismPerKPU` I/O
+ Log dettagliato nell'operatore: è consigliabile ridurlo al minimo per le applicazioni di produzione o considerare, invece, di inviare l'output di debug a un flusso di dati.
## Test della produttività con Discarding Sink
Il [discarding sink](https://nightlies.apache.org/flink/flink-docs-stable/api/java/org/apache/flink/streaming/api/functions/sink/DiscardingSink.html) ignora tutti gli eventi che riceve mentre l'applicazione è ancora in esecuzione (un'applicazione senza sink non può essere eseguita). Si rivela estremamente utile per effettuare test e profilazioni della velocità di trasmissione effettiva, nonché per verificare il corretto dimensionamento dell'applicazione. Si tratta inoltre di un controllo di integrità estremamente pragmatico, atto a verificare se a causare la contropressione siano i sink o l'applicazione. Limitarsi a effettuare un controllo dei parametri di contropressione, tuttavia, rappresenta spesso la soluzione più semplice e diretta.
Sostituire tutti i sink di un'applicazione con un discarding sink e creare una fonte fittizia che genera dati simili a quelli di produzione consente di misurare la massima velocità di trasmissione effettiva dell'applicazione relativamente a una determinata impostazione di parallelismo. È inoltre possibile aumentare il parallelismo per verificare che l'applicazione si dimensioni in maniera corretta e non presenti ostacoli che emergono solo a velocità di trasmissione effettiva più elevate (ad esempio, a causa del disallineamento dei dati).
# Disallineamento dei dati
Un'applicazione Flink viene eseguita su un cluster in modo distribuito. Per impiegare la scalabilità orizzontale su più nodi Flink utilizza il concetto di flussi con chiave, il che significa che gli eventi di un flusso vengono partizionati in base a una chiave specifica, ad esempio l'ID del cliente, per cui Flink può elaborare diverse partizioni su nodi diversi. Molti operatori Flink vengono quindi valutati sulla base di queste partizioni, ad esempio [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/) e [Async I/O](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/asyncio/).
La scelta di una chiave di partizione dipende spesso dalla logica commerciale. Al contempo, molte delle best practice per [DynamoDB](https://aws.amazon.com/dynamodb/) e Spark, per esempio, possono essere applicate anche a Flink. Tra di esse:
+ garantire un'elevata cardinalità delle chiavi di partizione;
+ evitare il disallineamento tra le partizioni del volume degli eventi.
È possibile identificare l'inclinazione nelle partizioni confrontando i record received/sent delle sottoattività (ad esempio, istanze dello stesso operatore) nella dashboard di Flink. Inoltre, il monitoraggio del servizio gestito per Apache Flink può essere configurato per mostrare le metriche relative a `numRecordsIn/Out` e `numRecordsInPerSecond/OutPerSecond` anche per quanto riguarda le attività secondarie.
# Disallineamento dello stato
Per gli operatori stateful, ovvero gli operatori che conservano lo stato per la propria logica commerciale, come Windows, il disallineamento dei dati provoca sempre il disallineamento dello stato. Alcune attività secondarie ricevono una quantità più elevata di eventi rispetto ad altre a causa del disallineamento dei dati, conservando così una maggiore quantità di dati nello stato. Tuttavia, anche per un'applicazione con partizioni bilanciate in modo uniforme, è possibile che si verifichi un disallineamento nella quantità di dati conservati nello stato. Ad esempio, per le finestre di sessione alcuni utenti e sessioni possono essere molto più lunghi di altri. Se le sessioni più lunghe fanno parte della stessa partizione, ciò può portare a uno squilibrio della dimensione dello stato gestita da diverse attività secondarie dello stesso operatore.
Il disallineamento dello stato non solo aumenta la quantità di memoria e di risorse del disco impiegate per le singole attività secondarie, ma può anche ridurre le prestazioni complessive dell'applicazione. Quando un'applicazione esegue un checkpoint o un savepoint, lo stato dell'operatore viene conservato in Amazon S3, per proteggere lo stato da errori del nodo o del cluster. Durante questo processo (specialmente con la semantica Exactly Once abilitata per impostazione predefinita su Managed Service for Apache Flink), l'elaborazione si blocca da una prospettiva esterna fino al completamento. checkpoint/savepoint In caso di disallineamento dei dati, il tempo necessario per completare l'operazione può essere vincolato da una singola attività secondaria che ha accumulato una quantità di stato particolarmente elevata. In casi estremi, l'esecuzione checkpoints/savepoints può fallire perché una singola sottoattività non è in grado di persistere.
Analogamente al disallineamento dei dati, il disallineamento dello stato può rallentare notevolmente un'applicazione.
La dashboard di Flink può essere sfrutrata per identificare il disallineamento dello stato. Individua un checkpoint o un savepoint recente e confronta la quantità di dati archiviati per le singole attività secondarie nei dettagli.
# Integrazione con risorse di diverse regioni
È possibile abilitare l'utilizzo di `StreamingFileSink` per la scrittura su un bucket Amazon S3 in una regione diversa rispetto all'applicazione di servizio gestito per Apache Flink tramite un'impostazione richiesta per la replica interregionale nella configurazione di Flink. A tale scopo, invia un ticket e richiedi assistenza al [Supporto AWS Centro](https://console.aws.amazon.com/support/home#/).