As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Depurando um HealthOmics execução do fluxo de trabalho
HealthOmics relata o comportamento de uma corrida por meio de várias fontes, cada uma respondendo a uma pergunta diferente. Para uma execução que falhou, leia-os nesta ordem em vez de começar com os registros:
1. Leia o registro da execução para saber se a execução falhou e por quê.
1. Leia os registros da tarefa, se uma tarefa falhou, para quais tarefas falharam e em quais tipos de instância. Uma execução também pode falhar antes de qualquer tarefa ser criada ou após a conclusão de cada tarefa.
1. Leia os registros: o registro de tarefas para saber o que uma tarefa relatou, o registro de execução para saber o que a execução relatou fora de qualquer tarefa e o registro do mecanismo para saber o que o mecanismo relatou.
1. Leia as métricas de execução e execute o log de manifesto para saber o que a tarefa consumiu.
Para uma corrida que foi concluída, mas foi mais lenta ou mais cara do que você esperava, comece com [Compare execuções do mesmo fluxo de trabalho](#workflows-run-debug-compare).
A orientação de recursos e custos neste tópico se aplica a fluxos de trabalho privados, pelo motivo apresentado em [Execute a otimização para um ambiente privado HealthOmics fluxo de trabalho](workflows-run-optimize.md). Para as operações de API e os campos de resposta que as etapas a seguir usam, consulte [Obtenha informações sobre a execução](getinfo-about-runs.md).
Nos comandos deste tópico, substitua os seguintes valores pelos seus próprios:
`{{run_id}}`
O ID da execução que você está depurando.
`{{duration}}`
A janela que **aws logs tail** lê: um tempo relativo, como `2h` para uma execução que terminou recentemente ou um carimbo de data/hora, como `2026-03-26T22:00:00` para um mais velho.
`{{run_uuid}}`
O `uuid` campo do recorde dessa corrida.
`{{task_id}}`
O ID de uma tarefa que falhou nessa execução.
`{{workflow_id}}`
O ID do fluxo de trabalho cujas execuções você deseja listar.
**Topics**
+ [Diagnosticar uma execução com falha](#workflows-run-debug-failed)
+ [Inspecione o uso de recursos com métricas de execução](#workflows-run-debug-metrics)
+ [Compare execuções do mesmo fluxo de trabalho](#workflows-run-debug-compare)
+ [Transforme descobertas em mudanças de custo e dimensionamento](#workflows-run-debug-cost)
## Diagnosticar uma execução com falha
**Para diagnosticar uma falha na execução**
1. Recupere o registro de execução e leia `status`, `failureReason`, `statusMessage`, e `logLocation`. Guarde a resposta: nas etapas posteriores, use-a. `logLocation` fornece os ARNs do registro de execução (`runLogStream`) e o registro do motor (`engineLogStream`).
```
aws omics get-run --id {{run_id}}
```
Pesquise o valor de `failureReason` em [Motivos de falha na execução](workflows-run-errors.md). Se `status` não é `FAILED`, veja [Valores de status de execução](monitoring-runs.md#run-status-values) em vez disso.
Algumas falhas acontecem antes HealthOmics cria qualquer tarefa ou depois de cada tarefa ser concluída, para que eles não deixem nenhum registro de tarefa para as próximas três etapas de leitura. Uma falha de função, entrada, importação ou exportação é uma; assim como uma imagem que HealthOmics rejeita antes de criar a tarefa (ECR\_IMAGE\_NOT\_FOUND, ECR\_PERMISSION\_ERROR, ECR\_REPOSITORY\_NOT\_FOUND, ou URIL\_ECR\_IMAGE\_URI INVÁLIDO). Para qualquer um deles, vá para o log de execução posteriormente neste procedimento. Em caso de falha de imagem, `statusMessage` nomeia o URI da imagem, então continue a partir de [Imagens de contêiner para fluxos de trabalho privados](workflows-ecr.md) e [Permissões do Amazon ECR](permissions-ecr.md). Se a próxima etapa retornar uma tarefa que falhou, leia essa tarefa em vez disso.
1. Liste as tarefas que falharam. Cada item inclui as tarefas `taskId`, que a próxima etapa usa, além de seu nome, `creationTime`e, uma vez que chegou até eles, seu tipo de instância, `startTime`, e `stopTime`.
```
aws omics list-run-tasks --id {{run_id}} --status FAILED
```
Se isso não retornar nenhuma tarefa, a execução é um dos casos na etapa 1: pule as próximas duas etapas e leia o log de execução.
1. Para cada tarefa que falhou, recupere seu registro. Acrescenta `failureReason`, `statusMessage`, `imageDetails`, e `logStream` para o que a etapa anterior retornou. `logStream` é o ARN do fluxo de log que a próxima etapa lê, e o nome do fluxo segue `log-stream:` nele.
```
aws omics get-run-task --id {{run_id}} --task-id {{task_id}}
```
1. Leia o registro de tarefas. Os eventos que explicam a falha estão no final do fluxo.
```
aws logs tail /aws/omics/WorkflowLog \
--log-stream-names run/{{run_id}}/task/{{task_id}} \
--since {{duration}}
```
Conjunto {{duration}} para começar antes do término da tarefa: o comando é lido de então até agora, e sua janela padrão é os últimos 10 minutos, portanto, uma execução concluída antes não retorna nenhum evento. Para o grupo de registros e o formato de cada fluxo, consulte [Inicia sessão CloudWatch](monitoring-cloudwatch-logs.md#cloudwatch-logs).
**nota**
Para saber por que uma tarefa pode não ter nenhum registro e para saber como tornar uma tarefa mais depurável, consulte [Solução de problemas de tarefas de fluxo](workflow-run-tasks.md#debugging-tasks).
1. Leia qualquer um dos outros dois registros da corrida que responda à pergunta que trouxe você até aqui. Ambos usam o comando da etapa 4 com um fluxo diferente.
```
aws logs tail /aws/omics/WorkflowLog \
--log-stream-names run/{{run_id}} \
--since {{duration}}
```
A execução não tem nenhuma tarefa falhada
Leia o registro de execução, `run/{{run_id}}`, como no comando anterior. Ele relata o próprio progresso da execução, incluindo as etapas de importação e exportação que falham sem nenhuma tarefa. Para saber o que ele relata, consulte [Tipos de registro para HealthOmics fluxos de trabalho](monitoring-cloudwatch-logs.md#log-descriptions).
Uma tarefa falhou e seu registro não explica o porquê
Leia o registro do motor, `run/{{run_id}}/engine`, que relata o que o motor fez com a falha, como a posição na definição do fluxo de trabalho. Seu ARN está em `logLocation.engineLogStream` da etapa 1; se esse campo não estiver na resposta, a execução não terá registro do mecanismo.
Para ler a definição na posição em que o mecanismo nomeia, exporte-a. O comando a seguir retorna um URL de download para a definição usada pela execução.
```
aws omics get-workflow --id {{workflow_id}} --export DEFINITION
```
Onde continuar depende do motivo da falha. A lista a seguir aborda as falhas mais comuns de recursos e contêineres. Para saber o que as tarefas consumiram, o que indica se a falha foi um problema de dimensionamento, consulte [Transforme descobertas em mudanças de custo e dimensionamento](#workflows-run-debug-cost).
**NÃO É POSSÍVEL INICIAR\_CONTAINER\_ERROR, NÃO É POSSÍVEL INICIAR\_CONTAINER\_SIZE\_ERROR, ou FALHA\_VERIFICAÇÃO\_DE IMAGEM**
HealthOmics criou a tarefa e não conseguiu iniciar seu contêiner, então a tarefa não produziu nenhum registro. Pegue a imagem do registro da tarefa `imageDetails`, em seguida, veja [Imagens de contêiner para fluxos de trabalho privados](workflows-ecr.md).
**ERRO\_DO\_DE\_MEMÓRIA**
Compare o uso de memória da tarefa com sua alocação, conforme descrito em [Como faço para dimensionar corretamente a computação e o armazenamento para meu fluxo de trabalho?](troubleshooting.md#troubleshooting-metrics-right-size), usando suas métricas de execução ou suas estatísticas no log do manifesto de execução, que [Transforme descobertas em mudanças de custo e dimensionamento](#workflows-run-debug-cost) localiza. Em seguida, aumente a memória na definição do fluxo de trabalho e verifique em qual tipo de instância o novo valor seleciona [Requisitos de computação e memória para tarefas HealthOmics](memory-and-compute-tasks.md).
**LIMITE DE TEMPO LIMITE DA TAREFA ou TEMPO DE EXECUÇÃO**
Confirme se a tarefa ainda estava funcionando quando o tempo limite expirou. Se não foi, trate-o como algo que não responde, em vez de lento, e veja [Orientação para corridas sem resposta](workflows-run-errors.md#workflows-guidance-unresponsive-runs). Se o limite que encerrou a corrida veio de um grupo de corridas, consulte [Usando grupos de HealthOmics execução](creating-run-groups.md).
## Inspecione o uso de recursos com métricas de execução
As métricas de execução abrangem uma execução que ainda está em andamento, então você pode usá-las antes que a execução termine. A série que existe para uma execução depende do tipo de armazenamento de execução, do modo de armazenamento inicial e se as tarefas solicitaram aceleradores. Portanto, verifique as condições em [Métricas disponíveis](monitoring-run-metrics.md#monitoring-run-metrics-available) antes de concluir que falta uma métrica. Se uma execução não tiver nenhuma série, verifique se sua função pode publicá-la, conforme descrito em [Habilitando métricas para uma corrida](monitoring-run-metrics.md#monitoring-run-metrics-enabling). Para obter a sintaxe da consulta e o procedimento do console, consulte [Consultando HealthOmics métricas de execução](monitoring-run-metrics.md#monitoring-run-metrics-viewing).
Defina o escopo de cada consulta para uma execução com o rótulo do recurso de execução. Per-task as métricas também carregam o rótulo de recurso da tarefa, que une uma série ao registro da tarefa e seus registros. Para os dois rótulos, consulte [Atributos comuns do](monitoring-run-metrics.md#monitoring-run-metrics-common-attributes).
**nota**
CloudWatch limita o número de séries temporais que uma consulta ProMQL retorna e o intervalo de tempo que ela abrange. Uma execução produz pelo menos uma série por tarefa para cada métrica por tarefa e mais quando a métrica se divide por direção ou por GPU. Para uma execução com muitas tarefas, agregue a série na própria consulta ou filtre para uma tarefa, uma direção ou uma GPU. Divida uma longa corrida em janelas consecutivas. Para os limites atuais, consulte [Limites e restrições do ProMQL](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-PromQL.html#CloudWatch-PromQL-Limits).
## Compare execuções do mesmo fluxo de trabalho
Quando uma execução é mais lenta ou mais cara do que uma execução anterior do mesmo fluxo de trabalho, compare as duas execuções tarefa por tarefa. Alinhe as tarefas pelo nome e não pelo ID da tarefa: recupere as tarefas de ambas as execuções e agrupe-as por `name`e compare a duração e os valores de pico de cada nome. Uma leitura do registro de manifesto de cada execução fornece os horários de cada tarefa e, quando a entrada os relata, seus picos; **ListRunTasks** fornece os horários para uma corrida que ainda está acontecendo, sem o `--status FAILED` filtro usado pelo procedimento anterior.
Compare duas extensões por tarefa: `startTime` para `stopTime` é a duração da tarefa e `creationTime` para `startTime` é quanto tempo ele esperou para começar, que abrange suas fases pendente e inicial em [Valores de status da tarefa](workflow-run-tasks.md#task-status-values). Uma execução pode ser muito mais lenta do que outra enquanto a duração de cada tarefa coincide, porque nenhuma métrica de tarefa cobre a espera.
**nota**
Várias tarefas em uma execução podem compartilhar um nome, e um índice de dispersão em um nome não cobre necessariamente os mesmos dados de entrada em ambas as execuções. Compare o agregado entre as tarefas que compartilham um nome, como a duração mais longa ou o pico mais alto, em vez de emparelhá-las índice por índice.
Para estabelecer o que é normal para um fluxo de trabalho em vez de comparar duas execuções, agregue um conjunto de suas execuções concluídas. O Run Analyzer faz isso em `--batch` modo, conforme descrito em [Impacto da variação do tamanho do arquivo entre as execuções](workflows-run-optimize.md#workflows-run-file-variance). Para coletar as corridas você mesmo, filtre a resposta de **ListRuns** em `workflowId`. A operação não tem filtro de fluxo de trabalho próprio, então **ListRuns** percorrem todas as execuções concluídas antes que seu filtro as restrinja.
```
aws omics list-runs --status COMPLETED \
--query "items[?workflowId=='{{workflow_id}}'].id"
```
A distribuição em um conjunto de execuções, e não em uma única execução, mostra se a alocação de uma tarefa se ajusta à variação em seus dados e se uma execução lenta está fora do intervalo normal.
## Transforme descobertas em mudanças de custo e dimensionamento
A tarefa consumida está no log do manifesto de execução, cujo fluxo é `manifest/run/{{run_id}}/{{run_uuid}}`. HealthOmics grava após o término da execução, então defina {{duration}} para alcançar o tempo de parada da execução em vez do tempo de uma tarefa. Leia com o mesmo **aws logs tail** comando como os outros fluxos. Para obter as estatísticas que ele relata, consulte [Tipos de registro para HealthOmics fluxos de trabalho](monitoring-cloudwatch-logs.md#log-descriptions).
Uma entrada de tarefa de manifesto informa o que a tarefa reservou, seu tipo de instância e sua duração. Ele relata o que a tarefa usou junto com elas, mas não para todas as tarefas. Quando uma entrada não relata o uso ou relata menos do que o trabalho da tarefa pode representar, em vez disso, o tamanho é comparado às métricas de execução da tarefa, pelo motivo indicado em [Chamadas](monitoring-run-metrics.md#monitoring-run-metrics-callouts).
Três HealthOmics comportamentos limitam o que uma mudança salva:
+ O custo de uma tarefa segue o tipo de instância que HealthOmics seleciona os recursos que você solicita, não os recursos que a tarefa usa. Consulte [Requisitos de computação e memória para tarefas HealthOmics](memory-and-compute-tasks.md).
+ As cobranças de tarefas têm uma duração mínima faturável, portanto, encurtar uma tarefa já curta não economiza nada. Consulte [Implicações de preços do status de execução](monitoring-runs.md#run-status-billing).
+ O armazenamento de execução estática vem em tamanhos fixos, portanto, uma redução altera a conta somente quando ela cai para um tamanho menor suportado. Consulte [Armazenamento de execução estática](workflows-run-types.md#workflows-run-type-static).
Para os métodos de otimização que alimentam essas descobertas, consulte [Métodos para otimizar execuções](workflows-run-optimize.md#run-optimize-methods).