ログから AWS Glue for Ray エラーをトラブルシューティングする - AWS Glue

ログから AWS Glue for Ray エラーをトラブルシューティングする

AWS Glue では、ジョブの実行中に Ray プロセスが生成するログにアクセス可能です。Ray ジョブでエラーや予期しない動作が発生した場合は、まずログから情報を収集して失敗の原因を特定します。また、インタラクティブセッションについても同様のログが提供されています。セッションのログは、先頭に /aws-glue/ray/sessions が付きます。

ジョブの実行時、ログの行はリアルタイムで CloudWatch に送信されます。実行が完了すると、Print ステートメントが CloudWatch ログに追加されます。ログはジョブの実行後 2 週間保持されます。

Ray ジョブのログを検査する

ジョブが失敗した場合は、ジョブ名とジョブ実行 ID を収集します。これらは AWS Glue コンソールで確認できます。ジョブページに移動し、[Runs] (実行) タブに移動します。Ray ジョブのログは、次の専用の CloudWatch ロググループに保存されます。

  • /aws-glue/ray/jobs/script-log/ — メインの Ray スクリプトが生成するログを保存します。

  • /aws-glue/ray/jobs/ray-monitor-log/ — Ray のオートスケーラープロセスが生成するログを保存します。これらのログはヘッドノードについて生成され、他のワーカーノードでは生成されません。

  • /aws-glue/ray/jobs/ray-gcs-logs/ – GCS (グローバルコントロールストア) プロセスから出力されたログを保存します。これらのログはヘッドノードについて生成され、他のワーカーノードでは生成されません。

  • /aws-glue/ray/jobs/ray-process-logs/ – ヘッドノードで実行されている他の Ray プロセス (主にダッシュボードエージェント) から出力されたログを保存します。これらのログはヘッドノードについて生成され、他のワーカーノードでは生成されません。

  • /aws-glue/ray/jobs/ray-raylet-logs/ – 各 raylet プロセスから出力されたログを保存します。これらのログは、ワーカーノード (ヘッドノードを含む) ごとに 1 つのストリームにまとめられます。

  • /aws-glue/ray/jobs/ray-worker-out-logs/ – クラスター内の各ワーカーの stdout ログを保存します。これらのログは、ワーカーノード (ヘッドノードを含む) ごとに生成されます。

  • /aws-glue/ray/jobs/ray-worker-err-logs/ – クラスター内の各ワーカーの stderr ログを保存します。これらのログは、ワーカーノード (ヘッドノードを含む) ごとに生成されます。

  • /aws-glue/ray/jobs/ray-runtime-env-log/ – Ray のセットアッププロセスに関するログを保存します。これらのログは、ワーカーノード (ヘッドノードを含む) ごとに生成されます。

Ray ジョブのエラーをトラブルシューティングする

Ray のロググループの構成を理解し、エラーのトラブルシューティングの助けになるロググループを見つけるには、Ray のアーキテクチャに関する背景情報があると役立ちます。

AWS Glue ETL では、ワーカーはインスタンスに対応します。AWS Glue ジョブのワーカーを設定する際は、そのジョブ専用のインスタンスタイプおよびインスタンス数を設定します。Ray では、ワーカーという単語がさまざまな形で使われています。

Ray は、ヘッドノードとワーカーノードを使用して、Ray クラスター内のインスタンスの役割を区別します。Ray のワーカーノードは、分散計算の結果を得るため計算を実行する、複数のアクタープロセスをホストできます。関数のレプリカを実行するアクターはレプリカと呼ばれます。レプリカのアクターはワーカープロセスとも呼ばれます。レプリカはヘッドノードでも実行できます。ヘッドノードは、追加のプロセスを実行してクラスターを調整することから、ヘッドと呼ばれます。

計算に関与する各アクターは、独自のログストリームを生成します。これにより、いくつかのインサイトが得られます。

  • ログを生成するプロセスの数は、ジョブに割り当てられるワーカーの数よりも多い場合があります。多くの場合、各インスタンスのコアには 1 つのアクターがあります。

  • Ray のヘッドノードは、クラスターの管理および起動ログを生成します。それに対して Ray のワーカーノードは、そのノードで実行される処理のログのみを生成します。

Ray のアーキテクチャの詳細については、Ray のドキュメントの「Architecture Whitepapers」(アーキテクチャホワイトペーパー) を参照してください。

問題の領域: Amazon S3 へのアクセス

ジョブ実行のエラーメッセージを確認します。それでも十分な情報が得られない場合は、/aws-glue/ray/jobs/script-log/ を確認します。

問題領域: PIP の依存性の管理

/aws-glue/ray/jobs/ray-runtime-env-log/ をチェックします。

問題の領域: メインプロセスにおける中間値の検査

メインスクリプトから stderr または stdout に書き込みを行います。また、/aws-glue/ray/jobs/script-log/ からログを取得します。

問題の領域: 子プロセスにおける中間値の検査

remote 関数から stderr または stdout に書き込みを行います。その後、/aws-glue/ray/jobs/ray-worker-out-logs/ または /aws-glue/ray/jobs/ray-worker-err-logs/ からログを取得します。関数はどのレプリカでも実行されている可能性があるため、目的の出力を見つけるには複数のログを調べなければならない場合があります。

問題の領域: エラーメッセージ内の IP アドレスの解釈

特定のエラー状況では、ジョブは IP アドレスを含むエラーメッセージを出力することがあります。これらの IP アドレスは一時的なもので、クラスターがノードを識別し、ノード間で通信するために使用されます。ノードのログは、IP アドレスに基づく一意のサフィックスが付いたログストリームに発行されます。

CloudWatch では、このサフィックスを識別することでログを絞り込み、この IP アドレス固有のログを検査できます。例えば、FAILED_IPJOB_RUN_ID が指定されている場合、サフィックスを以下のように識別できます。

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