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.
1. 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.
1. 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é.
1. 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](#workflows-run-debug-compare).
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](workflows-run-optimize.md). 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](getinfo-about-runs.md).
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.
**Topics**
+ [Diagnostiquer un échec d'exécution](#workflows-run-debug-failed)
+ [Inspectez l'utilisation des ressources à l'aide de métriques d'exécution](#workflows-run-debug-metrics)
+ [Comparez les exécutions d'un même flux de travail](#workflows-run-debug-compare)
+ [Transformez les résultats en modifications de coûts et de dimensionnement](#workflows-run-debug-cost)
## 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](workflows-run-errors.md). Si `status` n'est pas `FAILED`, voir [Exécuter les valeurs d'état](monitoring-runs.md#run-status-values) 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](workflows-ecr.md) et [Autorisations Amazon ECR](permissions-ecr.md). Si l'étape suivante renvoie une tâche ayant échoué, lisez plutôt cette tâche.
1. 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.
1. 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}}
```
1. 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](monitoring-cloudwatch-logs.md#cloudwatch-logs).
**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](workflow-run-tasks.md#debugging-tasks).
1. 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](monitoring-cloudwatch-logs.md#log-descriptions).
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](#workflows-run-debug-cost).
**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](workflows-ecr.md).
**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 ?](troubleshooting.md#troubleshooting-metrics-right-size), 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](#workflows-run-debug-cost) 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](memory-and-compute-tasks.md).
**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](workflows-run-errors.md#workflows-guidance-unresponsive-runs). Si la limite qui a mis fin à la course provenait d'un groupe de courses, voir [Utilisation de groupes d' HealthOmics exécution](creating-run-groups.md).
## 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](monitoring-run-metrics.md#monitoring-run-metrics-available) 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](monitoring-run-metrics.md#monitoring-run-metrics-enabling). Pour la syntaxe des requêtes et la procédure de la console, voir [Interrogation HealthOmics exécuter des métriques](monitoring-run-metrics.md#monitoring-run-metrics-viewing).
É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](monitoring-run-metrics.md#monitoring-run-metrics-common-attributes).
**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](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-PromQL.html#CloudWatch-PromQL-Limits).
## 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](workflow-run-tasks.md#task-status-values). 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](workflows-run-optimize.md#workflows-run-file-variance). 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](monitoring-cloudwatch-logs.md#log-descriptions).
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](monitoring-run-metrics.md#monitoring-run-metrics-callouts).
Trois HealthOmics les comportements limitent ce qu'une modification permet d'enregistrer :
+ Le coût d'une tâche dépend du type d'instance HealthOmics sélectionne les ressources que vous demandez, et non les ressources utilisées par la tâche. Consultez [Exigences en matière de calcul et de mémoire pour les HealthOmics tâches](memory-and-compute-tasks.md).
+ Les frais de tâches ont une durée facturable minimale, donc le fait de raccourcir une tâche déjà courte n'économise rien. Consultez [Incidences tarifaires du statut de course](monitoring-runs.md#run-status-billing).
+ Le stockage statique est disponible en tailles fixes, de sorte qu'une réduction ne modifie la facture que lorsqu'elle tombe à une taille prise en charge plus petite. Consultez [Stockage statique](workflows-run-types.md#workflows-run-type-static).
Pour les méthodes d'optimisation prises en compte par ces résultats, voir [Méthodes pour optimiser les courses](workflows-run-optimize.md#run-optimize-methods).