Pourquoi mon application Amazon Managed Service pour Apache Flink redémarre-t-elle ?

Résolution

Lorsqu'une tâche échoue, l'application Apache Flink redémarre la tâche qui a échoué et les autres tâches concernées pour ramener la tâche à un état normal.

Voici quelques-unes des causes et des étapes de dépannage de ce problème.

Erreurs de code

Les erreurs de code, telles que le type NullPointerException et DataCast, sont générées dans le gestionnaire de tâches et aboutissent dans le gestionnaire de tâches. L'application est ensuite redémarrée à partir du dernier point de contrôle. Pour détecter les redémarrages de l'application en raison d'exceptions non gérées dans l'application, vérifiez les métriques Amazon CloudWatch tels que la durée d’indisponibilité. Cette métrique affiche une valeur différente de zéro pendant les périodes de redémarrage. Pour identifier la cause de ce problème, interrogez vos journaux d’applications pour connaître les modifications apportées à l'état de votre application, passant de EN COURS D’EXÉCUTION à ÉCHEC. Pour plus d'informations, consultez la section Analyser les erreurs : Échecs liés aux tâches d'application.

Exceptions de mémoire insuffisante

Lorsque vous recevez des exceptions de mémoire insuffisante, le gestionnaire de tâches ne peut pas envoyer de signaux cardiaques sains au gestionnaire de tâches et l'application redémarre. Dans ce cas, les journaux d’application peuvent contenir des erreurs, telles que TimeoutException, FlinkException ou RemoteTransportException.

Vérifiez si l'application est surchargée en raison d’une pression sur le processeur ou les ressources mémoire :

• Assurez-vous que les métriques CloudWatch fullRestarts et downtime présentent des valeurs différentes de zéro.
• Vérifiez les métriques cpuUtilization et heapMemoryUtilization pour détecter des pics inhabituels.
• Vérifiez la présence d'exceptions non gérées dans votre code d’application.
• Vérifiez les échecs de point de contrôle et de sauvegarde. Surveillez les métriques CloudWatch numOFFailedCheckpoints, lastCheckpointSize et lastCheckpointDuration pour détecter des pics et des augmentations progressives.

Pour résoudre les pics et les augmentations progressives, procédez comme suit :

• Si vous avez activé les journaux de débogage pour l'application, l'utilisation des ressources de l'application peut être élevée. Pour réduire la quantité de journalisation, activez temporairement les journaux de débogage uniquement lorsque vous étudiez des problèmes.
• Analysez le vidage de thread TaskManager dans le tableau de bord Apache Flink. Par exemple, vous pouvez identifier les processus gourmands en ressources processeur à partir du vidage du thread.
• Pour passer en revue les graphiques en flamme qui sont construits, échantillonnez plusieurs fois les traces de pile. Pour vérifier les appels bloqués, utilisez les graphiques en flamme hors processeur. Pour plus d'informations sur les graphiques en flamme, consultez la section Graphiques en flamme sur le site Web d'Apache Flink.

Erreurs de limitation

Si votre application sous-provisionne une source ou un récepteur, elle peut rencontrer des erreurs de limitation lors de la lecture et de l'écriture sur des services de streaming, tels que Kinesis Data Streams. Ce problème peut entraîner un accident d’application. Pour vérifier le débit de la source et du récepteur, utilisez des métriques CloudWatch telles que WriteProvisionedThroughputExceeded et ReadProvisionedThroughputExceeded. Pour tenir compte du volume de données, augmentez le nombre de partitions pour augmenter vos flux de données.

Erreurs de délai d’attente

Le FlinkKinesisProducer utilise la bibliothèque Amazon Kinesis Producer Library (KPL) pour placer les données d'un flux Flink dans un flux de données Kinesis. Une erreur de délai d’attente peut provoquer des échecs du KPL susceptibles de provoquer le redémarrage de l'application Flink. Dans ce cas, vous pourriez constater une augmentation du temps de mise en mémoire tampon et du nombre de nouvelles tentatives. Vous pouvez modifier les configurations RecordMaxBufferedTime, RecordTtl et RequestTimeout pour le KPL afin que l'enregistrement n'expire pas. Pour plus d'informations, consultez la section default_config.properties sur le site Web de GitHub. Surveillez également les métriques KPL importantes, telles que ErrorsByCode, RetriesPerRecord et UserRecordsPending. Lorsque ces mesures indiquent que l'application a redémarré, utilisez les filtres de CloudWatch Logs Insights pour identifier les échecs qui ont provoqué le redémarrage de l'application.

Notez que toutes les erreurs n'entraînent pas un redémarrage immédiat de l'application. Par exemple, des erreurs dans le code d'application peuvent entraîner une erreur de flux de travail de graphe acyclique dirigé (DAG). Dans ce cas, le DAG de votre application n'est pas créé. L'application s'arrête et ne redémarre pas immédiatement. De plus, l'application ne redémarre pas immédiatement lorsqu’une erreur Accès refusé s’affiche.

Si le problème persiste, contactez AWS Support et fournissez les informations suivantes :

• ARN de l'application
• Informations sur la source et le récepteur de votre application
• Journaux CloudWatch pour votre application
• Heure d'émission en UTC
• Vidages de thread pertinents depuis le tableau de bord Apache Flink

Informations connexes

L'application est en cours de redémarrage