View a markdown version of this page

Solução de problemas - AWS HealthOmics

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

Solução de problemas

Os tópicos a seguir podem ajudá-lo a solucionar problemas que você encontra ao usar HealthOmics fluxos de trabalho e armazenamentos de dados.

Solucionar problemas com fluxos de trabalho

Como soluciono problemas de uma execução com falha?

Use a operação GetRun da API para recuperar o motivo da falha. Para obter mais informações, consulte Motivos de falha na execução.

Como soluciono problemas de uma tarefa que falhou?

Examine o código de erro da mensagem de falha da tarefa para entender a falha. Examine os logins da tarefa CloudWatch para ver as mensagens de registro detalhadas da tarefa. Se você não estiver recebendo mensagens de registro detalhadas, poderá revisar seu fluxo de trabalho para gerar instruções de registro adicionais. Para obter mais informações, consulte Monitoramento HealthOmics com CloudWatch registros.

Onde encontro os registros do motor?

HealthOmics publica os registros do mecanismo quase CloudWatch em tempo real para todas as execuções (bem-sucedidas e com falha). Os registros do mecanismo também são entregues ao seu bucket do Amazon S3 após a conclusão da execução. Para obter mais informações, consulte Monitoramento HealthOmics com CloudWatch registros e Logs no Amazon S3.

Como posso reduzir o tamanho do parâmetro de entrada para um fluxo de trabalho?

Você pode especificar até 50 KB de parâmetros de entrada para um fluxo de trabalho. Você pode usar importações de diretórios ou folhas de amostra para permanecer dentro dessa restrição de tamanho. Para obter mais informações, consulte Gerenciando o tamanho dos parâmetros de execução.

Por que minha corrida não está concluída?

Se houver problemas com seu código e os processos não tiverem sido encerrados corretamente, sua execução poderá parar de responder ou ficar “travada”. Para obter mais informações sobre como evitar e detectar execuções que não respondem, consulte. Orientação para corridas sem resposta

Solução de problemas de cache de chamadas

Os tópicos a seguir podem ajudá-lo a solucionar problemas encontrados com o cache de chamadas.

Por que minha execução não está sendo salva no cache?

  1. Verifique se a execução está configurada para usar um cache verificando o campo cacheID na resposta da operação da GetRun API. Usando a CLI, execute este comando:aws omics get-run —id <run_id>.

  2. Se a execução for bem-sucedida, verifique se o comportamento do cache retornado na GetRun resposta é CACHE_ALWAYS. Se o comportamento do cache for definido como CACHE_ON_FAILURE, as execuções só serão salvas no cache quando falharem.

Por que uma tarefa não está usando a entrada de cache?

<cache_id><cache_uuid>No grupo de /aws/omics/WorkflowLog CloudWatch registros, abra o fluxo de registros para o cache de execução: runCache//.

  1. Verifique se uma execução anterior criou uma entrada de cache para a tarefa que você esperava que fosse armazenada em cache. As execuções salvas no cache serão gravadas com uma mensagem de log de CACHE_ENTRY_CREATED.

  2. Localize o log CACHE_MISS da tarefa e execute-o concluído. Se não houver entrada de registro, verifique se a execução foi configurada para usar o cache.

  3. Se uma entrada de cache foi criada, verifique se as CPUs, a memória, as GPUs e o resumo do contêiner são idênticos para ambas as tarefas. O ARN da tarefa que criou a entrada de cache está na mensagem de log.

  4. Se os requisitos de computação para ambas as tarefas corresponderem, verifique se as entradas não foram alteradas entre as tarefas. Para fazer isso, abra os registros do motor. Os registros do motor estão disponíveis no Grupo de CloudWatch Registros/aws/omics/WorkflowLog para todas as execuções. Eles também estão disponíveis no diretório de saída da execução após a conclusão.

Por que o cache de chamadas para uma tarefa está desativado?

Verifique se a tarefa está configurada para desativar o armazenamento em cache usando os recursos do mecanismo de fluxo de trabalho:

  • Para fluxos de trabalho WDL: verifique se a tarefa tem volatile definido como true na seção meta

  • Para fluxos de trabalho do Nextflow: verifique se a tarefa tem a diretiva de cache definida como false

  • Para fluxos de trabalho CWL: verifique se a tarefa tem EnableReuse definido como para o recurso false WorkReuse

Solução de problemas de armazenamento de dados

Por que o S3 está GetObject falhando no meu conjunto de leitura?

Mais comumente, a falha ocorre devido à falta de uma permissão. A permissão de leitura do Sequence Store S3 é uma configuração bidirecional que exige que a política de acesso do Sequence Store S3 permita o acesso e o principal do IAM tenha uma política anexada permitindo o acesso. Para obter mais detalhes sobre os requisitos da política, consultePermissões para acesso a dados usando o Amazon S3 URIs. Verifique se as seguintes configurações estão em vigor:

  • A política de acesso do Sequence Store S3 permitiu explicitamente o acesso ao principal do IAM ou à raiz da conta do principal.

  • Verifique se o diretor do IAM tem uma política que fornece permissão explícita ao recurso que está sendo acessado. Observe que a política principal do IAM deve usar o ARN do ponto de acesso e não o caminho baseado no alias do ponto de acesso ao definir as permissões e que o ARN está na condição e não é usado para especificar um recurso.

  • Se sua loja usa uma chave gerenciada pelo cliente (CMK-KMS), certifique-se de que o principal do IAM tenha permissões kms:decrypt na chave. Consulte o guia de acesso entre contas do KMS para configurar o uso em todas as contas.

Se você tiver uma política que usa controles de acesso baseados em tags, verifique o seguinte:

  • Certifique-se de que o armazenamento de sequências tenha concluído a sincronização das tags. Para isso, o status da loja precisa ser active e nãoupdating.

  • Certifique-se de que não haja erros de digitação na chave da tag ou no valor da chave no conjunto de leitura e na política.

Por que não consigo ver minha loja de anotações ou loja de variantes no Athena?

Em Lake Formation, certifique-se de criar um link de recurso com base na loja que foi compartilhada com você. Depois de criar um link de recurso que você tenha permissão para acessar, a loja deverá estar visível no Athena. Para obter mais informações, consulte Configurando o Lake Formation para usar HealthOmics.

Por que não consigo acessar meu armazenamento de dados no Athena?

Se seu repositório de anotações ou variantes estiver visível, mas você estiver recebendo uma mensagem de erro informando que o acesso foi negado, verifique qual versão do mecanismo de consulta você está usando. Somente consultas executadas usando a versão 3 do mecanismo são suportadas. Para ler mais sobre as versões do mecanismo de consulta do Athena, consulte a documentação do Amazon Athena.

Solução de problemas com o Kiro CLI

O Kiro CLI pode ajudar a simplificar seu processo de solução de problemas ao:

  • Análise de execuções de fluxo de trabalho e falhas de tarefas de depuração

  • Coletando registros e mensagens de erro relevantes

  • Criação de casos de AWS suporte com todos os registros de depuração necessários anexados

  • Elimina informações de identificação pessoal (PII) das informações enviadas ao Suporte AWS

Para obter mais informações sobre como usar o Kiro CLI com AWS HealthOmics para solucionar problemas e criar casos de suporte, consulte o tutorial de IA generativa HealthOmics Agentic em. GitHub

Atenção

Ao trabalhar com o Kiro CLI, revise todo o conteúdo gerado e as ações propostas antes de continuar. Forneça feedback para melhorar a qualidade da resposta e atender aos requisitos do seu fluxo de trabalho. Para obter mais informações, consulte Considerações de segurança e melhores práticas para o Kiro.