View a markdown version of this page

Débogage d'un HealthOmics exécution du flux de travail - AWS HealthOmics
Diagnostiquer un échec d'exécutionInspectez l'utilisation des ressources à l'aide de métriques d'exécutionComparez les exécutions d'un même flux de travailTransformez les résultats en modifications de coûts et de dimensionnement

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.

Débogage d'un HealthOmics exécution du flux de travail

HealthOmics rapporte le comportement d'une course à travers plusieurs sources, chacune répondant à une question différente. En cas d'échec de l'exécution, lisez-les dans cet ordre au lieu de commencer par les journaux :

  1. Lisez l'enregistrement de l'exécution pour savoir si l'exécution a échoué et pourquoi.

  2. Lisez les enregistrements de tâches, si une tâche a échoué, pour quelles tâches ont échoué et sur quels types d'instances. Une exécution peut également échouer avant la création d'une tâche ou une fois que chaque tâche est terminée.

  3. Lisez les journaux : le journal des tâches pour ce qu'une tâche a rapporté, le journal d'exécution pour ce que l'exécution a rapporté en dehors de toute tâche et le journal du moteur pour ce que le moteur a rapporté.

  4. Lisez les métriques d'exécution et exécutez le journal du manifeste pour connaître la consommation de la tâche.

Pour une course terminée mais plus lente ou plus coûteuse que prévu, commencez à Comparez les exécutions d'un même flux de travail.

Les conseils en matière de ressources et de coûts présentés dans cette rubrique s'appliquent aux flux de travail privés, pour la raison indiquée dans Exécuter l'optimisation pour un compte privé HealthOmics flux de travail. Pour les opérations d'API et les champs de réponse utilisés lors des étapes suivantes, consultez Obtenir des informations sur la course.

Dans les commandes de cette rubrique, remplacez les valeurs suivantes par les vôtres :

run_id

L'ID de l'exécution que vous êtes en train de déboguer.

duration

La fenêtre qui aws logs tail se lit comme suit : un temps relatif tel que 2h pour une course qui s'est terminée récemment, ou un horodatage tel que 2026-03-26T22:00:00 pour une personne plus âgée.

run_uuid

Le uuid champ du record de cette course.

task_id

L'ID d'une tâche qui a échoué lors de cette exécution.

workflow_id

L'ID du flux de travail dont vous souhaitez répertorier les exécutions.

Diagnostiquer un échec d'exécution

