Pourquoi mon application Amazon Kinesis Data Analytics redémarre-t-elle ?

Solution

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

Voici certaines des causes et des étapes de dépannage correspondantes pour cette condition :

• Les erreurs de code, telles que l'exception NullPointer et le type DataCast, sont générées au niveau du gestionnaire d'affaires et transmises au gestionnaire de tâches. L'application est ensuite redémarrée à partir du dernier point de contrôle. Pour détecter les redémarrages d'applications en raison d'exceptions non gérées dans l'application, consultez les métriques Amazon CloudWatch, telles que les temps d'arrêt. Cette métrique affiche une valeur différente de zéro pendant les périodes de redémarrage. Pour identifier les causes de cette condition, interrogez les journaux de votre application afin de connaître les modifications de l'état de votre application de RUNNING (EN COURS D'EXÉCUTION) à FAILED (ÉCHEC). Pour plus d'informations, voir Analyser les erreurs : échecs liés aux tâches de l'application.

• Lorsque vous recevez des exceptions de mémoire insuffisante, le gestionnaire de tâches ne peut pas envoyer de signaux Heartbeat sains au responsable des tâches, ce qui entraîne un redémarrage de l'application. Dans ce cas, vous pouvez voir des erreurs telles que TimeoutException, FlinkException ou RemoteTransportException dans les journaux de l'application. Vérifiez si l'application est surchargée en raison de la pression des ressources du processeur ou de la mémoire.

  • Assurez-vous que les métriques CloudWatch fullRestarts et temps d'arrêt ont des valeurs différentes de zéro.
  • Vérifiez les métriques cpuUtilization et heapMemoryUtilization pour détecter les pics inhabituels.
  • Vérifiez les exceptions non gérées dans votre code d'application.
  • Vérifiez les points de contrôle et les points de sauvegarde défaillants. Surveillez les métriques CloudWatchnumOFFailedCheckpoints, lastCheckpointSize et lastCheckpointDuration pour détecter les pics et les augmentations de stabilité.
    Pour résoudre ce problème, suivez les étapes ci-dessous :
  • Si vous avez activé les journaux de débogage pour l'application, la consommation des ressources de l'application peut être élevée. Réduisez la quantité de journalisation en activant temporairement les journaux de débogage uniquement lors de la recherche de problèmes.
  • Analysez le thread dump du gestionnaire de tâches dans le tableau de bord Apache Flink. Par exemple, vous pouvez identifier les processus à forte intensité du processeur à partir du thread dump.
  • Passez en revue les graphiques Flame qui sont construits en échantillonnant les traces de la pile plusieurs fois. Vous pouvez utiliser les graphiques Flame pour effectuer les opérations suivantes : visualiser l'état général de l'application, identifier les méthodes qui consomment le plus de ressources du processeur et identifier la série d'appels sur la pile qui ont entraîné l'exécution d'une méthode particulière. Vérifiez les appels bloqués à l'aide des graphiques Flame hors processeur.

• Si votre application n'approvisionne pas suffisamment 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. Cette condition peut éventuellement entraîner un plantage de l'application. Vérifiez le débit de la source et du récepteur à l'aide des métriques CloudWatch telles queWriteProvisionedThroughputExceeded et ReadProvisionedThroughputExceeded. Pensez à augmenter vos flux de données pour adapter au volume de donnéesen augmentant le nombre de partitions.

• Le FlinkKinesisProducer utilise la bibliothèque Kinesis Producer Library (KPL) pour placer les données d'un flux Flink vers un flux de données Kinesis. Les erreurs, telles que le délai d'expiration, provoquent des défaillances dans KPL qui peuvent éventuellement entraîner le redémarrage de l'application Flink. Dans ce cas, vous pouvez constater une augmentation du temps de mise en mémoire tampon et du nombre de nouvelles tentatives. Vous pouvez régler les configurations suivantes pour KPL de telle sorte que le registre n'expire pas : RecordMaxBufferedTime, RecordTTL et RequestTimeout. Surveillez également les métriques KPL importantes telles que ErrorsByCode,RetriesPerRecord et UserRecordSpending. Lorsque ces métriques indiquent que l'application redémarre, utilisez les filtres de CloudWatch Logs Insights pour connaître les raisons exactes des erreurs qui ont entraîné le redémarrage.

• 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 l'erreur du flux de travail DAG. Dans ce cas, le graphe acyclique dirigé (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 lorsque vous recevez une erreur « Accès refusé ».

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 au format UTC
• Thread dumps pertinents depuis le tableau de bord Flink

Informations connexes

L'application est en cours de redémarrage