翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# トラブルシューティング
以下のトピックは、HealthOmics ワークフローとデータストアを使用する際に発生する問題のトラブルシューティングに役立ちます。
**Topics**
+ [ワークフローのトラブルシューティング](#error-workflows)
+ [コールキャッシュの問題のトラブルシューティング](#workflow-cache-troubleshooting)
+ [データストアのトラブルシューティング](#error-datastores)
+ [Kiro CLI を使用したトラブルシューティング](#kiro-cli-troubleshooting)
## ワークフローのトラブルシューティング
**Topics**
+ [失敗した実行のトラブルシューティング方法を教えてください。](#troubleshooting-run-fail)
+ [失敗したタスクのトラブルシューティング方法を教えてください。](#troubleshooting-task-fail)
+ [正常に完了した実行のエンジンログはどこにありますか?](#troubleshooting-engine-logs)
+ [ワークフローの入力パラメータサイズを減らすにはどうすればよいですか?](#troubleshooting-input-file-size)
+ [実行が完了しないのはなぜですか?](#troubleshooting-unresponsive-runs)
### 失敗した実行のトラブルシューティング方法を教えてください。
**GetRun** API オペレーションを使用して、失敗の理由を取得します。詳細については、「[実行失敗の理由](workflows-run-errors.md)」を参照してください。
### 失敗したタスクのトラブルシューティング方法を教えてください。
タスク失敗メッセージのエラーコードを確認して、失敗を理解します。CloudWatch のタスクログを確認して、タスクの詳細なログ記録メッセージを確認します。詳細なログメッセージが表示されない場合は、ワークフローを修正して追加のログステートメントを出力できます。詳細については、「[CloudWatch Logs による HealthOmics のモニタリング](monitoring-cloudwatch-logs.md)」を参照してください。
### 正常に完了した実行のエンジンログはどこにありますか?
HealthOmics は、失敗した実行に対してのみ CloudWatch にログを発行します。実行が正常に完了すると、HealthOmics はエンジンログを Amazon S3 バケットに配信します。詳細については、「[Amazon S3 のログ](monitoring-cloudwatch-logs.md#s3-logs)」を参照してください。
### ワークフローの入力パラメータサイズを減らすにはどうすればよいですか?
ワークフローには、最大 50 KB の入力パラメータを指定できます。ディレクトリのインポートまたはサンプルシートを使用して、このサイズ制約内にとどまることができます。詳細については、「[実行パラメータサイズの管理](workflows-run-inputs.md#run-input-file-options)」を参照してください。
### 実行が完了しないのはなぜですか?
コードに問題があり、プロセスが適切に終了していない場合、実行が応答しないか、「スタック」する可能性があります。応答しない実行を防止してキャッチする方法の詳細については、「」を参照してください[応答しない実行のガイダンス](workflows-run-errors.md#workflows-guidance-unresponsive-runs)。
## コールキャッシュの問題のトラブルシューティング
以下のトピックは、通話キャッシュで発生する問題のトラブルシューティングに役立ちます。
**Topics**
+ [実行がキャッシュに保存されないのはなぜですか?](#troubleshooting-did-run-cache)
+ [タスクがキャッシュエントリを使用していないのはなぜですか?](#troubleshooting-did-run-cache)
+ [タスクのコールキャッシュが無効になっているのはなぜですか?](#troubleshooting-task-cache-disabled)
### 実行がキャッシュに保存されないのはなぜですか?
1. GetRun API オペレーションレスポンスの cacheId フィールドをチェックして、キャッシュを使用するように実行が設定されていることを確認します。CLI を使用して、次のコマンドを実行します: `aws omics get-run —id `。
1. 実行が成功した場合は、GetRun レスポンスで返されるキャッシュ動作が CACHE\$1ALWAYS であることを確認します。キャッシュ動作が CACHE\$1ON\$1FAILURE に設定されている場合、実行は失敗したときにのみキャッシュに保存されます。
### タスクがキャッシュエントリを使用していないのはなぜですか?
`/aws/omics/WorkflowLog` CloudWatch ロググループで、実行キャッシュのログストリーム **runCache// **を開きます。
1. 前の実行で、キャッシュされる予定のタスクのキャッシュエントリが作成されていることを確認します。キャッシュに保存された実行は、CACHE\$1ENTRY\$1CREATED のログメッセージで記録されます。
1. タスクの CACHE\$1MISS ログを見つけ、完了した を実行します。ログエントリがない場合は、キャッシュを使用するように実行が設定されていることを確認します。
1. キャッシュエントリが作成された場合は、CPU、メモリCPUs、GPUs、コンテナダイジェストが両方のタスクで同じであることを確認します。キャッシュエントリを作成したタスクのタスク ARN は、ログメッセージにあります。
1. 両方のタスクのコンピューティング要件が一致する場合は、タスク間で入力が変更されていないことを確認します。これを行うには、エンジンログを開きます。実行のステータスが FAILED の場合、ログは Cloudwatch Log Group /aws/omics/WorkflowLog になります。それ以外の場合、エンジンログは実行の出力ディレクトリにあります。
### タスクのコールキャッシュが無効になっているのはなぜですか?
ワークフローエンジン機能を使用してキャッシュをオプトアウトするようにタスクが設定されているかどうかを確認します。
+ WDL ワークフローの場合: メタセクション`true`でタスクの揮発性が に設定されているかどうかを確認します
+ Nextflow ワークフローの場合: タスクのキャッシュディレクティブが に設定されているかどうかを確認します。 `false`
+ CWL ワークフローの場合: enableReuse 機能`false`に対してタスクの WorkReuse が に設定されているかどうかを確認します。
## データストアのトラブルシューティング
**Topics**
+ [読み取りセットで S3 GetObject が失敗するのはなぜですか?](#sequence-store-s3-getobject-failing)
+ [Athena で注釈ストアまたはバリアントストアが表示されないのはなぜですか?](#athena-troubleshooting)
+ [Athena のデータストアにアクセスできないのはなぜですか?](#athena-engine-troubleshooting)
### 読み取りセットで S3 GetObject が失敗するのはなぜですか?
ほとんどの場合、障害の原因はアクセス許可がないことです。シーケンスストア S3 読み取りアクセス許可は、アクセスを許可するシーケンスストア S3 アクセスポリシーと、アクセスを許可するポリシーをアタッチする IAM プリンシパルの両方を必要とする双方向の設定です。ポリシー要件の詳細については、「」を参照してください[Amazon S3 URIs を使用したデータアクセスのアクセス許可](s3-sharing.md)。次の設定が設定されていることを確認します。
+ シーケンスストア S3 アクセスポリシーは、IAM プリンシパルまたはプリンシパルのアカウントのルートへのアクセスを明示的に許可しています。
+ IAM プリンシパルに、アクセスするリソースにアクセス許可を明示的に付与するポリシーがあることを確認します。アクセス許可を定義するときは、IAM プリンシパルポリシーはアクセスポイント ARN を使用する必要があり、アクセスポイントエイリアスベースのパスは使用しないことに注意してください。また、ARN は 条件にあり、リソースの指定には使用されません。
+ ストアでカスタマーマネージドキー (CMK-KMS) を使用している場合は、IAM プリンシパルにキーに対する kms:decrypt アクセス許可があることを確認します。アカウント間の使用状況の設定については、KMS [クロスアカウントアクセスガイド](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html)を参照してください。
タグベースのアクセスコントロールを使用しているポリシーがある場合は、以下を確認してください。
+ シーケンスストアがタグの同期を完了していることを確認します。そのためには、ストアのステータスは **active** ではなく である必要があります**updating**。
+ 読み取りセットとポリシーのタグキーまたはキー値にタイプミスがないことを確認します。
### Athena で注釈ストアまたはバリアントストアが表示されないのはなぜですか?
Lake Formation では、共有されたストアに基づいてリソースリンクを作成してください。アクセス許可を持つリソースリンクを作成すると、ストアが Athena に表示されます。詳細については、「[HealthOmics を使用するように Lake Formation を設定する](setting-up-lf.md)」を参照してください。
### Athena のデータストアにアクセスできないのはなぜですか?
注釈ストアまたはバリアントストアが表示されていても、アクセスが拒否されたことを示すエラーメッセージが表示されている場合は、使用しているクエリエンジンのバージョンを確認してください。エンジンバージョン 3 を使用して実行されるクエリのみがサポートされています。Athena クエリエンジンのバージョンの詳細については、[Amazon Athena ドキュメント](https://docs.aws.amazon.com/athena/latest/ug/engine-versions-changing.html)を参照してください。
## Kiro CLI を使用したトラブルシューティング
[Kiro CLI ](https://docs.aws.amazon.com/kiro/latest/userguide/what-is.html)は、以下によってトラブルシューティングプロセスを合理化するのに役立ちます。
+ ワークフロー実行の分析とタスク失敗のデバッグ
+ 関連するログとエラーメッセージの収集
+ 必要なすべてのデバッグログがアタッチされた AWS サポートケースの作成
+ AWS サポートに送信された情報から個人を特定できる情報 (PII) を編集します
サポートケースのトラブルシューティングと作成 AWS HealthOmics に Kiro CLI を で使用する方法の詳細については、GitHub の [HealthOmics Agentic 生成 AI チュートリアル](https://github.com/aws-samples/aws-healthomics-tutorials/tree/main/generative-ai)を参照してください。
**警告**
Kiro CLI を使用する場合は、先に進む前に、生成されたすべてのコンテンツと提案されたアクションを確認してください。応答品質を向上させ、ワークフローの要件に合わせてフィードバックを提供します。詳細については、「Kiro [のセキュリティ上の考慮事項とベストプラクティス](https://docs.aws.amazon.com/kiro/latest/userguide/command-line-chat-security.html)」を参照してください。