Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Depurar un HealthOmics ejecución de flujo de trabajo
HealthOmics informa sobre el comportamiento de una carrera a través de varias fuentes, cada una de las cuales responde a una pregunta diferente. En el caso de una ejecución fallida, léalas en este orden en lugar de empezar por los registros:
1. Lea el registro de ejecución para saber si la ejecución falló y por qué.
1. Lea los registros de tareas, si una tarea falló, cuáles fueron las tareas que fallaron y en qué tipos de instancias. También se puede producir un error en una ejecución antes de que se cree una tarea o una vez finalizada cada tarea.
1. Lea los registros: el registro de tareas para lo que informó una tarea, el registro de ejecución para lo que la ejecución informó fuera de cualquier tarea y el registro del motor para lo que informó el motor.
1. Lee las métricas de ejecución y el registro del manifiesto de ejecución para ver lo que consumió la tarea.
En el caso de una ejecución que se completó pero fue más lenta o más cara de lo que esperabas, empieza por [Compare las ejecuciones del mismo flujo de trabajo](#workflows-run-debug-compare).
La orientación sobre recursos y costos de este tema se aplica a los flujos de trabajo privados, por el motivo expuesto en [Ejecute la optimización para un privado HealthOmics flujo de trabajo](workflows-run-optimize.md). Para ver las operaciones de la API y los campos de respuesta que se utilizan en los pasos siguientes, consulte [Obtenga información sobre la carrera](getinfo-about-runs.md).
En los comandos de este tema, sustituya los valores siguientes por los suyos propios:
`{{run_id}}`
El identificador de la ejecución que está depurando.
`{{duration}}`
La ventana que **aws logs tail** dice: un tiempo relativo como `2h` para una ejecución que finalizó recientemente, o una marca de tiempo como `2026-03-26T22:00:00` para una más antigua.
`{{run_uuid}}`
El `uuid` campo del récord de esa carrera.
`{{task_id}}`
El identificador de una tarea fallida en esa ejecución.
`{{workflow_id}}`
El identificador del flujo de trabajo cuyas ejecuciones desea enumerar.
**Topics**
+ [Diagnostica una ejecución fallida](#workflows-run-debug-failed)
+ [Inspeccione el uso de los recursos con métricas de ejecución](#workflows-run-debug-metrics)
+ [Compare las ejecuciones del mismo flujo de trabajo](#workflows-run-debug-compare)
+ [Convierta los hallazgos en cambios de costo y tamaño](#workflows-run-debug-cost)
## Diagnostica una ejecución fallida
**Para diagnosticar una ejecución fallida**
1. Recupera el registro de la ejecución y lee `status`, `failureReason`, `statusMessage`, y `logLocation`. Conserve la respuesta: úsela en los pasos posteriores. `logLocation` proporciona los ARN del registro de ejecución (`runLogStream`) y el registro del motor (`engineLogStream`).
```
aws omics get-run --id {{run_id}}
```
Busque el valor de `failureReason` en [Motivos de error de ejecución](workflows-run-errors.md). Si `status` no lo es `FAILED`, ver [Valores de estado de ejecución](monitoring-runs.md#run-status-values) en su lugar.
Algunas fallas ocurren antes HealthOmics crean cualquier tarea o una vez finalizada cada tarea, por lo que no dejan ningún registro de la tarea para leerla en los tres pasos siguientes. Un error de rol, entrada, importación o exportación es uno de ellos; también lo es una imagen que HealthOmics rechaza antes de crear la tarea (ECR\_IMAGE\_NOT\_FOUND, ECR\_PERMISSION\_ERROR, ECR\_REPOSITORY\_NOT\_FOUND, o INVALID\_ECR\_IMAGE\_URI). Para cualquiera de ellas, salte al registro de ejecución más adelante en este procedimiento. En caso de que se produzca un error de imagen, `statusMessage` asigna un nombre a la URI de la imagen, así que continúe desde [Imágenes de contenedor para flujos de trabajo privados](workflows-ecr.md) y [Permisos de Amazon ECR](permissions-ecr.md). Si el siguiente paso devuelve una tarea fallida, lee esa tarea en su lugar.
1. Enumera las tareas que fallaron. Cada elemento incluye las tareas `taskId`, que se usa en el siguiente paso, además de su nombre, su `creationTime`y, una vez que los haya alcanzado, su tipo de instancia, `startTime`, y `stopTime`.
```
aws omics list-run-tasks --id {{run_id}} --status FAILED
```
Si no devuelve ninguna tarea, la ejecución es uno de los casos del paso 1: omita los dos pasos siguientes y lea el registro de ejecución.
1. Para cada tarea fallida, recupere su registro. Añade `failureReason`, `statusMessage`, `imageDetails`, y `logStream` a lo que devolvió el paso anterior. `logStream` es el ARN de la secuencia de registro que lee el paso siguiente y el nombre de la secuencia es el siguiente `log-stream:` en él.
```
aws omics get-run-task --id {{run_id}} --task-id {{task_id}}
```
1. Lea el registro de tareas. Los eventos que explican el error se encuentran al final de la secuencia.
```
aws logs tail /aws/omics/WorkflowLog \
--log-stream-names run/{{run_id}}/task/{{task_id}} \
--since {{duration}}
```
Establecer {{duration}} para que comience antes que la tarea: el comando se lee desde entonces hasta ahora y su ventana predeterminada es la de los últimos 10 minutos, por lo que una ejecución que finalizó antes no devuelve ningún evento. Para ver el grupo de registros y el formato de cada transmisión, consulte [Inicia sesión CloudWatch](monitoring-cloudwatch-logs.md#cloudwatch-logs).
**nota**
Para saber por qué es posible que una tarea no tenga ningún registro y para conocer las formas de hacer que una tarea sea más depurable, consulte [Solución de problemas de tareas de flujo](workflow-run-tasks.md#debugging-tasks).
1. Lea cualquiera de los otros dos registros de la carrera que responda a la pregunta que lo trajo aquí. Ambos ejecutan el comando del paso 4 con una secuencia diferente.
```
aws logs tail /aws/omics/WorkflowLog \
--log-stream-names run/{{run_id}} \
--since {{duration}}
```
La ejecución no tiene ninguna tarea fallida
Lea el registro de ejecución, `run/{{run_id}}`, como en el comando anterior. Informa del propio progreso de la ejecución, incluidos los pasos de importación y exportación que fallan sin realizar ninguna tarea. Para ver lo que informa, consulte [Tipos de registro para HealthOmics flujos de trabajo](monitoring-cloudwatch-logs.md#log-descriptions).
Se produjo un error en una tarea y su registro no explica el motivo
Lea el registro del motor, `run/{{run_id}}/engine`, que informa sobre lo que hizo el motor con respecto a la falla, por ejemplo, la posición en la definición del flujo de trabajo. Su ARN está en `logLocation.engineLogStream` desde el paso 1; si ese campo no está en la respuesta, la ejecución no tiene ningún registro del motor.
Para leer la definición en la posición que nombra el motor, expórtela. El siguiente comando devuelve una URL de descarga para la definición que utilizó la ejecución.
```
aws omics get-workflow --id {{workflow_id}} --export DEFINITION
```
El lugar donde continuar depende del motivo del error. En la siguiente lista se describen los errores más comunes de recursos y contenedores. Para ver lo que consumieron las tareas, lo que indica si el error se debió a un problema de tamaño, consulte [Convierta los hallazgos en cambios de costo y tamaño](#workflows-run-debug-cost).
**CANNOT\_START\_CONTAINER\_ERROR, CANNOT\_START\_CONTAINER\_SIZE\_ERROR, o ERROR DE VERIFICACIÓN DE IMAGEN**
HealthOmics creó la tarea y no pudo iniciar su contenedor, por lo que la tarea no generó ningún registro. Toma la imagen del registro de tareas `imageDetails`, a continuación, consulte [Imágenes de contenedor para flujos de trabajo privados](workflows-ecr.md).
**ERROR DE FALTA DE MEMORIA**
Compare el uso de memoria de la tarea con su asignación, tal y como se describe en [¿Cómo puedo adaptar el procesamiento y el almacenamiento a mi flujo de trabajo?](troubleshooting.md#troubleshooting-metrics-right-size), utilizando sus métricas de ejecución o las estadísticas del registro del manifiesto de ejecución, que [Convierta los hallazgos en cambios de costo y tamaño](#workflows-run-debug-cost) localiza. A continuación, aumente la memoria en la definición del flujo de trabajo y compruebe en qué tipo de instancia se selecciona el nuevo valor [Requisitos de computación y memoria para HealthOmics las tareas](memory-and-compute-tasks.md).
**TASK\_TIMED\_OUT o RUN\_TIMED\_OUT**
Confirme si la tarea seguía funcionando cuando se agotó el tiempo de espera. Si no es así, trátela como si no respondiera, en lugar de hacerlo como si fuera lenta, y vea [Guía para ejecuciones que no responden](workflows-run-errors.md#workflows-guidance-unresponsive-runs). Si el límite que puso fin a la ejecución procedía de un grupo de carreras, consulte [Uso de grupos de HealthOmics ejecución](creating-run-groups.md).
## Inspeccione el uso de los recursos con métricas de ejecución
Las métricas de ejecución abarcan una ejecución que aún está en curso, por lo que puedes usarlas antes de que finalice una ejecución. La serie que exista para una ejecución depende del tipo de almacenamiento de ejecución, de su modo de almacenamiento desde cero y de si sus tareas requerían aceleradores, así que comprueba las condiciones en [Métricas disponibles](monitoring-run-metrics.md#monitoring-run-metrics-available) antes de concluir que falta una métrica. Si una tirada no tiene ninguna serie, compruebe que su función pueda publicarla, tal y como se describe en [Habilitar las métricas para una carrera](monitoring-run-metrics.md#monitoring-run-metrics-enabling). Para ver la sintaxis de la consulta y el procedimiento de la consola, consulte [Consultando HealthOmics ejecutar métricas](monitoring-run-metrics.md#monitoring-run-metrics-viewing).
Limite cada consulta a una ejecución con la etiqueta de recurso de ejecución. Per-task las métricas también llevan la etiqueta de recurso de la tarea, que une una serie al registro de la tarea y sus registros. Para ambas etiquetas, consulte [Atributos de comunes](monitoring-run-metrics.md#monitoring-run-metrics-common-attributes).
**nota**
CloudWatch limita tanto el número de series temporales que devuelve una consulta de PromQL como el intervalo de tiempo que abarca. Una ejecución produce al menos una serie por tarea para cada métrica por tarea, y más cuando la métrica se divide por dirección o por GPU. En el caso de una ejecución con muchas tareas, agrega la serie en la propia consulta o filtra por una tarea, una dirección o una GPU. Divida una ejecución larga en ventanas consecutivas. Para conocer los límites actuales, consulte [Límites y restricciones de PromQL](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-PromQL.html#CloudWatch-PromQL-Limits).
## Compare las ejecuciones del mismo flujo de trabajo
Cuando una ejecución es más lenta o más cara que una ejecución anterior del mismo flujo de trabajo, compare las dos ejecuciones tarea por tarea. Alinee las tareas por nombre en lugar de por ID de tarea: recupere las tareas de ambas ejecuciones y agrúpelas por `name`y compare la duración y los valores máximos de cada nombre. Una lectura del registro de manifiestos de cada ejecución muestra los tiempos de cada tarea y, si la entrada los indica, sus picos; **ListRunTasks** te muestra los tiempos de una ejecución que aún está en marcha, sin `--status FAILED` filtro que utiliza el procedimiento anterior.
Compare dos intervalos por tarea: `startTime` a `stopTime` es la duración de la tarea, y `creationTime` a `startTime` es el tiempo que esperó para empezar, lo que cubre sus fases pendiente e inicial en [Valores de estado de la tarea](workflow-run-tasks.md#task-status-values). Una ejecución puede ser mucho más lenta que otra si la duración de cada tarea coincide, porque ninguna métrica de la tarea cubre la espera.
**nota**
Varias tareas de una ejecución pueden compartir un nombre, y el índice de dispersión de un nombre no incluye necesariamente los mismos datos de entrada en ambas ejecuciones. Compara el agregado entre las tareas que comparten un nombre, como la de mayor duración o el pico más alto, en lugar de emparejarlas índice por índice.
Para establecer lo que es normal en un flujo de trabajo, en lugar de comparar dos ejecuciones, agregue un conjunto de las ejecuciones completadas. Run Analyzer hace esto en `--batch` modo, como se describe en [Impacto de la variación del tamaño de los archivos entre ejecuciones](workflows-run-optimize.md#workflows-run-file-variance). Para recopilar las carreras tú mismo, filtra la respuesta de **ListRuns** en `workflowId`. La operación no tiene un filtro de flujo de trabajo propio, por lo que **ListRuns** recorre todas las ejecuciones finalizadas antes de que el filtro las reduzca.
```
aws omics list-runs --status COMPLETED \
--query "items[?workflowId=='{{workflow_id}}'].id"
```
La distribución en un conjunto de ejecuciones, no en una sola, muestra si la asignación de una tarea se ajusta a la varianza de los datos y si una ejecución lenta está fuera del rango normal.
## Convierta los hallazgos en cambios de costo y tamaño
Lo que consume una tarea se encuentra en el registro de manifiestos de ejecución, cuyo flujo es `manifest/run/{{run_id}}/{{run_uuid}}`. HealthOmics lo escribe una vez finalizada la ejecución, así que configúralo {{duration}} para alcanzar la hora de parada de la ejecución en lugar de la hora de finalización de una tarea. Léelo con el mismo **aws logs tail** comando como las otras transmisiones. Para ver las estadísticas que informa, consulte [Tipos de registro para HealthOmics flujos de trabajo](monitoring-cloudwatch-logs.md#log-descriptions).
Una entrada de tarea del manifiesto indica lo que la tarea reservó, su tipo de instancia y su duración. Indica lo que la tarea usó junto con las demás, pero no para todas las tareas. Si una entrada no informa sobre el uso, o informa de una cantidad inferior a la que puede representar el trabajo de la tarea, compare el tamaño con las métricas de ejecución de la tarea, por el motivo indicado en [Avisos](monitoring-run-metrics.md#monitoring-run-metrics-callouts).
Tres HealthOmics los comportamientos limitan lo que ahorra un cambio:
+ El costo de una tarea depende del tipo de instancia que HealthOmics selecciona los recursos que solicitas, no los recursos que usa la tarea. Consulte [Requisitos de computación y memoria para HealthOmics las tareas](memory-and-compute-tasks.md).
+ Los cargos por tareas tienen una duración facturable mínima, por lo que acortar una tarea que ya es corta no ahorra nada. Consulte [Implicaciones del estado de ejecución en los precios](monitoring-runs.md#run-status-billing).
+ El almacenamiento de ejecución estática viene en tamaños fijos, por lo que una reducción solo cambia la factura cuando se reduce a un tamaño admitido más pequeño. Consulte [Almacenamiento de ejecución estático](workflows-run-types.md#workflows-run-type-static).
Para conocer los métodos de optimización en los que se basan estos hallazgos, consulte [Métodos para optimizar las carreras](workflows-run-optimize.md#run-optimize-methods).