View a markdown version of this page

Résolution des problèmes - AWS HealthOmics
Résolution des problèmes de fluxRésolution des problèmes liés aux métriques d'Résolution des problèmes de mise en cache des appelsRésolution des problèmes de stockage de donnéesRésolution des problèmes avec Kiro CLI

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résolution des problèmes

Les rubriques suivantes peuvent vous aider à résoudre les problèmes que vous rencontrez lors de l'utilisation des HealthOmics flux de travail et des magasins de données.

Résolution des problèmes de flux

Comment résoudre les problèmes liés à un échec d'exécution ?

Utilisez l'opération GetRun API pour récupérer la raison de l'échec. Pour plus d’informations, consultez Motifs d'échec de l'exécution.

Comment résoudre les problèmes liés à l'échec d'une tâche ?

Consultez le code d'erreur figurant dans le message d'échec de la tâche pour comprendre l'échec. Consultez les journaux de tâches CloudWatch pour voir les messages de journalisation détaillés relatifs à la tâche. Si vous ne recevez pas de messages de journal détaillés, vous pouvez modifier votre flux de travail pour générer des instructions de journal supplémentaires. Pour plus d’informations, consultez Surveillance à HealthOmics l'aide de CloudWatch journaux.

Où puis-je trouver les journaux du moteur ?

HealthOmics publie les journaux du moteur CloudWatch en temps quasi réel pour toutes les exécutions (réussies et échouées). Les journaux du moteur sont également envoyés à votre compartiment Amazon S3 une fois l'exécution terminée. Pour plus d’informations, consultez Surveillance à HealthOmics l'aide de CloudWatch journaux et Se connecte à Amazon S3.

Comment puis-je réduire la taille des paramètres d'entrée pour un flux de travail ?

Vous pouvez spécifier jusqu'à 256 Ko de paramètres d'entrée pour un flux de travail. Vous pouvez utiliser des importations de répertoires ou des feuilles d'exemple pour respecter cette contrainte de taille. Pour plus d’informations, consultez Gestion de la taille des paramètres d'exécution.

Pourquoi ma course ne se termine-t-elle pas ?

S'il y a des problèmes avec votre code et que les processus ne se sont pas terminés correctement, votre exécution peut ne pas répondre ou être « bloquée ». Pour plus d'informations sur la façon de prévenir et de détecter les courses qui ne répondent pas, consultezConseils pour les courses qui ne répondent pas.

Résolution des problèmes liés aux métriques d'

Pourquoi ma tâche s'exécute-t-elle plus lentement que prévu ?

Une tâche peut s'exécuter lentement si elle est liée à l'unité centrale (CPU), à l'unité de traitement graphique (GPU) ou si elle est en attente input/output (I/O). Utilisez les CloudWatch mesures en temps quasi réel de l'exécution pour voir l'utilisation des ressources alors que la tâche est toujours en cours d'exécution :

  • Comparez aws.omics.task.cpu.usage avecaws.omics.task.cpu.limit. Une utilisation prolongée à la limite indique que la tâche est CPU-bound et peut bénéficier d'une plus grande quantité de CPU allouée.

  • Pour les charges de travail GPU, vérifiezaws.omics.task.gpu.utilization. Un faible taux d'utilisation peut indiquer que la tâche n'utilise pas le GPU de manière efficace.

  • Vérifiez s'il y a aws.omics.task.filesystem.io aws.omics.task.filesystem.operations des I/O goulots d'étranglement.

Pour plus d’informations, consultez Exécutez des métriques pour les flux de travail privés.

Pourquoi mon exécution a-t-elle échoué en raison d'un manque de stockage ?

Une exécution peut échouer lorsqu'elle épuise l'espace de stockage de son système de fichiers partagé. Compareaws.omics.run.filesystem.usage, qui indique le stockage utilisé sur le système de fichiers partagé de l'exécution, par rapport àaws.omics.run.filesystem.limit, qui indique sa capacité totale. Vous pouvez créer des tableaux de bord ou des alarmes pour surveiller l'utilisation du stockage. Pour plus d’informations, consultez Exécutez des métriques pour les flux de travail privés.

Comment dimensionner correctement le calcul et le stockage pour mon flux de travail ?

Exécutez votre flux de travail une seule fois et examinez les CloudWatch indicateurs pour comparer l'utilisation réelle aux limites allouées :

  • Si l'utilisation du processeur, du GPU ou de la mémoire reste bien inférieure à la limite, vous pouvez réduire l'allocation pour réduire les coûts.

  • Si l'utilisation est constamment à la limite, augmentez l'allocation pour améliorer les performances ou éviter les pannes.

  • Permet aws.omics.run.filesystem.usage de définir une taille de système de fichiers appropriée pour l'exécution.

