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 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#/).