Pour diagnostiquer un échec d'exécution

  1. Récupérez l'enregistrement d'exécution et lisez status, failureReason, statusMessage, et logLocation. Conservez la réponse : les étapes suivantes l'utiliseront. logLocation donne les ARN du journal d'exécution (runLogStream) et le carnet de bord du moteur (engineLogStream).

    aws omics get-run --id run_id

    Recherchez la valeur de failureReason dans Motifs d'échec de l'exécution. Si status n'est pas FAILED, voir Exécuter les valeurs d'état au lieu de cela.

    Certains échecs se produisent avant HealthOmics crée n'importe quelle tâche, ou une fois chaque tâche terminée, afin de ne laisser aucun enregistrement de tâche à lire pour les trois étapes suivantes. Un échec de rôle, de saisie, d'importation ou d'exportation en est un ; il en va de même pour une image qui HealthOmics rejette avant de créer la tâche (ECR_IMAGE_NOT_FOUND, ECR_PERMISSION_ERROR, REPOSITORY_ECR_NOT_FOUND, ou UR_ECR_IMAGE_URI NON VALIDE). Pour chacun d'entre eux, passez au journal d'exécution plus loin dans cette procédure. En cas de panne d'image, statusMessage nomme l'URI de l'image, donc continuez à partir de Images de conteneurs pour les flux de travail privés et Autorisations Amazon ECR. Si l'étape suivante renvoie une tâche ayant échoué, lisez plutôt cette tâche.

  2. Répertoriez les tâches qui ont échoué. Chaque élément inclut les tâches taskId, que l'étape suivante utilisera, ainsi que son nom, son creationTime, et, une fois qu'il les a atteints, son type d'instance, startTime, et stopTime.

    aws omics list-run-tasks --id run_id --status FAILED

    Si aucune tâche n'est renvoyée, l'exécution est l'un des cas de l'étape 1 : sautez les deux étapes suivantes et lisez le journal d'exécution.

  3. Pour chaque tâche échouée, récupérez son enregistrement. Il ajoute failureReason, statusMessage, imageDetails, et logStream à ce à quoi l'étape précédente est revenue. logStream est l'ARN du flux de journal que l'étape suivante lit, et le nom du flux suit log-stream: dedans.

    aws omics get-run-task --id run_id --task-id task_id

  4. Lisez le journal des tâches. Les événements qui expliquent la panne se situent à la fin du flux.

    aws logs tail /aws/omics/WorkflowLog \
  --log-stream-names run/run_id/task/task_id \
  --since duration

    Set duration pour démarrer avant la fin de la tâche : la commande lit depuis cette date jusqu'à aujourd'hui, et sa fenêtre par défaut correspond aux 10 dernières minutes, donc une exécution terminée plus tôt ne renvoie aucun événement. Pour le groupe de journaux et le format de chaque flux, voir Se connecte CloudWatch.

    Note

    Pour savoir pourquoi une tâche peut ne pas avoir de journal du tout, et pour savoir comment rendre une tâche plus déboguable, voir Résolution des problèmes de flux de travail.

  5. Lisez celui des deux autres journaux de la course qui répond à la question qui vous a amené ici. Les deux exécutent la commande de l'étape 4 avec un flux différent.

    aws logs tail /aws/omics/WorkflowLog \
  --log-stream-names run/run_id \
  --since duration
    L'exécution ne comporte aucune tâche échouée

    Lisez le journal d'exécution, run/run_id, comme dans la commande précédente. Il indique la progression de l'exécution, y compris les étapes d'importation et d'exportation qui échouent sans aucune tâche. Pour ce qu'il rapporte, voir Types de journaux pour HealthOmics flux de travail.

    Une tâche a échoué et son journal n'explique pas pourquoi

    Lisez le journal du moteur, run/run_id/engine, qui indique ce que le moteur a pensé de la panne, par exemple sa position dans la définition du flux de travail. Son ARN est en logLocation.engineLogStream à partir de l'étape 1 ; si ce champ ne figure pas dans la réponse, l'exécution n'a pas de journal moteur.

    Pour lire la définition à l'emplacement des noms des moteurs, exportez-la. La commande suivante renvoie une URL de téléchargement pour la définition utilisée par l'exécution.

    aws omics get-workflow --id workflow_id --export DEFINITION

L'endroit où continuer dépend de la raison de l'échec. La liste suivante répertorie les défaillances de ressources et de conteneurs les plus courantes. Pour connaître les tâches consommées, qui vous indiquent si la panne était due à un problème de dimensionnement, voir Transformez les résultats en modifications de coûts et de dimensionnement.

CANNOT_START_CONTAINER_ERROR, CANNOT_START_CONTAINER_SIZE_ERROR, ou ÉCHEC DE LA VÉRIFICATION_D'IMAGE

HealthOmics a créé la tâche et n'a pas pu démarrer son conteneur, la tâche n'a donc généré aucun journal. Prenez l'image de l'enregistrement des tâches imageDetails, puis consultez Images de conteneurs pour les flux de travail privés.

ERREUR_OUT_OF_MEMORY_ERROR

Comparez l'utilisation de la mémoire de la tâche par rapport à son allocation, comme décrit dans Comment puis-je dimensionner correctement le calcul et le stockage pour mon flux de travail ?, en utilisant soit ses métriques d'exécution, soit ses statistiques dans le journal du manifeste d'exécution, qui Transformez les résultats en modifications de coûts et de dimensionnement localise. Augmentez ensuite la mémoire dans la définition du flux de travail et vérifiez dans quel type d'instance la nouvelle valeur est sélectionnée Exigences en matière de calcul et de mémoire pour les HealthOmics tâches.

TASK_TIMED_OUT ou RUN_TIMED_OUT

Vérifiez si la tâche était toujours en cours à l'expiration du délai. Si ce n'était pas le cas, considérez-le comme ne répondant pas plutôt que comme lent, et voyez Conseils pour les courses qui ne répondent pas. Si la limite qui a mis fin à la course provenait d'un groupe de courses, voir Utilisation de groupes d' HealthOmics exécution.

Inspectez l'utilisation des ressources à l'aide de métriques d'exécution

Les métriques d'exécution couvrent une course qui est toujours en cours. Vous pouvez donc les utiliser avant la fin d'une course. Les séries disponibles pour une exécution dépendent de son type de stockage d'exécution, de son mode de stockage temporaire et de la question de savoir si ses tâches ont nécessité des accélérateurs. Vérifiez donc les conditions dans Métriques disponibles avant de conclure qu'une métrique est manquante. Si une série ne comporte aucune série, vérifiez que son rôle peut les publier, comme décrit dans Activation des métriques pour une course. Pour la syntaxe des requêtes et la procédure de la console, voir Interrogation HealthOmics exécuter des métriques.