Pour plus d’informations, consultez Exécutez des métriques pour les flux de travail privés.

Pourquoi ne puis-je pas voir les statistiques de ma course ?

Si les mesures d'exécution et de tâche n'apparaissent pas dans la cloudwatch.aws/omics portée de CloudWatch, vérifiez les points suivants :

  • Vérifiez que le rôle IAM utilisé pour l'exécution est autorisé à publier des métriques. CloudWatch

  • Les métriques sont publiées en temps quasi réel pendant l'exécution de l'exécution. Prévoyez un court délai (environ 30 secondes) pour que les premiers points de données apparaissent.

  • Les tâches exécutées pendant moins de 30 secondes peuvent ne pas comporter de métriques.

  • Vérifiez que vous consultez la bonne AWS région et le bon compte.

Pour plus d’informations, consultez Exécutez des métriques pour les flux de travail privés.

En quoi est-ce différent des statistiques des ressources du journal du manifeste d'exécution ?

Les journaux des manifestes d'exécution fournissent des statistiques agrégées pour une exécution terminée, telles que le processeur et la mémoire maximum et moyen, afin que vous puissiez consulter une exécution terminée pour identifier les opportunités d'optimisation. CloudWatch les métriques d'exécution sont une série chronologique : HealthOmics publie des points de données à la fréquence indiquée dansMétriques disponibles, afin que vous puissiez surveiller les changements d'utilisation pendant l'exécution et utiliser des données plus précises pour résoudre les problèmes liés à vos essais. Pour plus d'informations sur les métriques d'exécution, consultezExécutez des métriques pour les flux de travail privés.

En quoi les métriques d'exécution dans Query Studio diffèrent-elles du rapport d'exécution de Nextflow ?

Les deux indiquent l'utilisation des ressources pour votre flux de travail. Ils diffèrent en termes de synchronisation, de couverture du moteur et de la façon dont vous les utilisez. Utilisez les métriques d'exécution pour surveiller une exécution en cours et utilisez le rapport d'exécution Nextflow pour examiner une exécution terminée.

  • Les métriques d'exécution sont disponibles en temps quasi réel pendant l'exécution de l'exécution, ce qui vous permet de suivre la progression, de définir des alarmes et de dépanner une exécution toujours en cours. Le rapport d'exécution de Nextflow est écrit à la fin de l'exécution. Vous ne pouvez donc l'utiliser que pour revoir une exécution après coup.

  • HealthOmics émet des métriques d'exécution pour chaque exécution de flux de travail privée, quel que soit le moteur de flux de travail utilisé par l'exécution. Le rapport d'exécution est spécifique à Nextflow et ne l' HealthOmics exporte que lorsque vous le configurez pour écrire sous/mnt/workflow/output/.

  • Les métriques d'exécution sont des séries CloudWatch chronologiques. Vous pouvez donc les interroger avec ProMQL, émettre une alarme et les ajouter à un tableau de bord. Le rapport d'exécution est un fichier statique situé dans l'emplacement de sortie Amazon S3 de votre exécution.

Pour plus d'informations sur le rapport d'exécution, consultezGénérez des rapports d'exécution de Nextflow. Pour plus d'informations sur les métriques d'exécution, consultezExécutez des métriques pour les flux de travail privés.

Résolution des problèmes de mise en cache des appels

Les rubriques suivantes peuvent vous aider à résoudre les problèmes que vous rencontrez lors de la mise en cache des appels.

Pourquoi ma course n'est-elle pas enregistrée dans le cache ?

  1. Vérifiez que l'exécution est configurée pour utiliser un cache en vérifiant le champ CacheID dans la réponse à l'opération GetRun d'API. À l'aide de la CLI, exécutez cette commande :aws omics get-run —id <run_id>.

  2. Si l'exécution a réussi, vérifiez que le comportement du cache renvoyé dans la GetRun réponse est CACHE_ALWAYS. Si le comportement du cache est défini sur CACHE_ON_FAILURE, les exécutions ne seront enregistrées dans le cache qu'en cas d'échec.

Pourquoi une tâche n'utilise-t-elle pas l'entrée du cache ?

<cache_id><cache_uuid>Dans le groupe de /aws/omics/WorkflowLog CloudWatch journaux, ouvrez le flux de journal pour le cache d'exécution : RunCache//.

  1. Vérifiez qu'une exécution précédente a créé une entrée de cache pour la tâche qui devait être mise en cache. Les exécutions enregistrées dans le cache seront enregistrées avec un message de journal de type CACHE_ENTRY_CREATED.

  2. Localisez le journal CACHE_MISS pour la tâche et exécutez-le terminé. S'il n'y a aucune entrée de journal, vérifiez que l'exécution a été configurée pour utiliser le cache.

  3. Si une entrée de cache a été créée, vérifiez que les processeurs, la mémoire, les GPU et le condensé du conteneur sont identiques pour les deux tâches. L'ARN de la tâche qui a créé l'entrée de cache se trouve dans le message du journal.

  4. Si les exigences de calcul pour les deux tâches correspondent, vérifiez que les entrées n'ont pas changé entre les tâches. Pour ce faire, ouvrez les journaux du moteur. Les journaux du moteur sont disponibles dans CloudWatch Log Group/aws/omics/WorkflowLog pour toutes les exécutions. Ils sont également disponibles dans le répertoire de sortie de l'exécution une fois terminée.

