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ê.

2. 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.

3. 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.

4. 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.

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. 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.

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.

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. Se status não é FAILED, veja Valores de status de execução 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 e Permissões do Amazon ECR. Se a próxima etapa retornar uma tarefa que falhou, leia essa tarefa em vez disso.

2. Liste as tarefas que falharam. Cada item inclui as tarefas taskId, que a próxima etapa usa, além de seu nome, creationTimee, 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.

3. 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

4. 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.

   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.

5. 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.

   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.

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.

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?, 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 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.

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. Se o limite que encerrou a corrida veio de um grupo de corridas, consulte Usando grupos de HealthOmics execução.

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 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. Para obter a sintaxe da consulta e o procedimento do console, consulte Consultando HealthOmics métricas de execução.

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.

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.

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 namee 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. 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. 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.

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.

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.

• 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.

• 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.

Para os métodos de otimização que alimentam essas descobertas, consulte Métodos para otimizar execuções.