View a markdown version of this page

Risoluzione dei problemi - AWS HealthOmics
Risoluzione dei problemi relativi ai flussi di lavoroRisoluzione dei problemi relativi alle metriche di esecuzioneRisoluzione dei problemi di memorizzazione nella cache delle chiamateRisoluzione dei problemi relativi agli archivi datiRisoluzione dei problemi con Kiro CLI

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Risoluzione dei problemi

I seguenti argomenti possono aiutarti a risolvere i problemi riscontrati durante l'utilizzo HealthOmics di flussi di lavoro e archivi dati.

Risoluzione dei problemi relativi ai flussi di lavoro

Come posso risolvere un problema relativo a un'esecuzione non riuscita?

Utilizza l'operazione GetRun API per recuperare il motivo dell'errore. Per ulteriori informazioni, consulta Motivi di errore dell'esecuzione.

Come posso risolvere un problema relativo a un'attività non riuscita?

Esamina il codice di errore contenuto nel messaggio di errore dell'attività per comprendere l'errore. Esamina i log in dell'attività CloudWatch per visualizzare i messaggi di registrazione dettagliati relativi all'attività. Se non ricevi messaggi di registro dettagliati, puoi modificare il flusso di lavoro per generare istruzioni di registro aggiuntive. Per ulteriori informazioni, consulta Monitoraggio HealthOmics con CloudWatch registri.

Dove posso trovare i log del motore?

HealthOmics pubblica i log del motore quasi CloudWatch in tempo reale per tutte le esecuzioni (riuscite e non riuscite). I log del motore vengono inoltre inviati al bucket Amazon S3 al termine dell'esecuzione. Per ulteriori informazioni, consulta Monitoraggio HealthOmics con CloudWatch registri e Effettua il login in Amazon S3.

Come posso ridurre la dimensione dei parametri di input per un flusso di lavoro?

È possibile specificare fino a 256 KB di parametri di input per un flusso di lavoro. È possibile utilizzare le importazioni di directory o i fogli di esempio per rimanere entro questo vincolo di dimensione. Per ulteriori informazioni, consulta Gestione delle dimensioni dei parametri di esecuzione.

Perché la mia corsa non viene completata?

Se ci sono problemi con il codice e i processi non sono terminati correttamente, l'esecuzione potrebbe non rispondere o «bloccarsi». Per ulteriori informazioni su come prevenire e rilevare le esecuzioni che non rispondono, consulta. Linee guida per le esecuzioni che non rispondono

Risoluzione dei problemi relativi alle metriche di esecuzione

Perché la mia attività viene eseguita più lentamente del previsto?

Un'operazione può essere eseguita lentamente se è associata alla CPU (Central Processing Unit), alla GPU (Graphics Processing Unit) o è in attesa (). input/output I/O Utilizza le CloudWatch metriche relative all'esecuzione quasi in tempo reale per vedere l'utilizzo delle risorse mentre l'attività è ancora in esecuzione:

  • Confronta conaws.omics.task.cpu.usage. aws.omics.task.cpu.limit Un utilizzo prolungato al limite indica che l'attività è CPU-bound e può trarre vantaggio da una maggiore CPU allocata.

  • Per i carichi di lavoro della GPU, controlla. aws.omics.task.gpu.utilization Un basso utilizzo può indicare che l'attività non utilizza la GPU in modo efficace.

  • Verifica la presenza di eventuali aws.omics.task.filesystem.io aws.omics.task.filesystem.operations strozzature I/O .

Per ulteriori informazioni, consulta Esegui metriche per flussi di lavoro privati.

Perché la mia corsa non è riuscita a causa dell'esaurimento dello spazio di archiviazione?

Un'esecuzione può fallire quando esaurisce lo spazio di archiviazione sul file system condiviso. Confrontaaws.omics.run.filesystem.usage, che riporta lo spazio di archiviazione in uso sul file system condiviso dell'esecuzione, rispetto aaws.omics.run.filesystem.limit, che ne indica la capacità totale. È possibile creare dashboard o allarmi per monitorare l'utilizzo dello spazio di archiviazione. Per ulteriori informazioni, consulta Esegui metriche per flussi di lavoro privati.

Come posso dimensionare correttamente l'elaborazione e lo storage per il mio flusso di lavoro?

Esegui il flusso di lavoro una volta e rivedi le CloudWatch metriche per confrontare l'utilizzo effettivo con i limiti allocati:

  • Se l'utilizzo di CPU, GPU o memoria rimane ben al di sotto del limite, puoi ridurre l'allocazione a costi inferiori.

  • Se l'utilizzo è costantemente al limite, aumenta l'allocazione per migliorare le prestazioni o per evitare guasti.

  • aws.omics.run.filesystem.usageDa utilizzare per impostare una dimensione del file system appropriata per l'esecuzione.