Étendez chaque requête à une seule exécution avec l'étiquette de ressource run. Per-task les métriques portent également l'étiquette de ressource de tâche, qui joint une série à l'enregistrement de la tâche et à ses journaux. Pour les deux étiquettes, voir Attributs communs.

Note

CloudWatch limite à la fois le nombre de séries chronologiques renvoyées par une requête ProMQL et la plage de temps qu'elle couvre. Une exécution produit au moins une série par tâche pour chaque métrique par tâche, et davantage lorsque la métrique est divisée par direction ou par GPU. Pour une exécution comportant de nombreuses tâches, regroupez les séries dans la requête elle-même ou filtrez en fonction d'une tâche, d'une direction ou d'un GPU. Divisez une longue course en fenêtres consécutives. Pour les limites actuelles, voir Limites et restrictions de ProMQL.

Comparez les exécutions d'un même flux de travail

Lorsqu'une exécution est plus lente ou plus coûteuse qu'une exécution précédente du même flux de travail, comparez les deux exécutions tâche par tâche. Alignez les tâches par nom plutôt que par identifiant de tâche : récupérez les tâches des deux exécutions, regroupez-les par name, et comparez la durée et les valeurs maximales pour chaque nom. Une lecture du journal du manifeste de chaque exécution vous donne le calendrier de chaque tâche et, là où l'entrée les indique, ses pics ; ListRunTasks vous donne les chronométrages d'une course encore en cours, sans --status FAILED filtre utilisé par la procédure précédente.

Comparez deux périodes par tâche : startTime pour stopTime est la durée de la tâche, et creationTime pour startTime est le temps qu'il a attendu pour démarrer, qui couvre ses phases en attente et de démarrage dans Valeurs d'état des tâches. Une exécution peut être beaucoup plus lente qu'une autre alors que la durée de chaque tâche correspond, car aucune métrique de tâche ne couvre l'attente.

Note

Plusieurs tâches au cours d'une exécution peuvent partager le même nom, et un indice de dispersion dans un nom ne couvre pas nécessairement les mêmes données d'entrée dans les deux exécutions. Comparez l'agrégat entre les tâches qui partagent un même nom, par exemple la durée la plus longue ou le pic le plus élevé, plutôt que de les associer index par indice.

Pour déterminer ce qui est normal pour un flux de travail plutôt que de comparer deux exécutions, regroupez un ensemble de ses exécutions terminées. Run Analyzer le fait dans --batch mode, comme décrit dans Impact de la variation de taille de fichier entre les exécutions. Pour collecter vous-même les points, filtrez la réponse de ListRuns sur workflowId. L'opération ne possède pas de filtre de flux de travail propre, donc ListRuns pages parcourent chaque cycle terminé avant que votre filtre ne les réduise.

aws omics list-runs --status COMPLETED \
  --query "items[?workflowId=='workflow_id'].id"

La distribution sur un ensemble d'exécutions, et non sur une seule exécution, indique si l'allocation d'une tâche correspond à la variance de vos données et si une exécution lente se situe en dehors de la plage normale.

Transformez les résultats en modifications de coûts et de dimensionnement

La nature d'une tâche consommée se trouve dans le journal du manifeste d'exécution, dont le flux est manifest/run/run_id/run_uuid. HealthOmics l'écrit une fois l'exécution terminée, donc définissez duration pour atteindre l'heure d'arrêt de la course plutôt que celle d'une tâche. Lisez-le avec le même aws logs tail commande comme les autres flux. Pour les statistiques qu'il rapporte, voir Types de journaux pour HealthOmics flux de travail.

Une entrée de tâche manifeste indique ce que la tâche a réservé, son type d'instance et sa durée. Il indique ce que la tâche a utilisé en plus de celles-ci, mais pas pour toutes les tâches. Lorsqu'une entrée ne rend pas compte de l'utilisation ou indique des informations inférieures à ce que le travail de la tâche peut prendre en compte, la taille par rapport aux mesures d'exécution de la tâche, pour la raison indiquée dans Alertes.

Trois HealthOmics les comportements limitent ce qu'une modification permet d'enregistrer :

Pour les méthodes d'optimisation prises en compte par ces résultats, voir Méthodes pour optimiser les courses.