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.

Dépannage des erreurs AWS Glue pour Ray liées aux journaux

AWS Glue permet d'accéder aux journaux émis par les processus Ray lors de l'exécution de la tâche. En cas d'erreurs ou de comportements inattendus dans les tâches Ray, collectez d'abord des informations à partir des journaux pour déterminer la cause de l'échec. Nous fournissons également des journaux similaires pour les sessions interactives. Les journaux de sessions sont identifiables par le préfixe /aws-glue/ray/sessions.

Les lignes de journal sont envoyées à CloudWatch en temps réel, au fur et à mesure de l'exécution de votre tâche. Les instructions d'impression sont ajoutées aux journaux CloudWatch une fois l'exécution terminée. Les journaux sont conservés pendant deux semaines après l'exécution d'une tâche.

Inspection des journaux de tâches Ray

Lorsqu'une tâche échoue, collectez le nom et l'ID d'exécution de celle-ci. Vous les trouverez dans la console AWS Glue. Accédez à la page de la tâche, puis à l'onglet Runs (Exécutions). Les journaux des tâches Ray sont stockés dans les groupes de journaux CloudWatch dédiés suivants.

Résolution des erreurs liées aux tâches Ray

Pour comprendre l'organisation des groupes de journaux Ray et identifier les groupes de journaux qui vous aideront à résoudre vos erreurs, vous devez disposer d'informations de base sur l'architecture Ray.

Dans AWS Glue ETL, un travail correspond à une instance. Lorsque vous configurez des travaux pour une tâche AWS Glue, vous définissez le type et la quantité d'instances dédiées à cette tâche. Ray utilise le terme travail de différentes manières.

Ray utilise le nœud principal et le composant master pour distinguer les responsabilités d'une instance au sein d'un cluster Ray. Un composant master Ray peut héberger plusieurs processus acteurs qui effectuent des calculs afin d'obtenir le résultat de vos calculs distribués. Les acteurs qui exécutent une réplique d'une fonction sont appelés réplicas. Les réplicas d'acteurs peuvent également être appelés processus de travail. Les réplicas peuvent également s'exécuter sur le nœud principal, connu sous le nom de tête, car il exécute des processus supplémentaires pour coordonner le cluster.

Chaque acteur qui contribue à votre calcul génère son propre flux de journaux. Ce scénario nous donne quelques informations :

Pour plus d'informations sur l'architecture Ray, consultez Architecture Whitepapers (Livres blancs sur l'architecture) dans la documentation Ray.

Problème : accès à Amazon S3

Vérifiez le message d'échec de la tâche exécutée. Si ce dernier ne fournit pas suffisamment d'informations, vérifiez /aws-glue/ray/jobs/script-log/.

Problème : gestion de la dépendance PIP

Vérifiez /aws-glue/ray/jobs/ray-runtime-env-log/.

Problème : inspection des valeurs intermédiaires dans le processus principal

Écrivez dans stderr ou stdout depuis votre script principal, et récupérez les journaux dans /aws-glue/ray/jobs/script-log/.

Problème : inspection des valeurs intermédiaires dans un processus enfant

Écrivez dans stderr ou stdout depuis votre fonction remote. Récupérez ensuite les journaux depuis /aws-glue/ray/jobs/ray-worker-out-logs/ ou /aws-glue/ray/jobs/ray-worker-err-logs/. Votre fonction a pu être exécutée sur n'importe quel réplica. Vous pouvez donc être amené à examiner plusieurs journaux pour identifier la sortie souhaitée.

Problème : interprétation des adresses IP dans les messages d'erreur

Dans certaines situations d'erreur, votre tâche peut émettre un message d'erreur contenant une adresse IP. Ces adresses IP sont éphémères et sont utilisées par le cluster pour identifier les nœuds et communiquer entre eux. Les journaux d'un nœud seront publiés dans un flux de journaux avec un suffixe unique basé sur l'adresse IP.

Dans CloudWatch, vous pouvez filtrer vos journaux pour inspecter ceux spécifiques à cette adresse IP en identifiant ce suffixe. Par exemple, pour FAILED_IP et JOB_RUN_ID, vous pouvez identifier le suffixe avec :

filter @logStream like /JOB_RUN_ID/
| filter @message like /IP-/
| parse @message "IP-[*]" as ip
| filter ip like /FAILED_IP/
| fields replace(ip, ":", "_") as uIP
| stats count_distinct by uIP as logStreamSuffix
| display logStreamSuffix