Per ulteriori informazioni, consulta Esegui metriche per flussi di lavoro privati.

Perché non vedo le metriche relative alla mia corsa?

Se le metriche relative all'esecuzione e alle attività non sono visualizzate nell'cloudwatch.aws/omicsambito in CloudWatch, verifica quanto segue:

  • Verifica che il ruolo IAM utilizzato per l'esecuzione sia autorizzato a pubblicare le metriche in. CloudWatch

  • Le metriche vengono pubblicate quasi in tempo reale durante l'esecuzione dell'esecuzione. Attendi un breve ritardo (circa 30 secondi) per la visualizzazione dei primi punti dati.

  • Le attività eseguite per meno di 30 secondi potrebbero non avere metriche.

  • Verifica di visualizzare la AWS regione e l'account corretti.

Per ulteriori informazioni, consulta Esegui metriche per flussi di lavoro privati.

In che modo è diverso dalle statistiche sulle risorse del registro di run manifest?

I log di run manifest riportano statistiche aggregate relative a un'esecuzione completata, ad esempio la CPU e la memoria massime e medie, in modo da poter esaminare un'esecuzione finita per individuare opportunità di ottimizzazione. CloudWatch le metriche di esecuzione sono una serie temporale: HealthOmics pubblica i punti dati con la frequenza indicata inMetriche disponibili, in modo da poter monitorare le modifiche all'utilizzo mentre l'esecuzione è in corso e utilizzare dati più dettagliati per risolvere i problemi relativi alle esecuzioni. Per ulteriori informazioni sulle metriche di esecuzione, consulta. Esegui metriche per flussi di lavoro privati

In che modo le metriche di esecuzione in Query Studio sono diverse dal report di esecuzione di Nextflow?

Entrambi segnalano l'utilizzo delle risorse per il flusso di lavoro. Si differenziano per tempistica, copertura del motore e modalità di utilizzo. Utilizza le metriche di esecuzione per monitorare un'esecuzione in corso e utilizza il report di esecuzione di Nextflow per esaminare un'esecuzione completata.

  • Le metriche di esecuzione sono disponibili quasi in tempo reale mentre l'esecuzione è in esecuzione, quindi puoi monitorare l'avanzamento, impostare allarmi e risolvere i problemi di un'esecuzione ancora in corso. Il report di esecuzione di Nextflow viene scritto al termine dell'esecuzione, quindi è possibile utilizzarlo solo per esaminare un'esecuzione a posteriori.

  • HealthOmics emette metriche di esecuzione per ogni esecuzione privata del flusso di lavoro, indipendentemente dal motore di flusso di lavoro utilizzato dall'esecuzione. Il report di esecuzione è specifico di Nextflow e lo HealthOmics esporta solo quando lo configuri per la scrittura. /mnt/workflow/output/

  • Le metriche di esecuzione sono serie CloudWatch temporali, quindi puoi interrogarle con ProMQL, inserirle in un avviso e aggiungerle a una dashboard. Il report di esecuzione è un file statico nella posizione di output di Amazon S3 dell'esecuzione.

Per ulteriori informazioni sul rapporto di esecuzione, consultaGenera report di esecuzione di Nextflow. Per ulteriori informazioni sulle metriche di esecuzione, vedereEsegui metriche per flussi di lavoro privati.

Risoluzione dei problemi di memorizzazione nella cache delle chiamate

I seguenti argomenti possono aiutarti a risolvere i problemi riscontrati con la memorizzazione nella cache delle chiamate.

Perché la mia corsa non viene salvata nella cache?

  1. Verifica che l'esecuzione sia configurata per utilizzare una cache controllando il campo cacheID nella risposta all'operazione GetRun API. Utilizzando la CLI, esegui questo comando:. aws omics get-run —id <run_id>

  2. Se l'esecuzione ha avuto successo, verifica che il comportamento della cache restituito nella GetRun risposta sia CACHE_ALWAYS. Se il comportamento della cache è impostato su CACHE_ON_FAILURE, le esecuzioni verranno salvate nella cache solo in caso di esito negativo.

Perché un'attività non utilizza la voce della cache?

<cache_id><cache_uuid>Nel gruppo di /aws/omics/WorkflowLog CloudWatch log, apri il flusso di log per la cache di esecuzione: runCache//.

  1. Verifica che un'esecuzione precedente abbia creato una voce della cache per l'attività che ti aspettavi fosse memorizzata nella cache. Le esecuzioni salvate nella cache verranno registrate con un messaggio di registro di CACHE_ENTRY_CREATED.

  2. Individua il registro CACHE_MISS per l'operazione ed esegui il comando completato. Se non è presente alcuna voce nel registro, controlla che l'esecuzione sia stata configurata per utilizzare la cache.

  3. Se è stata creata una voce della cache, verifica che CPU, memoria, GPU e container digest siano identici per entrambe le attività. L'ARN del task per il task che ha creato la voce della cache si trova nel messaggio di log.

  4. Se i requisiti di calcolo per entrambe le attività corrispondono, verifica che gli input non siano cambiati tra le attività. A tale scopo, aprite i log del motore. I log del motore sono disponibili in CloudWatch Log Group/aws/omics/WorkflowLog per tutte le esecuzioni. Sono disponibili anche nella directory di output dell'esecuzione dopo il completamento.