Pourquoi la mise en cache des appels pour une tâche est-elle désactivée ?

Vérifiez si la tâche est configurée pour désactiver la mise en cache à l'aide des fonctionnalités du moteur de flux de travail :

  • Pour les flux de travail WDL : vérifiez si la tâche est définie sur « volatile » true dans la méta-section

  • Pour les flux de travail Nextflow : vérifiez si la directive de cache de la tâche est définie sur false

  • Pour les flux de travail CWL : vérifiez si EnableReuse est défini sur pour la tâche pour la fonctionnalité false WorkReuse

Résolution des problèmes de stockage de données

Pourquoi S3 GetObject échoue-t-il sur mon appareil de lecture ?

Le plus souvent, l'échec est dû à une autorisation manquante. L'autorisation de lecture S3 du magasin de séquences est une configuration bidirectionnelle nécessitant à la fois la politique d'accès S3 du magasin de séquences pour autoriser l'accès et le principal IAM doit être associé à une politique autorisant l'accès. Pour plus de détails sur les exigences de la politique, voirAutorisations d'accès aux données à l'aide d'Amazon S3 URIs. Vérifiez que les configurations suivantes sont en place :

  • La politique d'accès S3 du magasin de séquences a explicitement autorisé l'accès au principal IAM ou à la racine du compte du principal.

  • Vérifiez que le principal IAM dispose d'une politique fournissant explicitement l'autorisation d'accéder à la ressource. Notez que la politique principale IAM doit utiliser l'ARN du point d'accès et non le chemin basé sur l'alias du point d'accès lors de la définition des autorisations et que l'ARN est en condition et n'est pas utilisé pour spécifier une ressource.

  • Si votre boutique utilise une clé gérée par le client (CMK-KMS), assurez-vous que le responsable IAM dispose des autorisations kms:decrypt sur la clé. Consultez le guide d'accès multicompte KMS pour configurer l'utilisation entre les comptes.

Si votre politique utilise des contrôles d'accès basés sur des balises, assurez-vous de ce qui suit :

  • Assurez-vous que le magasin de séquences a fini de synchroniser les balises. Pour cela, le statut de la boutique doit être active et nonupdating.

  • Assurez-vous qu'il n'y a pas de fautes de frappe dans la clé de balise ou dans la valeur de la clé du jeu de lecture et de la politique.

Pourquoi ne puis-je pas voir mon magasin d'annotations ou mon magasin de variantes dans Athena ?

Dans Lake Formation, veillez à créer un lien vers une ressource en fonction de la boutique qui a été partagée avec vous. Une fois que vous avez créé un lien vers une ressource auquel vous êtes autorisé à accéder, la boutique devrait être visible dans Athena. Pour plus d’informations, consultez Configuration de Lake Formation à utiliser HealthOmics.

Pourquoi ne puis-je pas accéder à ma banque de données dans Athena ?

Si votre magasin d'annotations ou de variantes est visible mais que vous recevez un message d'erreur indiquant que l'accès est refusé, vérifiez la version du moteur de requête que vous utilisez. Seules les requêtes exécutées à l'aide de la version 3 du moteur sont prises en charge. Pour en savoir plus sur les versions du moteur de requête Athena, consultez la documentation Amazon Athena.

Résolution des problèmes avec Kiro CLI

Kiro CLI peut vous aider à rationaliser votre processus de dépannage en :

  • Analyse des exécutions du flux de travail et des échecs des tâches de débogage

  • Collecte des journaux et des messages d'erreur pertinents

  • Création de dossiers de AWS support avec tous les journaux de débogage nécessaires

  • Supprime les informations personnelles identifiables (PII) des informations soumises au support AWS

Pour plus d'informations sur l'utilisation de la CLI Kiro AWS HealthOmics pour le dépannage et la création de dossiers de support, consultez le didacticiel HealthOmics Agentic Generative AI sur. GitHub

Avertissement

Lorsque vous travaillez avec Kiro CLI, passez en revue tout le contenu généré et les actions proposées avant de continuer. Fournissez des commentaires afin d'améliorer la qualité des réponses et de répondre aux exigences de votre flux de travail. Pour plus d'informations, consultez la section Considérations de sécurité et meilleures pratiques pour Kiro.