Solución de problemas AWS Glue de errores de Ray en los registros

AWS Glue proporciona acceso a los registros emitidos por los procesos de Ray durante la ejecución del trabajo. Si encuentra errores o un comportamiento inesperado en los trabajos de Ray, recopile antes información de los registros para determinar la causa del error. También proporcionamos registros similares para sesiones interactivas. Los registros de sesiones se proporcionan con el prefijo /aws-glue/ray/sessions.

Las líneas de registro se envían a CloudWatch en tiempo real, a medida que se ejecuta el trabajo. Las declaraciones de impresión se adjuntan a los registros de CloudWatch una vez finalizada la ejecución. Los registros se conservan durante dos semanas después de ejecutar un trabajo.

Inspección de los registros de trabajos de Ray

Cuando se produce un error en un trabajo, recopile el nombre del trabajo y el identificador de ejecución del trabajo. Puede encontrarlos en la consola de AWS Glue. Vaya a la página del trabajo y, a continuación, vaya a la pestaña Runs (Ejecuciones). Los registros de trabajos de Ray se almacenan en los siguientes grupos de registros dedicados de CloudWatch.

• /aws-glue/ray/jobs/script-log/: almacena los registros emitidos por su script principal de Ray.

• /aws-glue/ray/jobs/ray-monitor-log/: almacena los registros emitidos por el proceso del escalador automático de Ray. Estos registros se generan para el nodo principal y no para otros nodos de trabajo.

• /aws-glue/ray/jobs/ray-gcs-logs/: Almacena los registros emitidos por el proceso GCS (almacenamiento de control global). Estos registros se generan para el nodo principal y no para otros nodos de trabajo.

• /aws-glue/ray/jobs/ray-process-logs/: Almacena los registros emitidos por otros procesos de Ray (principalmente el agente del panel de control) que se ejecutan en el nodo principal. Estos registros se generan para el nodo principal y no para otros nodos de trabajo.

• /aws-glue/ray/jobs/ray-raylet-logs/: Almacena los registros emitidos por cada proceso de raylet. Estos registros se recopilan en una sola secuencia para cada nodo de trabajo, incluido el nodo principal.

• /aws-glue/ray/jobs/ray-worker-out-logs/: Almacena los registros stdout de cada proceso de trabajo en el clúster. Estos registros se generan para cada nodo de trabajo, incluido el nodo principal.

• /aws-glue/ray/jobs/ray-worker-err-logs/: Almacena los registros stderr de cada proceso de trabajo en el clúster. Estos registros se generan para cada nodo de trabajo, incluido el nodo principal.

• /aws-glue/ray/jobs/ray-runtime-env-log/: Almacena los registros sobre el proceso de configuración de Ray. Estos registros se generan para cada nodo de trabajo, incluido el nodo principal.

Solución de errores de trabajos de Ray

Para entender la organización de los grupos de registro de Ray y encontrar los grupos de registro que ayudarán a solucionar los errores, es útil disponer de información básica sobre la arquitectura de Ray.

En ETL de AWS Glue, un proceso de trabajo corresponde a una instancia. Al configurar procesos de trabajo para un trabajo de AWS Glue, se establece el tipo y la cantidad de instancias dedicadas al trabajo. Ray utiliza el término proceso de trabajo de diferentes maneras.

Ray usa el nodo principal y el nodo de trabajo para distinguir las responsabilidades de una instancia en un clúster de Ray. Un nodo de trabajo de Ray puede alojar procesos de varios actores que hacen cálculos para lograr el resultado de su cálculo distribuido. Los actores que ejecutan una réplica de una función se denominan réplicas. Los actores de réplica también se pueden denominar procesos de trabajo. Las réplicas también se pueden ejecutar en el nodo principal, que se conoce como el principal porque ejecuta procesos adicionales para coordinar el clúster.

Cada actor que contribuye al cálculo genera su propio flujo de registro. Esto nos proporciona un poco de información:

• La cantidad de procesos que emiten registros puede ser mayor que la cantidad de procesos de trabajo asignados al trabajo. A menudo, cada núcleo de cada instancia tiene un actor.

• Los nodos principales de Ray emiten registros de inicio y administración de clústeres. Por el contrario, los nodos de trabajo de Ray solo emiten registros del trabajo hecho en ellos.

Para más información acerca de la arquitectura de Ray, consulte Architecture Whitepapers (Documentos técnicos sobre la arquitectura) en la documentación de Ray.

Área del problema: acceso a Amazon S3

Compruebe el mensaje de error de la ejecución del trabajo. Si eso no proporciona suficiente información, compruebe /aws-glue/ray/jobs/script-log/.

Área del problema: administración de dependencias de PIP

Compruebe /aws-glue/ray/jobs/ray-runtime-env-log/.

Área del problema: inspección de valores intermedios en el proceso principal

Escriba a stderr o stdout desde su script principal y recupere los registros de /aws-glue/ray/jobs/script-log/.

Área del problema: inspección de valores intermedios en un proceso secundario

Escriba a stderr o stdout desde su función remote. A continuación, recupere los registros de /aws-glue/ray/jobs/ray-worker-out-logs/ o /aws-glue/ray/jobs/ray-worker-err-logs/. Es posible que la función se haya ejecutado en cualquier réplica, por lo que es posible que tenga que examinar varios registros para encontrar el resultado deseado.

Área problemática: interpretación de las direcciones IP en los mensajes de error

En determinadas situaciones de error, es posible que su trabajo emita un mensaje de error que contenga una dirección IP. Estas direcciones IP son efímeras y el clúster las utiliza para identificar los nodos y comunicarse entre ellos. Los registros de un nodo se publicarán en un flujo de registros con un sufijo único basado en la dirección IP.

En CloudWatch, puede filtrar los registros para inspeccionar los específicos de esta dirección IP a través de la identificación de este sufijo. Por ejemplo, si utiliza FAILED_IP y JOB_RUN_ID, puede identificar el sufijo con:

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