Perché la memorizzazione nella cache delle chiamate per un'attività è disabilitata?

Verifica se l'attività è configurata per disattivare la memorizzazione nella cache utilizzando le funzionalità del motore di flusso di lavoro:

  • Per i flussi di lavoro WDL: controlla se l'attività è impostata su volatile nella metasezione true

  • Per i flussi di lavoro Nextflow: controlla se l'attività ha la direttiva sulla cache impostata su false

  • Per i flussi di lavoro CWL: controlla se l'attività ha EnableReuse impostato su per la funzionalità false WorkReuse

Risoluzione dei problemi relativi agli archivi dati

Perché S3 GetObject non funziona sul mio set di lettura?

Più comunemente, l'errore è dovuto a un'autorizzazione mancante. L'autorizzazione di lettura S3 del Sequence Store è una configurazione bidirezionale che richiede sia la policy di accesso S3 del Sequence Store per consentire l'accesso sia il principal IAM ad avere una policy allegata che consenta l'accesso. Per maggiori dettagli sui requisiti delle policy, vedere. Autorizzazioni per l'accesso ai dati tramite Amazon S3 URIs Verifica che siano presenti le seguenti configurazioni:

  • La politica di accesso S3 del sequence store ha consentito esplicitamente l'accesso al principale IAM o alla radice dell'account del principale.

  • Verifica che il responsabile IAM disponga di una politica che fornisce esplicitamente l'autorizzazione alla risorsa a cui si accede. Nota che la policy principale IAM deve utilizzare l'Access Point ARN e non il percorso basato sull'Access Point Alias quando definisce le autorizzazioni e che l'ARN è nella condizione e non viene utilizzato per specificare una risorsa.

  • Se il tuo negozio utilizza una chiave gestita dal cliente (CMK-KMS), assicurati che il responsabile IAM disponga delle autorizzazioni kms:decrypt sulla chiave. Consulta la guida all'accesso tra più account di KMS per configurare l'utilizzo tra gli account.

Se hai una policy che utilizza controlli di accesso basati su tag, assicurati quanto segue:

  • Assicuratevi che l'archivio delle sequenze abbia terminato la sincronizzazione dei tag. Per questo, lo stato del negozio deve essere active e nonupdating.

  • Assicurati che non vi siano errori di battitura nella chiave del tag o nel valore della chiave sul set di lettura e sulla politica.

Perché non riesco a vedere il mio archivio di annotazioni o il mio archivio di varianti in Athena?

In Lake Formation, assicurati di creare un link alle risorse basato sul negozio che è stato condiviso con te. Una volta creato un link a una risorsa a cui hai il permesso di accedere, il negozio dovrebbe essere visibile in Athena. Per ulteriori informazioni, consulta Configurazione di Lake Formation da usare HealthOmics.

Perché non riesco ad accedere al mio archivio dati in Athena?

Se il tuo archivio di annotazioni o varianti è visibile ma ricevi un messaggio di errore che indica che l'accesso è negato, controlla quale versione del motore di query stai utilizzando. Sono supportate solo le query eseguite utilizzando la versione 3 del motore. Per saperne di più sulle versioni del motore di query Athena, consulta la documentazione di Amazon Athena.

Risoluzione dei problemi con Kiro CLI

La CLI di Kiro può aiutarti a semplificare il processo di risoluzione dei problemi:

  • Analisi delle esecuzioni del flusso di lavoro ed esecuzione del debug degli errori delle attività

  • Raccolta di log e messaggi di errore pertinenti

  • Creazione di casi di AWS supporto con tutti i log di debug necessari allegati

  • Elimina le informazioni personali identificabili (PII) dalle informazioni inviate all'assistenza AWS

Per ulteriori informazioni sull'utilizzo di Kiro CLI AWS HealthOmics per la risoluzione dei problemi e la creazione di casi di supporto, consulta il tutorial sull'intelligenza artificiale generativa di Agentic su. HealthOmics GitHub

avvertimento

Quando lavori con Kiro CLI, rivedi tutti i contenuti generati e le azioni proposte prima di procedere. Fornisci feedback per migliorare la qualità delle risposte e soddisfare i requisiti del tuo flusso di lavoro. Per ulteriori informazioni, consulta Considerazioni sulla sicurezza e best practice per Kiro.