翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # HealthOmics ワークフロー実行のデバッグ HealthOmics は、複数のソースを通じて実行の動作を報告し、それぞれが異なる質問に答えます。失敗した実行の場合は、ログで始まるのではなく、次の順序で読み取ります。 1. 実行に失敗したかどうか、および失敗した理由については、実行レコードを読み取ります。 1. タスクが失敗した場合、どのタスクが失敗し、どのインスタンスタイプでタスクレコードを読み取ります。実行は、タスクの作成前、またはすべてのタスクの完了後に失敗する可能性があります。 1. ログを読みます。タスクが報告したタスクログ、タスク外で実行が報告した実行ログ、エンジンが報告したエンジンログです。 1. 実行メトリクスを読み、タスクが消費したマニフェストログを実行します。 完了したが、予想よりも遅い、またはコストがかかった実行については、 から開始します[同じワークフローの実行を比較する](#workflows-run-debug-compare)。 このトピックのリソースとコストのガイダンスは、 に記載されている理由により、プライベートワークフローに適用されます[プライベート HealthOmics ワークフローの最適化を実行する](workflows-run-optimize.md)。次の手順で使用する API オペレーションとレスポンスフィールドについては、「」を参照してください[実行情報を取得する](getinfo-about-runs.md)。 このトピックのコマンドで、次の値を独自の値に置き換えます。 `{{run_id}}` デバッグする実行の ID。 `{{duration}}` **aws logs tail** 読み取りウィンドウ: 最近終了した実行`2h`の などの相対時間、または`2026-03-26T22:00:00`古い実行の などのタイムスタンプ。 `{{run_uuid}}` その実行のレコードの `uuid`フィールド。 `{{task_id}}` その実行で失敗したタスクの ID。 `{{workflow_id}}` 実行を一覧表示するワークフローの ID。 **Topics** + [失敗した実行を診断する](#workflows-run-debug-failed) + [実行メトリクスでリソースの使用を検査する](#workflows-run-debug-metrics) + [同じワークフローの実行を比較する](#workflows-run-debug-compare) + [検出結果をコストとサイジングの変更に変換する](#workflows-run-debug-cost) ## 失敗した実行を診断する **失敗した実行を診断するには** 1. 実行レコードを取得し、`status`、、`failureReason``statusMessage`、および を読み取ります`logLocation`。レスポンスを保持します。後のステップで使用します。 `logLocation` は実行ログの ARNs (`runLogStream`) とエンジンログ () を提供します`engineLogStream`。 ``` aws omics get-run --id {{run_id}} ``` `failureReason` で の値を検索します[実行失敗の理由](workflows-run-errors.md)。`status` が でない場合は`FAILED`、[実行ステータス値](monitoring-runs.md#run-status-values)代わりに「」を参照してください。 一部の障害は、HealthOmics がタスクを作成する前、またはタスクが終了するたびに発生するため、次の 3 つのステップを読み取るタスクレコードを残しません。ロール、入力、インポート、またはエクスポートの失敗は 1 つであるため、 はタスクを作成する前に HealthOmics が拒否するイメージです (ECR\_IMAGE\_NOT\_FOUND、ECR\_PERMISSION\_ERROR、ECR\_REPOSITORY\_NOT\_FOUND、または INVALID\_ECR\_IMAGE\_URI)。いずれの場合も、この手順の後半で実行ログにスキップします。イメージに障害が発生した場合、 はイメージ URI に`statusMessage`名前を付けるため、 [プライベートワークフローのコンテナイメージ](workflows-ecr.md)と から続行します[Amazon ECR のアクセス許可](permissions-ecr.md)。次のステップで失敗したタスクが返された場合は、代わりにそのタスクを読み取ります。 1. 失敗したタスクを一覧表示します。各項目には`taskId`、タスクの が含まれます。これは次のステップで使用されます。さらに、その名前、その `creationTime`、およびそれらに到達したら、そのインスタンスタイプ、`startTime`、および が含まれます`stopTime`。 ``` aws omics list-run-tasks --id {{run_id}} --status FAILED ``` これがタスクを返さない場合、実行はステップ 1: 次の 2 つのステップをスキップして実行ログを読み取るケースの 1 つです。 1. 失敗したタスクごとに、そのレコードを取得します。前のステップで返された内容`logStream`に `failureReason`、`imageDetails`、、 が追加されます。 `statusMessage``logStream`は、次のステップが読み取るログストリームの ARN であり、ストリームの名前はその中で続き`log-stream:`ます。 ``` aws omics get-run-task --id {{run_id}} --task-id {{task_id}} ``` 1. タスクログを読み取ります。失敗を説明するイベントは、ストリームの最後にあります。 ``` aws logs tail /aws/omics/WorkflowLog \ --log-stream-names run/{{run_id}}/task/{{task_id}} \ --since {{duration}} ``` タスクの実行前に開始する{{期間}}を設定します。コマンドはそれまで読み取られ、デフォルトのウィンドウは過去 10 分であるため、以前に終了した実行はイベントを返しません。ロググループと各ストリームの形式については、「」を参照してください[CloudWatch のログ](monitoring-cloudwatch-logs.md#cloudwatch-logs)。 **注記** タスクにログがまったくない理由と、タスクをよりデバッグ可能にする方法については、「」を参照してください[ワークフロータスクのトラブルシューティング](workflow-run-tasks.md#debugging-tasks)。 1. 実行の他の 2 つのログのいずれかを読み取ると、ここにある質問に回答します。どちらも異なるストリームでステップ 4 コマンドを実行します。 ``` aws logs tail /aws/omics/WorkflowLog \ --log-stream-names run/{{run_id}} \ --since {{duration}} ``` 実行に失敗したタスクがない 前述のコマンドのように`run/{{run_id}}`、実行ログ を読み取ります。タスクなしで失敗するインポートおよびエクスポートステップなど、実行自体の進行状況をレポートします。レポートについては、「」を参照してください[HealthOmics ワークフローのログタイプ](monitoring-cloudwatch-logs.md#log-descriptions)。 タスクが失敗し、ログにその理由が説明されない ワークフロー定義内の位置など、エンジンが失敗した原因`run/{{run_id}}/engine`を報告するエンジンログ を読み取ります。その ARN はステップ 1 `logLocation.engineLogStream`の にあります。そのフィールドがレスポンスに含まれていない場合、実行にはエンジンログがありません。 エンジン名の位置の定義を読み取るには、それをエクスポートします。次のコマンドは、実行が使用した定義のダウンロード URL を返します。 ``` aws omics get-workflow --id {{workflow_id}} --export DEFINITION ``` 続行する場所は、失敗の理由によって異なります。次のリストでは、最も一般的なリソースとコンテナの障害について説明します。タスクが消費した内容、つまり障害がサイジングの問題であったかどうかについては、「」を参照してください[検出結果をコストとサイジングの変更に変換する](#workflows-run-debug-cost)。 **CANNOT\_START\_CONTAINER\_ERROR、CANNOT\_START\_CONTAINER\_SIZE\_ERROR、または IMAGE\_VERIFICATION\_FAILURE** HealthOmics はタスクを作成し、コンテナを起動できなかったため、タスクはログを生成しませんでした。タスクレコードの からイメージを取得し`imageDetails`、「」を参照してください[プライベートワークフローのコンテナイメージ](workflows-ecr.md)。 **OUT\_OF\_MEMORY\_ERROR** 「」で説明されているように、タスクの実行メトリクスまたは が[検出結果をコストとサイジングの変更に変換する](#workflows-run-debug-cost)検索する実行マニフェストログの統計[ワークフローのコンピューティングとストレージを適切なサイズにするにはどうすればよいですか?](troubleshooting.md#troubleshooting-metrics-right-size)を使用して、タスクのメモリ使用量を割り当てと比較します。次に、ワークフロー定義のメモリを増やし、新しい値が で選択するインスタンスタイプを確認します[HealthOmics タスクのコンピューティングとメモリの要件](memory-and-compute-tasks.md)。 **TASK\_TIMED\_OUT または RUN\_TIMED\_OUT** タイムアウトの期限が切れたときにタスクがまだ作業を行っていたかどうかを確認します。そうでない場合は、低速ではなく応答しないものとして扱い、「」を参照してください[応答しない実行のガイダンス](workflows-run-errors.md#workflows-guidance-unresponsive-runs)。実行を終了した制限が実行グループからのものである場合は、「」を参照してください[HealthOmics 実行グループの使用](creating-run-groups.md)。 ## 実行メトリクスでリソースの使用を検査する 実行メトリクスは、まだ進行中の実行を対象とするため、実行が終了する前に使用できます。実行にどのシリーズが存在するかは、その実行ストレージタイプ、スクラッチストレージモード、タスクがアクセラレーターをリクエストしたかどうかによって異なるため、メトリクスが欠落していると判断[使用可能なメトリクス](monitoring-run-metrics.md#monitoring-run-metrics-available)する前に、 の条件を確認してください。実行にシリーズがまったくない場合は、「」で説明されているように、そのロールがシリーズを発行できることを確認します[実行のメトリクスの有効化](monitoring-run-metrics.md#monitoring-run-metrics-enabling)。クエリ構文とコンソールの手順については、「」を参照してください[HealthOmics 実行メトリクスのクエリ](monitoring-run-metrics.md#monitoring-run-metrics-viewing)。 実行リソースラベルを使用して、すべてのクエリを 1 回の実行にスコープします。タスクごとのメトリクスには、一連の をタスクレコードとそのログに結合するタスクリソースラベルも含まれます。両方のラベルについては、「」を参照してください[共通の 属性](monitoring-run-metrics.md#monitoring-run-metrics-common-attributes)。 **注記** CloudWatch は、PromQL クエリが返す時系列の数とそれにかかる時間範囲の両方を制限します。実行では、タスクごとのメトリクスごとにタスクごとに少なくとも 1 つのシリーズが生成されます。さらに、メトリクスが方向または GPU で分割される複数のシリーズが生成されます。タスクが多い実行の場合、クエリ自体にシリーズを集約するか、1 つのタスク、1 つの方向、または 1 つの GPU にフィルタリングします。ロングランを連続したウィンドウに分割します。現在の制限については、[PromQL の制限と制限](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-PromQL.html#CloudWatch-PromQL-Limits)」を参照してください。 ## 同じワークフローの実行を比較する 同じワークフローの以前の実行よりも実行が遅いか、コストがかかる場合は、2 つの実行タスクをタスクごとに比較します。タスク ID ではなく名前でタスクを調整します。両方の実行のタスクを取得し、 でグループ化して`name`、各名前の期間とピーク値を比較します。各実行のマニフェストログを 1 回読み取ると、すべてのタスクのタイミングと、エントリによってレポートされるピークが表示されます。 は、前の手順で使用した`--status FAILED`フィルターなしで、まだ実行中の実行のタイミング**ListRunTasks**を提供します。 タスクごとに 2 つのスパンを比較します。 `startTime` `stopTime`はタスクの所要時間、 `creationTime``startTime`は開始を待機した時間で、 の保留中フェーズと開始フェーズが含まれます[タスクステータス値](workflow-run-tasks.md#task-status-values)。タスクメトリクスが待機をカバーしないため、すべてのタスクの時間が一致する間、実行は別のタスクよりもはるかに遅くなる可能性があります。 **注記** 1 回の実行で複数のタスクが名前を共有でき、名前の散布インデックスが両方の実行で同じ入力データをカバーしているとは限りません。インデックスでインデックスをペアリングするのではなく、最も長い期間や最も高いピークなど、名前を共有するタスク間で集計を比較します。 2 つの実行を比較するのではなく、ワークフローの正常性を確立するには、完了した実行のセットを集計します。Run Analyzer は、「」で説明されているように、これを `--batch` モードで実行します[実行間のファイルサイズの差異の影響](workflows-run-optimize.md#workflows-run-file-variance)。実行を自分で収集するには、 **ListRuns** で のレスポンスをフィルタリングします`workflowId`。オペレーションには独自のワークフローフィルターがないため、フィルターが絞り込む前に、完了したすべての実行を**ListRuns**ページスルーします。 ``` aws omics list-runs --status COMPLETED \ --query "items[?workflowId=='{{workflow_id}}'].id" ``` 1 回の実行ではなく、一連の実行にわたる分布は、タスクの割り当てがデータの分散に適しているかどうか、およびスロールックの実行が正常範囲外であるかどうかを示します。 ## 検出結果をコストとサイジングの変更に変換する 消費されるタスクは実行マニフェストログにあり、ストリームは です`manifest/run/{{run_id}}/{{run_uuid}}`。HealthOmics は実行の完了後にこれを書き込むため、タスクの停止時間ではなく実行の停止時間に達するように{{期間}}を設定します。他のストリームと同じ**aws logs tail**コマンドで読み取ります。レポートされる統計については、「」を参照してください[HealthOmics ワークフローのログタイプ](monitoring-cloudwatch-logs.md#log-descriptions)。 マニフェストタスクエントリは、タスクの予約内容、インスタンスタイプ、期間を報告します。タスクがそれらと一緒に使用した内容をレポートしますが、すべてのタスクに使用されたわけではありません。エントリが使用状況を報告しない場合、またはタスクの作業が考慮できる範囲を下回った場合、代わりに で指定された理由で、タスクの実行メトリクスに対してサイズを設定します[コールアウト](monitoring-run-metrics.md#monitoring-run-metrics-callouts)。 HealthOmics の 3 つの動作は、変更によって保存される内容を制限します。 + タスクのコストは、タスクが使用するリソースではなく、リクエストするリソースに対して HealthOmics が選択するインスタンスタイプに従います。「[HealthOmics タスクのコンピューティングとメモリの要件](memory-and-compute-tasks.md)」を参照してください。 + タスク料金には最小請求期間があるため、すでに短いタスクを短縮しても何も節約されません。「[実行ステータスの料金への影響](monitoring-runs.md#run-status-billing)」を参照してください。 + 静的実行ストレージは固定サイズであるため、削減により、サポートされるサイズが小さくなった場合にのみ料金が変更されます。「[静的実行ストレージ](workflows-run-types.md#workflows-run-type-static)」を参照してください。 これらの検出結果がフィードされる最適化方法については、「」を参照してください[実行を最適化する方法](workflows-run-optimize.md#run-optimize-methods)。