Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Résolution des problèmes d'exécution
Cette section contient des informations sur le diagnostic et la résolution des problèmes d’exécution de votre application de service géré pour Apache Flink.
**Topics**
+ [Outils de dépannage](#troubleshooting-tools)
+ [Problèmes liés à l'application](troubleshooting-symptoms.md)
+ [L'application est en train de redémarrer](troubleshooting-rt-restarts.md)
+ [Le débit est trop lent](troubleshooting-rt-throughput.md)
+ [Croissance illimitée de l'État](troubleshooting-rt-stateleaks.md)
+ [Opérateurs liés aux E/S](troubleshooting-io-bound-operators.md)
+ [Limitation en amont ou à la source à partir d’un flux de données Kinesis](troubleshooting-source-throttling.md)
+ [Points de contrôle](troubleshooting-checkpoints.md)
+ [Le délai du point de contrôle est expiré](troubleshooting-chk-timeout.md)
+ [Échec de point de contrôle pour l’application Apache Beam](troubleshooting-chk-failure-beam.md)
+ [Contre-pression](troubleshooting-backpressure.md)
+ [Asymétrie de données](troubleshooting-data-skew.md)
+ [Asymétrie d’état](troubleshooting-state-skew.md)
+ [Intégrez les ressources de différentes régions](troubleshooting-resources-in-different-regions.md)
## Outils de dépannage
Les CloudWatch alarmes sont le principal outil de détection des problèmes liés aux applications. À l'aide d' CloudWatch alarmes, vous pouvez définir des seuils pour CloudWatch les mesures qui indiquent des erreurs ou des goulots d'étranglement dans votre application. Pour plus d'informations sur les CloudWatch alarmes recommandées, consultez[Utiliser les CloudWatch alarmes avec Amazon Managed Service pour Apache Flink](monitoring-metrics-alarms.md).
# Problèmes liés à l'application
Cette section contient des solutions aux erreurs que vous pourriez rencontrer avec votre application de service géré pour for Apache Flink.
**Topics**
+ [L'application est bloquée dans un statut transitoire](#troubleshooting-rt-stuck)
+ [La création d'un instantané échoue](#troubleshooting-rt-snapshots)
+ [Impossible d'accéder aux ressources d'un VPC](#troubleshooting-rt-vpc)
+ [Des données sont perdues lors de l'écriture dans un compartiment Amazon S3](#troubleshooting-rt-s3)
+ [L'application est en cours d'exécution mais ne traite pas les données](#troubleshooting-rt-processing)
+ [Snapshot, mise à jour de l'application ou erreur d'arrêt de l'application : InvalidApplicationConfigurationException](#troubleshooting-rt-appconfigexception)
+ [fichier java.nio. NoSuchFileException:/ usr/local/openjdk-8/lib/security/cacerts](#troubleshooting-rt-fnf)
## L'application est bloquée dans un statut transitoire
Si votre application reste dans un état transitoire (`STARTING`,`UPDATING`, ou`AUTOSCALING`)`STOPPING`, vous pouvez arrêter votre application en utilisant l'[StopApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_StopApplication.html)action dont le `Force` paramètre est défini sur. `true` Vous ne pouvez pas forcer l’arrêt d’une application lorsqu’elle est à l’état `DELETING`. Sinon, si l’application a l’état `UPDATING` ou `AUTOSCALING`, vous pouvez revenir à la version précédente en cours d’exécution. Lorsque vous annulez une application, elle charge les données d’état du dernier instantané réussi. Si l’application ne possède aucun instantané, le service géré pour Apache Flink rejette la demande de restauration. Pour plus d'informations sur l'annulation d'une application, consultez la section [RollbackApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_RollbackApplication.html)Action.
**Note**
L’arrêt forcé de votre application peut entraîner une perte ou une duplication des données. Pour éviter la perte de données ou le double traitement des données lors du redémarrage de l’application, nous vous recommandons d’enregistrer fréquemment des instantanés de votre application.
Les causes de blocage des applications peuvent être les suivantes :
+ **L’état de l’application est trop important :** si l’état de l’application est trop important ou trop persistant, l’application peut se bloquer lors d’une opération de point de contrôle ou d’instantané. Vérifiez les métriques `lastCheckpointDuration` et `lastCheckpointSize` de votre application pour détecter des valeurs en augmentation constante ou anormalement élevées.
+ **Le code de l’application est trop volumineux :** vérifiez que le fichier JAR de votre application est inférieur à 512 Mo. Les fichiers JAR de plus de 512 Mo ne sont pas pris en charge.
+ **La création d’un instantané de l’application échoue :** le service géré pour Apache Flink crée un instantané de l’application lors d’une demande [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) ou [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). Le service utilise ensuite cet état d’instantané et restaure l’application à l’aide de la configuration mise à jour de l’application afin de fournir une sémantique de traitement *unique*. Si la création automatique d’instantané échoue, consultez [La création d'un instantané échoue](#troubleshooting-rt-snapshots).
+ **La restauration à partir d’un instantané échoue :** si vous supprimez ou modifiez un opérateur dans une mise à jour d’application et que vous tentez de restaurer à partir d’un instantané, la restauration échouera par défaut si l’instantané contient les données d’état de l’opérateur manquant. De plus, l’application sera bloquée à l’état `STOPPED` ou `UPDATING`. Pour modifier ce comportement et permettre à la restauration de réussir, modifiez le *AllowNonRestoredState*paramètre de l'application [FlinkRunConfiguration](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_FlinkRunConfiguration.html)sur`true`. Cela permettra à l’opération de reprise d’ignorer les données d’état qui ne peuvent pas être mises en correspondance avec le nouveau programme.
+ **L’initialisation de l’application prend trop de temps :** le service géré pour Apache Flink utilise un délai d’attente interne de 5 minutes (réglage modifiable) pour le démarrage d’une tâche Flink. Si votre tâche ne démarre pas dans ce délai, vous verrez le CloudWatch journal suivant :
```
Flink job did not start within a total timeout of 5 minutes for application: %s under account: %s
```
Si vous rencontrez l’erreur ci-dessus, cela signifie que vos opérations définies selon la méthode `main` de la tâche Flink prennent plus de 5 minutes, entraînant l’expiration du délai de création de la tâche Flink du côté du service géré pour Apache Flink. Nous vous suggérons de consulter les **JobManager**journaux Flink ainsi que le code de votre application pour voir si ce retard dans la `main` méthode est prévu. Si ce n’est pas le cas, vous devez prendre des mesures pour résoudre le problème afin que l’opération prenne moins de 5 minutes.
Vous pouvez vérifier l’état de votre application à l’aide des actions [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) ou [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 création d'un instantané échoue
Le service géré pour Apache Flink ne peut pas prendre d’instantané dans les circonstances suivantes :
+ L’application a dépassé la limite d’instantané. La limite est de 1 000 instantanés. Pour de plus amples informations, veuillez consulter [Gérez les sauvegardes d'applications à l'aide de snapshots](how-snapshots.md).
+ L’application n’est pas autorisée à accéder à sa source ou à son récepteur.
+ Le code de l’application ne fonctionne pas correctement.
+ L’application rencontre d’autres problèmes de configuration.
Si vous obtenez une exception lors de la création d’un instantané pendant la mise à jour ou l’arrêt de l’application, définissez la propriété `SnapshotsEnabled` de la [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) de votre application sur `false` et réessayez la demande.
Les instantanés peuvent échouer si les opérateurs de votre application ne sont pas correctement configurés. Pour obtenir des informations sur le réglage des performances des opérateurs, consultez [Mise à l’échelle des opérateurs](performance-improving.md#performance-improving-scaling-op).
Une fois que l’application est revenue à un état sain, nous vous recommandons de définir la propriété `SnapshotsEnabled` de l’application sur `true`.
## Impossible d'accéder aux ressources d'un VPC
Si votre application utilise un VPC exécuté sur Amazon VPC, procédez comme suit pour vérifier que votre application a accès à ses ressources :
+ Vérifiez vos CloudWatch journaux pour détecter l'erreur suivante. Cette erreur indique que votre application ne peut pas accéder aux ressources de votre VPC :
```
org.apache.kafka.common.errors.TimeoutException: Failed to update metadata after 60000 ms.
```
Si cette erreur s’affiche, vérifiez que vos tables de routage sont correctement configurées et que les paramètres de connexion de vos connecteurs sont corrects.
Pour plus d'informations sur la configuration et l'analyse CloudWatch des journaux, consultez[Journalisation et surveillance dans Amazon Managed Service pour Apache Flink](monitoring-overview.md).
## Des données sont perdues lors de l'écriture dans un compartiment Amazon S3
Certaines pertes de données peuvent se produire lors de l’écriture d’un fichier de sortie dans un compartiment Amazon S3 à l’aide d’Apache Flink version 1.6.2. Nous vous recommandons d’utiliser la dernière version prise en charge d’Apache Flink lorsque vous utilisez Amazon S3 pour écrire un fichier de sortie directement. Pour écrire dans un compartiment Amazon S3 à l'aide d'Apache Flink 1.6.2, nous vous recommandons d'utiliser Firehose. Pour plus d'informations sur l'utilisation de Firehose avec Managed Service pour Apache Flink, consultez. [Évier Firehose](earlier.md#get-started-exercise-fh)
## L'application est en cours d'exécution mais ne traite pas les données
Vous pouvez vérifier l’état de votre application à l’aide des actions [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) ou [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). Si votre application entre dans le `RUNNING` statut mais n'écrit pas de données dans votre récepteur, vous pouvez résoudre le problème en ajoutant un flux de CloudWatch journal Amazon à votre application. Pour de plus amples informations, veuillez consulter [Utiliser les options de CloudWatch journalisation des applications](cloudwatch-logs.md#adding_cloudwatch). Le flux de journaux contient des messages que vous pouvez utiliser pour résoudre les problèmes de l’application.
## Snapshot, mise à jour de l'application ou erreur d'arrêt de l'application : InvalidApplicationConfigurationException
Une erreur similaire à la suivante peut se produire lors d’une opération d’instantané ou lors d’une opération de création d’un instantané, telle que la mise à jour ou l’arrêt d’une application :
```
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
```
Cette erreur se produit lorsque l’application ne parvient pas à créer un instantané.
Si vous rencontrez cette erreur lors d’une opération d’instantané ou d’une opération de création d’un instantané, procédez comme suit :
+ Désactivez les instantanés pour votre application. Vous pouvez le faire soit dans la console Managed Service for Apache Flink, soit en utilisant le `SnapshotsEnabledUpdate` paramètre de l'[UpdateApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_UpdateApplication.html)action.
+ Découvrez pourquoi les instantanés ne peuvent pas être créés. Pour plus d’informations, consultez [L'application est bloquée dans un statut transitoire](#troubleshooting-rt-stuck).
+ Réactivez les instantanés lorsque l’application revient à un état sain.
## fichier java.nio. NoSuchFileException:/ usr/local/openjdk-8/lib/security/cacerts
L’emplacement du truststore SSL a été mis à jour lors d’un déploiement précédent. Utilisez la valeur suivante pour le paramètre `ssl.truststore.location` à la place :
```
/usr/lib/jvm/java-11-amazon-corretto/lib/security/cacerts
```
# L'application est en train de redémarrer
Si votre application n’est pas saine, sa tâche Apache Flink échoue et redémarre continuellement. Cette section décrit les symptômes et les étapes de résolution de ce problème.
## Symptômes
Ce problème peut présenter les symptômes suivants :
+ La métrique `FullRestarts` n’est pas nulle. Cette métrique représente le nombre de fois où la tâche de l’application a été redémarrée depuis que vous l’avez lancée.
+ La métrique `Downtime` n’est pas nulle. Cette métrique représente le nombre de millisecondes pendant lesquelles l’application est à l’état `FAILING` ou `RESTARTING`.
+ Le journal des applications contient les passages à l’état `RESTARTING` ou `FAILED`. Vous pouvez interroger le journal de votre application pour ces changements de statut à l'aide de la requête CloudWatch Logs Insights suivante :[Analyser les erreurs : défaillances liées aux tâches de l'application](cloudwatch-logs-reading.md#cloudwatch-logs-reading-apps).
## Causes et solutions
Les conditions suivantes peuvent rendre votre application instable et provoquer des redémarrages répétés :
+ **L'opérateur lance une exception :** si une exception d'un opérateur de votre application n'est pas gérée, l'application bascule (en interprétant que l'échec ne peut pas être géré par l'opérateur). L’application redémarre à partir du dernier point de contrôle afin de conserver la sémantique de traitement unique. Par conséquent, la valeur `Downtime` n’est pas nulle pendant ces périodes de redémarrage. Pour éviter que cela ne se produise, nous vous recommandons de gérer toutes les exceptions réessayables dans le code de l’application.
Vous pouvez rechercher les causes de cette situation en interrogeant les journaux de votre application pour vérifier si l’état de votre application est passé de `RUNNING` à `FAILED`. Pour plus d’informations, consultez [Analyser les erreurs : défaillances liées aux tâches de l'application](cloudwatch-logs-reading.md#cloudwatch-logs-reading-apps).
+ **Les flux de données Kinesis ne sont pas correctement provisionnés :** si la source ou le récepteur de votre application est un flux de données Kinesis, vérifiez si les [métriques](https://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.html) du flux ne contiennent pas d'erreurs. `ReadProvisionedThroughputExceeded` `WriteProvisionedThroughputExceeded`
Si ces erreurs s’affichent, vous pouvez augmenter le débit disponible pour le flux Kinesis en augmentant le nombre de partitions du flux. Pour plus d’informations, consultez la rubrique [Comment modifier le nombre de partitions ouvertes dans Kinesis Data Streams ?](https://aws.amazon.com/premiumsupport/knowledge-center/kinesis-data-streams-open-shards/)
+ **Les autres sources ou récepteurs ne sont pas correctement provisionnés ou disponibles :** vérifiez que votre application provisionne correctement les sources et les récepteurs. Vérifiez que les sources ou les récepteurs utilisés dans l'application (tels que les autres AWS services ou les sources ou destinations externes) sont bien approvisionnés, ne sont pas limités en lecture ou en écriture ou sont régulièrement indisponibles.
Si vous rencontrez des problèmes de débit avec vos services dépendants, augmentez les ressources disponibles pour ces services ou recherchez la cause des erreurs ou indisponibilités.
+ **Les opérateurs ne sont pas correctement provisionnés :** si la charge de travail sur les threads de l’un des opérateurs de votre application n’est pas correctement répartie, l’opérateur peut être surchargé et l’application peut se bloquer. Pour obtenir des informations sur le réglage du parallélisme des opérateurs, consultez [Gérez correctement la mise à l’échelle des opérateurs](performance-improving.md#performance-improving-scaling-op).
+ **L'application échoue avec DaemonException :** Cette erreur apparaît dans le journal de votre application si vous utilisez une version d'Apache Flink antérieure à la version 1.11. Vous devrez peut-être effectuer une mise à niveau vers une version ultérieure d’Apache Flink afin d’utiliser une version KPL 0.14 ou ultérieure.
+ **L'application échoue avec TimeoutException FlinkException, ou RemoteTransportException :** Ces erreurs peuvent apparaître dans le journal de votre application si vos gestionnaires de tâches tombent en panne. Si votre application est surchargée, vos gestionnaires de tâches peuvent être soumis à une pression sur les ressources du processeur ou de la mémoire, ce qui peut entraîner leur échec.
Ces erreurs peuvent se présenter comme suit :
+ `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`
Pour résoudre ce problème, vérifiez les points suivants :
+ Vérifiez vos CloudWatch indicateurs pour détecter des pics inhabituels d'utilisation du processeur ou de la mémoire.
+ Vérifiez que votre application ne présente aucun problème de débit. Pour plus d’informations, consultez [Résoudre les problèmes de performances](performance-troubleshooting.md).
+ Examinez le journal de votre application pour détecter les exceptions non gérées générées par le code de votre application.
+ **L'application échoue avec l'erreur JaxbAnnotationModule Not Found :** cette erreur se produit si votre application utilise Apache Beam, mais ne possède pas les dépendances ou les versions de dépendances correctes. Les applications du service géré pour Apache Flink qui utilisent Apache Beam doivent utiliser les versions de dépendances suivantes :
```
2.10.2
...
com.fasterxml.jackson.module
jackson-module-jaxb-annotations
2.10.2
```
Si vous ne fournissez pas la bonne version de `jackson-module-jaxb-annotations` en tant que dépendance explicite, votre application la charge à partir des dépendances de l’environnement, et comme les versions ne correspondent pas, l’application se bloque au moment de l’exécution.
Pour plus d’informations sur l’utilisation d’Apache Beam avec le service géré pour Apache Flink, consultez [Utiliser CloudFormationCréation d’une application à l’aide d’Apache Beam](examples-beam.md).
+ **L'application échoue avec java.io. IOException: nombre insuffisant de tampons réseau**
Cela se produit lorsqu’une application ne dispose pas de mémoire suffisante pour les tampons réseau. Les tampons réseau facilitent la communication entre les sous-tâches. Ils sont utilisés pour stocker des enregistrements avant leur transmission sur un réseau et pour stocker les données entrantes avant de les disséquer en enregistrements et de les transmettre à des sous-tâches. Le nombre de tampons réseau requis varie directement en fonction du parallélisme et de la complexité de votre graphique de tâches. Il existe plusieurs approches pour atténuer ce problème :
+ Vous pouvez configurer une valeur `parallelismPerKpu` inférieure pour augmenter la quantité de mémoire allouée par sous-tâche et par mémoire tampon réseau. Notez que la réduction de la valeur `parallelismPerKpu` augmentera le nombre d’unités KPU et donc le coût. Pour éviter cela, vous pouvez conserver la même quantité d’unités KPU en réduisant le parallélisme du même facteur.
+ Vous pouvez simplifier votre graphe de tâches en réduisant le nombre d’opérateurs ou en créant des chaînes afin de réduire le nombre de tampons nécessaires.
+ Sinon, vous pouvez vous adresser à une configuration personnalisée https://aws.amazon.com/premiumsupport/ de la mémoire tampon réseau.
# Le débit est trop lent
Si votre application ne traite pas assez rapidement les données de streaming entrantes, elle fonctionnera mal et deviendra instable. Cette section décrit les symptômes et les étapes de résolution de ce problème.
## Symptômes
Ce problème peut présenter les symptômes suivants :
+ Si la source de données de votre application est un flux Kinesis, la métrique `millisbehindLatest` du flux augmente continuellement.
+ Si la source de données de votre application est un cluster Amazon MSK, les métriques de retard des consommateurs pour le cluster augmentent continuellement. Pour plus d’informations, consultez la section [Surveillance du retard des consommateurs](https://docs.aws.amazon.com/msk/latest/developerguide/consumer-lag.html) du [guide du développeur Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html).
+ Si la source de données de votre application est un autre service ou une autre source, vérifiez les métriques de retard des consommateurs ou les données disponibles.
## Causes et solutions
Le ralentissement du débit des applications peut avoir de nombreuses causes. Si votre application ne suit pas le rythme des entrées, vérifiez les points suivants :
+ Si le retard de débit augmente puis diminue, vérifiez si l’application redémarre. Votre application arrêtera de traiter les entrées pendant le redémarrage, ce qui provoquera un pic de retard. Pour obtenir des informations sur les échecs d’application, consultez [L'application est en train de redémarrer](troubleshooting-rt-restarts.md).
+ Si le retard de débit est constant, vérifiez si les performances de votre application sont optimisées. Pour plus d’informations sur l’optimisation des performances de votre application, consultez [Résoudre les problèmes de performances](performance-troubleshooting.md).
+ Si le retard de débit n’augmente pas de manière excessive, mais augmente continuellement et que les performances de votre application sont optimisées, vous devez augmenter les ressources de votre application. Pour plus d’informations sur l’augmentation des ressources d’application, consultez[Mettre en œuvre le dimensionnement des applications](how-scaling.md).
+ Si votre application lit à partir d’un cluster Kafka situé dans une autre région et que `FlinkKafkaConsumer` ou `KafkaSource` sont principalement inactifs (`idleTimeMsPerSecond` élevé ou `CPUUtilization` faible) malgré un retard important pour les consommateurs, vous pouvez augmenter la valeur pour `receive.buffer.byte`, par exemple 2097152. Pour plus d’informations, consultez la section relative à l’environnement à retard élevé de [Configurations MSK personnalisées](https://docs.aws.amazon.com/msk/latest/developerguide/msk-configuration-properties.html).
Pour les étapes de résolution des problèmes liés au ralentissement du débit ou à l’augmentation du retard des consommateurs dans la source de l’application, consultez [Résoudre les problèmes de performances](performance-troubleshooting.md).
# Croissance illimitée de l'État
Si votre application ne supprime pas correctement les informations d’état obsolètes, elles s’accumuleront continuellement et entraîneront des problèmes de performance ou de stabilité de l’application. Cette section décrit les symptômes et les étapes de résolution de ce problème.
## Symptômes
Ce problème peut présenter les symptômes suivants :
+ La métrique `lastCheckpointDuration` augmente progressivement ou connaît des pics.
+ La métrique `lastCheckpointSize` augmente progressivement ou connaît des pics.
## Causes et solutions
Les conditions suivantes peuvent amener votre application à accumuler des données d’état :
+ Votre application conserve les données d’état plus longtemps que nécessaire.
+ Votre application utilise des requêtes de fenêtre d’une durée trop longue.
+ Vous n’avez pas défini le TTL pour vos données d’état. Pour plus d'informations, consultez [State Time-To-Live (TTL)](https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/dev/datastream/fault-tolerance/state/#state-time-to-live-ttl) dans la documentation d'Apache Flink.
+ Vous exécutez une application qui dépend de la version 2.25.0 ou ultérieure d’Apache Beam. [Vous pouvez vous désinscrire de la nouvelle version de la transformation de lecture en BeamApplicationProperties ajoutant les expériences et les valeurs clés`use_deprecated_read`.](https://docs.aws.amazon.com/managed-flink/latest/java/examples-beam.html#examples-beam-configure) Pour plus d’informations, consultez la [documentation Apache Beam](https://beam.apache.org/blog/beam-2.25.0/#highlights).
Parfois, les applications sont confrontées à une augmentation constante de la taille de l’état, qu’elles ne peuvent supporter à long terme (une application Flink fonctionne indéfiniment, après tout). Parfois, cela peut venir du fait que les applications stockent les données dans leur état, sans permettre le vieillissement correct des anciennes informations. Mais parfois, les attentes quant à ce que Flink peut offrir sont tout simplement déraisonnables. Les applications peuvent utiliser des agrégations sur de longues périodes s’étendant sur des jours, voire des semaines. À moins qu'il [AggregateFunctions](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/windows/#aggregatefunction)ne soit utilisé, ce qui permet des agrégations incrémentielles, Flink doit conserver les événements de l'ensemble de la fenêtre en état.
En outre, lors de l’utilisation de fonctions de processus pour implémenter des opérateurs personnalisés, l’application doit supprimer les données d’état qui ne sont plus nécessaires à la logique métier. Dans ce cas, [l'état time-to-live](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/fault-tolerance/state/#state-time-to-live-ttl) peut être utilisé pour vieillir automatiquement les données en fonction du temps de traitement. Le service géré pour Apache Flink utilise des points de contrôle incrémentiels, ainsi l’état TTL est basé sur le [compactage RocksDB.](https://github.com/facebook/rocksdb/wiki/Compaction) Vous ne pouvez observer une réduction réelle de la taille de l’état (indiquée par la taille du point de contrôle) qu’après une opération de compactage. En particulier pour les points de contrôle de taille inférieure à 200 Mo, il est peu probable que vous observiez une réduction de la taille des points de contrôle à la suite de l’expiration de l’état. Cependant, les points de sauvegarde sont basés sur une copie propre de l’état, qui ne contient pas d’anciennes données. Vous pouvez donc déclencher un instantané dans le service géré pour Apache Flink afin de forcer la suppression de l’état obsolète.
À des fins de débogage, il peut être judicieux de désactiver les points de contrôle incrémentiels pour vérifier plus rapidement que la taille du point de contrôle diminue ou se stabilise réellement (et éviter l’effet de compactage dans RocksBS). Pour cela, il faut cependant envoyer un ticket à l’équipe du service.
# Opérateurs liés aux E/S
Il est préférable d’éviter toute dépendance à des systèmes externes sur le chemin des données. Il est souvent beaucoup plus performant de conserver un ensemble de données de référence dans son état plutôt que de faire appel à un système externe pour enrichir des événements individuels. Cependant, certaines dépendances ne peuvent pas être facilement déplacées vers un état, par exemple si vous souhaitez enrichir les événements avec un modèle de machine learning hébergé sur Amazon Sagemaker.
Les opérateurs qui s’interfacent avec des systèmes externes via le réseau peuvent devenir un goulot d’étranglement et provoquer une contre-pression. Il est fortement recommandé d’utiliser [AsyncIO](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/asyncio/) pour implémenter la fonctionnalité, afin de réduire le temps d’attente pour les appels individuels et d’éviter le ralentissement de l’ensemble de l’application.
En outre, pour les applications avec des opérateurs I/O liés, il peut également être judicieux d'augmenter le paramètre [ParallelismPerKPU](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_ParallelismConfiguration.html) de l'application Managed Service for Apache Flink. Cette configuration décrit le nombre de sous-tâches parallèles qu’une application peut effectuer par unité de traitement Kinesis (KPU). En augmentant la valeur par défaut de 1 à 4, par exemple, l’application utilise les mêmes ressources (et a le même coût) mais peut augmenter le parallélisme jusqu’à 4 fois. Cela fonctionne bien pour les applications I/O liées, mais cela entraîne une surcharge supplémentaire pour les applications non I/O liées.
# Limitation en amont ou à la source à partir d’un flux de données Kinesis
**Symptôme** : l’application rencontre une erreur `LimitExceededExceptions` provenant du flux de données Kinesis source en amont.
**Cause potentielle** : le paramètre par défaut du connecteur Kinesis de la bibliothèque Apache Flink est défini pour lire à partir du flux de données Kinesis source, avec un paramètre par défaut très agressif pour le nombre maximal d’enregistrements extraits par appel `GetRecords`. Apache Flink est configuré par défaut pour récupérer 10 000 enregistrements par `GetRecords` appel (cet appel est effectué par défaut toutes les 200 ms), bien que la limite par partition ne soit que de 1 000 enregistrements.
Ce comportement par défaut peut entraîner une limitation lors de la tentative de consommation à partir du flux de données Kinesis, ce qui affectera les performances et la stabilité des applications.
Vous pouvez le confirmer en vérifiant la CloudWatch `ReadProvisionedThroughputExceeded` métrique et en voyant les périodes prolongées ou prolongées pendant lesquelles cette métrique est supérieure à zéro.
Vous pouvez également le voir dans CloudWatch les journaux de votre application Amazon Managed Service for Apache Flink en observant `LimitExceededException` les erreurs continues.
**Résolution** : vous pouvez effectuer l'une des deux opérations suivantes pour résoudre ce scénario :
+ Abaisser la limite par défaut du nombre d'enregistrements récupérés par appel `GetRecords`
+ Activez les lectures adaptatives dans votre application Amazon Managed Service pour Apache Flink. Pour plus d’informations sur la fonctionnalité de lecture adaptative, consultez [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)
# Points de contrôle
Les points de contrôle sont le mécanisme utilisé par Flink pour garantir que l’état d’une application est tolérant aux pannes. Ce mécanisme permet à Flink de récupérer l’état des opérateurs en cas d’échec de la tâche et donne à l’application la même sémantique qu’une exécution sans échec. Avec Managed Service pour Apache Flink, l'état d'une application est stocké dans RockSDB, un key/value magasin intégré qui conserve son état de fonctionnement sur le disque. Lorsqu’un point de contrôle est pris, l’état est également transféré sur Amazon S3. Ainsi, même en cas de perte du disque, le point de contrôle peut être utilisé pour restaurer l’état de l’application.
Pour plus d’informations, consultez [Fonctionnement des instantanés d’état](https://nightlies.apache.org/flink/flink-docs-master/docs/learn-flink/fault_tolerance/#how-does-state-snapshotting-work).
## Étapes du point de contrôle
Pour une sous-tâche d’opérateur de point de contrôle dans Flink, il y a 5 étapes principales :
+ En attente [**Délai de démarrage**] : Flink utilise des barrières de point de contrôle qui sont insérées dans le flux. Ainsi, le délai à cette étape correspond au temps pendant lequel l’opérateur attend que la barrière de contrôle l’atteigne.
+ Alignement [**Durée de l’alignement**] : à cette étape, la sous-tâche a atteint une barrière, mais elle attend les barrières provenant d’autres flux d’entrée.
+ Point de contrôle synchrone [**Durée de synchronisation**] : c’est à cette étape que la sous-tâche crée réellement un instantané de l’état de l’opérateur et bloque toutes les autres activités de la sous-tâche.
+ Point de contrôle asynchrone [**Durée asynchrone**] : pendant la majeure partie de cette étape, la sous-tâche télécharge l’état vers Amazon S3. Au cours de cette étape, la sous-tâche n’est plus bloquée et peut traiter des enregistrements.
+ Reconnaissance — Il s'agit généralement d'une étape courte et consiste simplement à envoyer un accusé de réception aux messages de validation JobManager et à exécuter les éventuels messages de validation (par exemple avec les puits Kafka).
Chacune de ces étapes (à l’exception de la reconnaissance) correspond à une métrique de durée pour les points de contrôle, disponible dans l’interface utilisateur Web de Flink, qui peut aider à isoler la cause d’un long point de contrôle.
Pour voir une définition exacte de chacune des métriques disponibles sur les points de contrôle, rendez-vous dans l’[onglet Historique](https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/monitoring/checkpoint_monitoring/#history-tab).
## Enquête
Lorsque vous étudiez la durée prolongée d’un point de contrôle, la chose la plus importante à déterminer est le goulot d’étranglement du point de contrôle, c’est-à-dire quel opérateur et quelle sous-tâche mettent le plus de temps à atteindre le point de contrôle et quelle étape de cette sous-tâche prend le plus de temps. Cela peut être déterminé à l’aide de l’interface utilisateur Web de Flink, dans la tâche de contrôle des tâches. L’interface Web de Flink fournit des données et des informations qui aident à étudier les problèmes liés aux points de contrôle. Pour une analyse complète, consultez [Surveillance des points de contrôle](https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/monitoring/checkpoint_monitoring/).
La première chose à examiner est la **durée de bout en bout** de chaque opérateur dans le graphique des tâches afin de déterminer quel opérateur met beaucoup de temps à effectuer un point de contrôle et mérite une enquête plus approfondie. Selon la documentation de Flink, la durée est définie comme suit :
*Durée comprise entre l'horodatage du déclencheur et le dernier accusé de réception (ou n/a si aucun accusé de réception n'a encore été reçu). Cette durée de bout en bout pour un point de contrôle complet est déterminée par la dernière sous-tâche qui accuse réception du point de contrôle. Ce délai est généralement supérieur à celui dont ont besoin les sous-tâches individuelles pour effectuer un point de contrôle de l’état.*
Les autres durées du point de contrôle fournissent également des informations plus précises sur l’endroit où le temps est passé.
Si la **durée de synchronisation** est élevée, cela indique que quelque chose se passe pendant la création de l’instantané. Au cours de cette étape, `snapshotState()` est appelé pour les classes qui implémentent l’interface snapshotState ; il peut s’agir de code utilisateur, donc les vidages de threads peuvent être utiles pour étudier cela.
Une longue **durée asynchrone** suggère que beaucoup de temps est consacré au chargement de l’état sur Amazon S3. Cela peut se produire si l’état est volumineux ou si de nombreux fichiers d’état sont en cours de chargement. Si tel est le cas, cela vaut la peine d’étudier la manière dont l’état est utilisé par l’application et de s’assurer que les structures de données natives de Flink sont utilisées dans la mesure du possible ([Using Keyed State](https://nightlies.apache.org/flink/flink-docs-master/docs/dev/datastream/fault-tolerance/state/#using-keyed-state)). Le service géré pour Apache Flink configure Flink de manière à minimiser le nombre d’appels Amazon S3 pour garantir que cela ne soit pas trop long. Voici un exemple des statistiques de point de contrôle d’un opérateur. Cela montre que la **durée asynchrone** est relativement longue par rapport aux statistiques de point de contrôle des opérateurs précédentes.
![\[Enquête sur les points de contrôle\]](http://docs.aws.amazon.com/fr_fr/managed-flink/latest/java/images/checkpoint.png)
Si le **délai de démarrage** est élevé, cela signifie que la majeure partie du temps est consacrée à attendre que la barrière du point de contrôle atteigne l’opérateur. Cela indique que l’application met un certain temps à traiter les enregistrements, ce qui signifie que l’obstacle traverse lentement le graphique des tâches. C’est généralement le cas si le la tâche est soumise à une contre-pression ou si un ou plusieurs opérateurs sont constamment occupés. Voici un exemple de situation dans JobGraph laquelle le deuxième KeyedProcess opérateur est occupé.
![\[Enquête sur les points de contrôle\]](http://docs.aws.amazon.com/fr_fr/managed-flink/latest/java/images/checkpoint2.png)
Vous pouvez étudier ce qui prend autant de temps en utilisant Flink Flame Graphs ou en utilisant des TaskManager thread dumps. Une fois que le goulot d’étranglement a été identifié, il peut être étudié plus en détail à l’aide des graphiques en flamme ou des vidages de thread.
## Vidages de thread
Les vidages de thread sont un autre outil de débogage légèrement inférieur à celui des graphiques en flamme. Un vidage de thread affiche l’état d’exécution de tous les threads à un moment donné. Flink effectue un vidage de thread JVM, qui est un état d’exécution de tous les threads du processus Flink. L’état d’un thread est présenté par une trace de pile du thread ainsi que par des informations supplémentaires. Les graphiques en flamme sont en fait construits à partir de plusieurs traces de pile prises en succession rapide. Le graphique est une visualisation réalisée à partir de ces traces qui permet d’identifier facilement les chemins de code courants.
```
"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)
...
```
Vous trouverez ci-dessus un extrait d’un vidage de thread issu de l’interface utilisateur de Flink pour un seul thread. La première ligne contient des informations générales sur ce thread, notamment :
+ Le nom du fil *KeyedProcess (1/3) \$10*
+ La priorité du thread *prio=5*
+ Un identifiant de thread unique *Id=1423*
+ L’état du thread : *EXÉCUTABLE*
Le nom d’un thread donne généralement des informations sur son usage général. Les fils d'opérateurs peuvent être identifiés par leur nom puisque les fils d'opérateurs portent le même nom que l'opérateur, ainsi qu'une indication de la sous-tâche à laquelle ils sont liés. Par exemple, le fil *KeyedProcess (1/3) \$10* provient de l'*KeyedProcess*opérateur et provient de la première sous-tâche (sur 3).
Les threads peuvent avoir l’un des états suivants :
+ NOUVEAU : le thread a été créé mais n’a pas encore été traité
+ EXÉCUTABLE : le thread est en cours d’exécution sur le processeur
+ BLOQUÉ : le thread attend qu’un autre thread lève son verrou
+ EN ATTENTE : le thread attend à l’aide d’une méthode `wait()`, `join()` ou `park()`
+ EN ATTENTE PROGRAMMÉE : le thread attend en utilisant une méthode veille, attendre, rejoindre ou parquer, mais avec un temps d’attente maximal.
**Note**
Dans Flink 1.13, la profondeur maximale d’une trace de pile dans le vidage de thread est limitée à 8.
**Note**
Les vidages de thread doivent être le dernier recours pour résoudre les problèmes de performances dans une application Flink, car ils peuvent être difficiles à lire et nécessiter le prélèvement de plusieurs échantillons et leur analyse manuelle. Dans la mesure du possible, il est préférable d’utiliser des graphiques en flamme.
### Vidages de thread dans Flink
Dans Flink, un vidage de thread peut être effectué en choisissant l’option **Gestionnaires de tâches** dans la barre de navigation à gauche de l’interface utilisateur de Flink, en sélectionnant un gestionnaire de tâches spécifique, puis en accédant à l’onglet **Thread Dump**. Le vidage de thread peut être téléchargé, copié dans votre éditeur de texte préféré (ou analyseur de vidage de thread) ou analysé directement dans l’affichage en texte de l’interface utilisateur Web de Flink (cette dernière option peut toutefois s’avérer un peu compliquée).
Pour déterminer dans quel gestionnaire de tâches, un thread dump de l'**TaskManagers**onglet peut être utilisé lorsqu'un opérateur particulier est sélectionné. Cela montre que l’opérateur exécute différentes sous-tâches d’un opérateur et qu’il peut s’exécuter sur différents gestionnaires de tâches.
![\[Utilisation des vidages de thread\]](http://docs.aws.amazon.com/fr_fr/managed-flink/latest/java/images/checkpoint4.png)
Le vidage sera composé de plusieurs traces de pile. Cependant, lors de l’enquête sur le vidage, les informations relatives à un opérateur sont les plus importantes. Elles sont faciles à trouver, puisque les threads d’opérateurs portent le même nom que l’opérateur et indiquent à quelle sous-tâche ils sont liés. Par exemple, la trace de pile suivante provient de l'*KeyedProcess*opérateur et constitue la première sous-tâche.
```
"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)
...
```
Cela peut prêter à confusion s’il existe plusieurs opérateurs portant le même nom, mais nous pouvons nommer les opérateurs pour contourner ce problème. Par exemple :
```
....
.process(new ExpensiveFunction).name("Expensive function")
```
## [Graphiques en flamme](https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/debugging/flame_graphs/)
Les graphiques en flamme constituent un outil de débogage utile qui permet de visualiser les traces du code ciblé, ce qui permet d’identifier les chemins de code les plus fréquents. Ils sont créés en échantillonnant plusieurs fois des traces de pile. L’axe X d’un graphique en flamme montre les différents profils de pile, tandis que l’axe Y indique la profondeur de la pile et les appels dans la trace de pile. Un seul rectangle dans un graphique en flamme représente un cadre de pile, et la largeur d’un cadre indique la fréquence à laquelle il apparaît dans les piles. Pour plus de détails sur les graphiques en flamme et sur leur utilisation, consultez [Graphiques en flamme](https://www.brendangregg.com/flamegraphs.html).
Dans Flink, le graphe de flamme d'un opérateur est accessible via l'interface utilisateur Web en sélectionnant un opérateur, puis en choisissant l'**FlameGraph**onglet. Une fois que suffisamment d’échantillons ont été prélevés, le graphique en flamme s’affiche. Voici le car il fallait ProcessFunction beaucoup de temps FlameGraph pour se rendre au point de contrôle.
![\[Utilisation des graphiques en flamme\]](http://docs.aws.amazon.com/fr_fr/managed-flink/latest/java/images/checkpoint3.png)
Il s'agit d'un graphique en flammes très simple qui montre que tout le temps du processeur est consacré à un seul coup `processElement` d'œil à l' ExpensiveFunction opérateur. Vous obtenez également le numéro de ligne qui aide à déterminer l’endroit où l’exécution du code a lieu.
# Le délai du point de contrôle est expiré
Si votre application n’est pas optimisée ou correctement provisionnée, les points de contrôle peuvent échouer. Cette section décrit les symptômes et les étapes de résolution de ce problème.
## Symptômes
Si les points de contrôle échouent pour votre application, le `numberOfFailedCheckpoints` sera supérieur à zéro.
Les points de contrôle peuvent échouer soit en raison de d’échecs directs, telles que des erreurs d’application, soit en raison d’échecs temporaires, tels que l’épuisement des ressources de l’application. Vérifiez les journaux et les métriques de votre application pour détecter les symptômes suivants :
+ Des erreurs dans votre code.
+ Des erreurs lors de l’accès aux services dépendants de votre application.
+ Des erreurs lors de la sérialisation des données. Si le sérialiseur par défaut ne parvient pas à sérialiser les données de votre application, celle-ci échouera. Pour plus d'informations sur l'utilisation d'un sérialiseur personnalisé dans votre application, consultez la section [Types de données et sérialisation dans la documentation](https://nightlies.apache.org/flink/flink-docs-release-1.19/docs/dev/datastream/fault-tolerance/serialization/types_serialization/) d'Apache Flink.
+ Erreurs de mémoire insuffisante.
+ Des pics ou des augmentations constantes des métriques suivantes :
+ `heapMemoryUtilization`
+ `oldGenerationGCTime`
+ `oldGenerationGCCount`
+ `lastCheckpointSize`
+ `lastCheckpointDuration`
Pour plus d'informations sur la surveillance des points de contrôle, consultez la section [Surveillance des points de contrôle dans la](https://nightlies.apache.org/flink/flink-docs-release-1.19/docs/ops/monitoring/checkpoint_monitoring/) documentation d'Apache Flink.
## Causes et solutions
Les messages d’erreur du journal de votre application indiquent la cause des échecs directs. Les échecs temporaires peuvent avoir les causes suivantes :
+ Le provisionnement en KPU de votre application est insuffisant. Pour obtenir des informations sur l’augmentation du provisionnement de l’application, consultez [Mettre en œuvre le dimensionnement des applications](how-scaling.md).
+ La taille de l’état de votre application est trop grande. Vous pouvez surveiller la taille de l’état de votre application à l’aide de la métrique `lastCheckpointSize`.
+ Les données d’état de votre application sont réparties de manière inégale entre les clés. Si votre application utilise l’opérateur `KeyBy`, assurez-vous que les données entrantes sont réparties de manière égale entre les clés. Si la plupart des données sont attribuées à une seule clé, cela crée un goulot d’étranglement, qui entraînera des échecs.
+ Votre application est confrontée à une contre-pression liée à la mémoire ou au récupérateur de mémoire. Vérifiez s’il y a des pics ou des augmentations constantes des valeurs `heapMemoryUtilization`, `oldGenerationGCTime` et `oldGenerationGCCount`.
# Échec de point de contrôle pour l’application Apache Beam
Si votre application Beam est configurée avec une valeur [shutdownSourcesAfterIdleMs](https://beam.apache.org/documentation/runners/flink/#:~:text=shutdownSourcesAfterIdleMs)définie sur 0 ms, les points de contrôle peuvent ne pas se déclencher car les tâches sont à l'état « TERMINÉ ». Cette section décrit les symptômes et la résolution de ce problème.
## Symptôme
Accédez aux CloudWatch journaux de votre application Managed Service for Apache Flink et vérifiez si le message de journal suivant a été enregistré. Le message de journal suivant indique que le point de contrôle n’a pas pu être déclenché, car certaines tâches sont terminées.
```
{
"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"
}
```
Vous pouvez également le voir sur le tableau de bord de Flink, où certaines tâches sont passées à l’état « TERMINÉ » et où le point de contrôle n’est plus possible.
![\[Tâches à l’état « TERMINÉ »\]](http://docs.aws.amazon.com/fr_fr/managed-flink/latest/java/images/beam_checkpoint_failure.png)
## Cause
shutdownSourcesAfterIdleMs est une variable de configuration Beam qui arrête les sources qui sont restées inactives pendant la durée configurée de millisecondes. Une fois qu’une source a été fermée, le point de contrôle n’est plus possible. Cela pourrait entraîner un [échec du point de contrôle](https://issues.apache.org/jira/browse/FLINK-2491).
L'une des raisons pour lesquelles les tâches passent à l'état « TERMINÉ » shutdownSourcesAfter IdleMs est lorsqu'elle est définie sur 0 ms, ce qui signifie que les tâches inactives seront immédiatement arrêtées.
## Solution
Pour empêcher les tâches de passer immédiatement à l'état « TERMINÉ », définissez ce paramètre sur shutdownSourcesAfter IdleMs Long.MAX\$1VALUE. Vous pouvez effectuer cette opération de deux façons :
+ Option 1 : Si la configuration de votre faisceau est définie sur la page de configuration de votre application Managed Service for Apache Flink, vous pouvez ajouter une nouvelle paire clé-valeur pour définir shutdpwnSourcesAfteridle Ms comme suit :
![\[Défini sur shutdownSourcesAfter IdleMs Long.MAX_VALUE\]](http://docs.aws.amazon.com/fr_fr/managed-flink/latest/java/images/beam_checkpoint_failure_solution.png)
+ Option 2 : Si la configuration de votre faisceau est définie dans votre fichier JAR, vous pouvez définir shutdownSourcesAfter IdleMs comme suit :
```
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
```
# Contre-pression
Flink utilise la contre-pression pour adapter la vitesse de traitement de chaque opérateur.
L’opérateur peut avoir du mal à traiter le volume de messages qu’il reçoit pour de nombreuses raisons. L'opération peut nécessiter plus de ressources CPU que celles dont dispose l'opérateur. L'opérateur peut attendre la fin I/O des opérations. Si un opérateur ne parvient pas à traiter les événements assez rapidement, cela crée une contre-pression chez les opérateurs en amont qui alimentent l’opérateur lent. Cela ralentit les opérateurs en amont, ce qui peut propager davantage la contre-pression vers la source et amener la source à s’adapter au débit global de l’application en ralentissant également. Vous trouverez une description plus détaillée de la contre-pression et de son fonctionnement dans [How Apache Flink™ handles backpressure](https://www.ververica.com/blog/how-flink-handles-backpressure).
Le fait de savoir quels opérateurs d’une application sont lents vous fournit des informations cruciales pour comprendre la cause première des problèmes de performances de l’application. Les informations sur la contre-pression sont [affichées via le tableau de bord Flink](https://nightlies.apache.org/flink/flink-docs-stable/docs/ops/monitoring/back_pressure/). Pour identifier l’opérateur lent, recherchez l’opérateur présentant une valeur de contre-pression élevée qui est le plus proche d’un récepteur (l’opérateur B dans l’exemple suivant). L’opérateur à l’origine de la lenteur est alors l’un des opérateurs en aval (l’opérateur C dans l’exemple). L’opérateur B peut traiter les événements plus rapidement, mais il est soumis à une contre-pression, car il ne peut pas transmettre le résultat à l’opérateur C lent.
```
A (backpressured 93%) -> B (backpressured 85%) -> C (backpressured 11%) -> D (backpressured 0%)
```
Une fois que vous avez identifié l’opérateur lent, essayez de comprendre pourquoi il est lent. Il peut y avoir une multitude de raisons. Parfois, le problème n’est pas évident et peut nécessiter plusieurs jours de débogage et de profilage pour être résolu. Voici quelques raisons évidentes et courantes, dont certaines sont expliquées plus en détail ci-dessous :
+ L’opérateur effectue des opérations d’I/O lentes, par exemple des appels réseau (pensez plutôt à utiliser AsyncIO à la place).
+ Les données sont biaisées et un opérateur reçoit plus d'événements que les autres (vérifiez en examinant le nombre de messages relatifs à des sous-tâches individuelles (c'est-à-dire in/out des instances du même opérateur) dans le tableau de bord Flink.
+ Il s'agit d'une opération gourmande en ressources (s'il n'y a pas de distorsion des données, envisagez de l'étendre pour le travail CPU/memory limité ou d'augmenter `ParallelismPerKPU` pour le travail I/O lié)
+ Journalisation étendue dans l’opérateur (réduisez la journalisation au minimum pour les applications de production ou envisagez plutôt d’envoyer les résultats de débogage vers un flux de données).
## Débit de test avec l'évier de mise au rebut
[Discarding Sink](https://nightlies.apache.org/flink/flink-docs-stable/api/java/org/apache/flink/streaming/api/functions/sink/DiscardingSink.html) ignore simplement tous les événements qu’il reçoit pendant l’exécution de l’application (une application sans récepteur ne s’exécute pas). Cela est très utile pour les tests de débit, le profilage et pour vérifier si l’application est correctement mise à l’échelle. Il s’agit également d’un contrôle de santé très pragmatique pour vérifier si les récepteurs sont à l’origine de la contre-pression ou cela vient de l’application (mais il est souvent plus facile et plus simple de vérifier les métriques de contre-pression).
En remplaçant tous les récepteurs d’une application par un récepteur de rejet et en créant une source fictive qui génère des données similaires aux données de production, vous pouvez mesurer le débit maximal de l’application pour un certain paramètre de parallélisme. Vous pouvez également augmenter le parallélisme pour vérifier que l’application évolue correctement et qu’elle ne présente pas de goulot d’étranglement qui n’apparaît qu’à un débit plus élevé (par exemple, en raison d’une asymétrie de données).
# Asymétrie de données
Une application Flink est exécutée sur un cluster de manière distribuée. Pour s’étendre à plusieurs nœuds, Flink utilise le concept de flux liés à une clé, ce qui signifie essentiellement que les événements d’un flux sont partitionnés en fonction d’une clé spécifique, par exemple l’identifiant du client, et Flink peut ensuite traiter différentes partitions sur différents nœuds. De nombreux opérateurs Flink sont ensuite évalués en fonction de ces partitions, par exemple [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/) et [Async I/O](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/asyncio/).
Le choix d’une clé de partition dépend souvent de la logique métier. Dans le même temps, bon nombre des bonnes pratiques, par exemple pour [DynamoDB](https://aws.amazon.com/dynamodb/) et Spark, s’appliquent également à Flink, notamment :
+ garantir une cardinalité élevée des clés de partition ;
+ éviter toute asymétrie du volume d’événements entre les partitions.
Vous pouvez identifier l'asymétrie dans les partitions en comparant les enregistrements received/sent des sous-tâches (c'est-à-dire les instances du même opérateur) dans le tableau de bord Flink. En outre, la surveillance du service géré pour Apache Flink peut également être configurée pour exposer des métriques au niveau de `numRecordsIn/Out` et `numRecordsInPerSecond/OutPerSecond` au niveau des sous-tâches.
# Asymétrie d’état
Pour les opérateurs dynamiques, c’est-à-dire les opérateurs qui maintiennent l’état de leur logique métier, comme les fenêtres, l’asymétrie de données entraîne toujours une asymétrie d’état. Certaines sous-tâches reçoivent plus d’événements que d’autres en raison de l’asymétrie des données et conservent donc un plus grand nombre de données dans leur état. Cependant, même pour une application dont les partitions sont équilibrées, il peut y avoir une asymétrie dans la quantité de données conservées dans leur état. Par exemple, pour les fenêtres de session, certains utilisateurs et certaines sessions peuvent respectivement être beaucoup plus longs que d’autres. Si les sessions les plus longues font partie de la même partition, cela peut entraîner un déséquilibre de la taille des états conservés par les différentes sous-tâches du même opérateur.
L’asymétrie d’état augmente non seulement la mémoire et les ressources disque requises par les sous-tâches individuelles, mais elle peut également diminuer les performances globales de l’application. Lorsqu’une application atteint un point de contrôle ou un point de sauvegarde, l’état de l’opérateur est conservé dans Amazon S3, afin de protéger l’état contre l’échec d’un nœud ou d’un cluster. Au cours de ce processus (en particulier avec la sémantique « pile une fois » activée par défaut sur Managed Service for Apache Flink), le traitement s'arrête d'un point de vue externe jusqu'à ce qu'il soit terminé. checkpoint/savepoint En cas d’asymétrie des données, le temps nécessaire pour terminer l’opération peut être limité par une seule sous-tâche ayant accumulé un nombre d’états particulièrement élevé. Dans les cas extrêmes, l' checkpoints/savepoints exécution peut échouer parce qu'une seule sous-tâche ne parvient pas à conserver son état.
Tout comme l’asymétrie de données, l’asymétrie d’état peut considérablement ralentir une application.
Pour identifier une asymétrie d’état, vous pouvez utiliser le tableau de bord Flink. Trouvez un point de contrôle ou de sauvegarde récent et comparez la quantité de données stockées pour chaque sous-tâche dans les détails.
# Intégrez les ressources de différentes régions
Vous pouvez activer l’utilisation de `StreamingFileSink` pour écrire dans un compartiment Amazon S3 situé dans une région différente de celle de votre application de service géré pour Apache Flink via un paramètre requis pour la réplication entre régions dans la configuration Flink. Pour ce faire, envoyez un ticket d’assistance au [Centre AWS Support](https://console.aws.amazon.com/support/home#/).