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.

• /aws-glue/ray/jobs/script-log/ : stocke les journaux émis par votre script Ray principal.

• /aws-glue/ray/jobs/ray-monitor-log/ : stocke les journaux émis par le processus de scalabilité automatique Ray. Ces journaux sont générés pour le nœud principal et non pour les autres composants master.

• /aws-glue/ray/jobs/ray-gcs-logs/ : stocke les journaux émis par le processus GCS (global control store). Ces journaux sont générés pour le nœud principal et non pour les autres composants master.

• /aws-glue/ray/jobs/ray-process-logs/ : stocke les journaux émis par d'autres processus Ray (principalement l'agent du tableau de bord) exécutés sur le nœud principal. Ces journaux sont générés pour le nœud principal et non pour les autres composants master.

• /aws-glue/ray/jobs/ray-raylet-logs/ : stocke les journaux émis par chaque processus raylet. Ces journaux sont collectés dans un flux unique pour chaque composant master, y compris le nœud principal.

• /aws-glue/ray/jobs/ray-worker-out-logs/ : stocke les journaux stdout pour chaque travail du cluster. Ces journaux sont générés pour chaque composant master, y compris le nœud principal.

• /aws-glue/ray/jobs/ray-worker-err-logs/ : stocke les journaux stderr pour chaque travail du cluster. Ces journaux sont générés pour chaque composant master, y compris le nœud principal.

• /aws-glue/ray/jobs/ray-runtime-env-log/ : stocke les journaux relatifs au processus de configuration Ray. Ces journaux sont générés pour chaque composant master, y compris le nœud principal.

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 :

• Le nombre de processus qui émettent des journaux peut être supérieur au nombre de travaux qui sont alloués à la tâche. Souvent, chaque cœur de chaque instance comporte un acteur.

• Les nœuds principaux Ray émettent des journaux de gestion et de démarrage du cluster. En revanche, les composants master Ray émettent uniquement des journaux pour le travail qui les concerne.

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