Debug di un HealthOmics esecuzione del flusso di lavoro

HealthOmics riporta il comportamento di una corsa attraverso diverse fonti, ognuna delle quali risponde a una domanda diversa. Per un'esecuzione fallita, leggile in questo ordine invece di iniziare con i log:

1. Leggi il record dell'esecuzione per sapere se l'esecuzione è fallita e perché.

2. Leggi i record delle attività, se un'attività non è riuscita, per quali attività non sono riuscite e su quali tipi di istanza. Un'esecuzione può inoltre fallire prima della creazione di un'attività o al termine di ogni attività.

3. Leggi i registri: il registro delle attività per ciò che è stato segnalato da un'attività, il registro di esecuzione per ciò che l'esecuzione ha riportato all'esterno di qualsiasi attività e il registro del motore per ciò che ha riportato il motore.

4. Leggi le metriche di esecuzione e il registro del manifesto di esecuzione per sapere cosa ha consumato l'attività.

Per un'esecuzione completata ma più lenta o costosa del previsto, inizia da Confronta le esecuzioni dello stesso flusso di lavoro.

Le indicazioni sulle risorse e sui costi in questo argomento si applicano ai flussi di lavoro privati, per il motivo indicato in Esegui l'ottimizzazione per un privato HealthOmics flusso di lavoro. Per le operazioni API e i campi di risposta utilizzati nei passaggi seguenti, consulta Ottieni informazioni sulla corsa.

Nei comandi di questo argomento, sostituisci i seguenti valori con i tuoi:

run_id

L'ID della corsa di cui stai eseguendo il debug.

duration

La finestra che aws logs tail legge: un tempo relativo come 2h per una corsa terminata di recente, o un timestamp come 2026-03-26T22:00:00 per uno più vecchio.

run_uuid

La uuid campo del record di quella corsa.

task_id

L'ID di un'operazione non riuscita in quell'esecuzione.

workflow_id

L'ID del flusso di lavoro di cui desideri elencare le esecuzioni.

Diagnostica un'esecuzione non riuscita

Per diagnosticare un'esecuzione non riuscita

1. Recupera il record dell'esecuzione e leggi status, failureReason, statusMessage, e logLocation. Conserva la risposta: usala nei passaggi successivi. logLocation fornisce gli ARN del log di esecuzione (runLogStream) e il registro del motore (engineLogStream).

   aws omics get-run --id run_id

   Cerca il valore di failureReason nel Motivi di errore dell'esecuzione. Se status non è FAILED, vedi Valori dello stato di esecuzione invece.

   Alcuni fallimenti si verificano prima HealthOmics crea un'attività o dopo che ogni attività è stata completata, in modo da non lasciare alcun record di attività da leggere per i tre passaggi successivi. Un errore di ruolo, input, importazione o esportazione è uno di questi, così come un'immagine HealthOmics rifiuta prima di creare l'attività (ECR_IMAGE_NOT_FOUND, ECR_PERMISSION_ERROR, REPOSITORY_ECR_NON_TROVATO, oppure INVALID_ECR_IMAGE_URI). Per ognuno di essi, passa al registro di esecuzione più avanti in questa procedura. In caso di errore di immagine, statusMessage assegna un nome all'URI dell'immagine, quindi continua da Immagini contenitore per flussi di lavoro privati e Autorizzazioni Amazon ECR. Se il passaggio successivo restituisce un'attività non riuscita, leggi invece quell'attività.

2. Elenca le attività non riuscite. Ogni elemento include le attività taskId, che utilizza il passaggio successivo, più il nome, il suo creationTimee, una volta raggiunti, il tipo di istanza, startTimee stopTime.

   aws omics list-run-tasks --id run_id --status FAILED

   Se non restituisce alcuna attività, l'esecuzione è uno dei casi descritti nel passaggio 1: salta i due passaggi successivi e leggi il registro dell'esecuzione.

3. Per ogni operazione fallita, recupera il relativo record. Aggiunge failureReason, statusMessage, imageDetails, e logStream a ciò che ha restituito il passaggio precedente. logStream è l'ARN del flusso di log letto nel passaggio successivo, seguito dal nome dello stream log-stream: in esso.

   aws omics get-run-task --id run_id --task-id task_id

4. Leggi il registro delle attività. Gli eventi che spiegano l'errore si trovano alla fine dello stream.

   aws logs tail /aws/omics/WorkflowLog \
     --log-stream-names run/run_id/task/task_id \
     --since duration

   Impostare duration da iniziare prima del completamento dell'operazione: il comando viene letto da allora fino a ora e la finestra predefinita è gli ultimi 10 minuti, quindi un'esecuzione terminata prima non restituisce alcun evento. Per il gruppo di log e il formato di ogni stream, vedi Effettua il login CloudWatch.

   Nota

   Per sapere perché un'attività potrebbe non avere alcun registro e per i modi per renderla più debuggabile, vedi Risoluzione dei problemi delle attività del flusso di lavoro.

5. Leggi gli altri due registri della corsa che rispondono alla domanda che ti ha portato qui. Entrambi eseguono il comando step 4 con un flusso diverso.

   aws logs tail /aws/omics/WorkflowLog \
     --log-stream-names run/run_id \
     --since duration

   L'esecuzione non ha alcun compito fallito

   Leggi il registro dell'esecuzione, run/run_id, come nel comando precedente. Riporta lo stato di avanzamento dell'esecuzione, inclusi i passaggi di importazione ed esportazione che falliscono senza alcuna operazione. Per sapere cosa riporta, consulta Tipi di log per HealthOmics flussi di lavoro.

   Un'operazione non è riuscita e il relativo registro non spiega perché

   Leggi il registro del motore, run/run_id/engine, che riporta l'origine del guasto da parte del motore, ad esempio la posizione nella definizione del flusso di lavoro. Il suo ARN è inserito logLocation.engineLogStream dal passaggio 1; se quel campo non è presente nella risposta, l'esecuzione non ha alcun registro del motore.

   Per leggere la definizione nella posizione in cui si trovano i nomi del motore, esportala. Il comando seguente restituisce un URL di download per la definizione utilizzata dall'esecuzione.

   aws omics get-workflow --id workflow_id --export DEFINITION

La posizione in cui continuare dipende dal motivo dell'errore. L'elenco seguente riporta gli errori più comuni relativi alle risorse e ai contenitori. Per informazioni sul consumo delle attività, che indicano se l'errore è stato un problema di dimensionamento, consulta Trasforma i risultati in modifiche ai costi e alle dimensioni.

CANNOT_START_CONTAINER_ERROR, CANNOT_START_CONTAINER_SIZE_ERROR, oppure IMAGE_VERIFICATION_FAILURE

HealthOmics ha creato l'operazione e non è stato possibile avviare il relativo contenitore, pertanto l'attività non ha prodotto alcun registro. Prendi l'immagine dal record dell'attività imageDetails, quindi vedi Immagini contenitore per flussi di lavoro privati.

ERRORE_IN_MEMORIA

Confronta l'utilizzo della memoria dell'attività con la sua allocazione, come descritto in Come posso dimensionare correttamente l'elaborazione e lo storage per il mio flusso di lavoro?, utilizzando le relative metriche di esecuzione o le relative statistiche nel registro del manifesto di esecuzione, che Trasforma i risultati in modifiche ai costi e alle dimensioni individua. Quindi aumenta la memoria nella definizione del flusso di lavoro e controlla in quale tipo di istanza viene selezionato il nuovo valore Requisiti di calcolo e memoria per le attività HealthOmics.

TASK_TIMED_OUT o RUN_TIMED_OUT

Verifica se l'attività stava ancora funzionando quando è scaduto il timeout. In caso contrario, considerala insensibile anziché lenta e verifica Linee guida per le esecuzioni che non rispondono. Se il limite che ha posto fine alla corsa proveniva da un gruppo di corse, vedi Utilizzo dei gruppi di HealthOmics esecuzione.

Ispeziona l'uso delle risorse con le metriche di esecuzione

Le metriche di esecuzione si riferiscono a una corsa ancora in corso, quindi puoi utilizzarle prima del termine di una corsa. Le serie disponibili per una corsa dipendono dal tipo di archiviazione della corsa, dalla modalità di archiviazione scratch e dal fatto che le attività richiedessero acceleratori, quindi controlla le condizioni in Parametri disponibili prima di concludere che manca una metrica. Se un'esecuzione non contiene alcuna serie, verifica che il suo ruolo possa pubblicarle, come descritto in Abilitazione delle metriche per una corsa. Per la sintassi della query e la procedura della console, vedere Interrogazione HealthOmics eseguire metriche.

Assegna a ogni interrogazione un'unica esecuzione con l'etichetta della risorsa run. Per-task le metriche riportano anche l'etichetta della risorsa dell'attività, che unisce una serie al record dell'attività e ai relativi registri. Per entrambe le etichette, vedi Attributi comuni.

Nota

CloudWatch limita sia il numero di serie temporali restituite da una query ProMQL sia l'intervallo di tempo su cui si estende. Un'esecuzione produce almeno una serie per attività per ogni metrica relativa all'attività e più se la metrica viene suddivisa per direzione o per GPU. Per un'esecuzione con molte attività, aggrega le serie nella query stessa o filtra in base a un'attività, una direzione o una GPU. Suddividi una lunga serie in finestre consecutive. Per i limiti attuali, vedi Limiti e restrizioni ProMQL.

Confronta le esecuzioni dello stesso flusso di lavoro

Quando un'esecuzione è più lenta o più costosa di un'esecuzione precedente dello stesso flusso di lavoro, confronta le due esecuzioni attività per attività. Allinea le attività per nome anziché per ID attività: recupera le attività di entrambe le esecuzioni, raggruppale per namee confronta la durata e i valori massimi per ciascun nome. Una lettura del registro del manifest di ogni esecuzione indica i tempi di ogni operazione e, laddove la voce li riporta, i relativi picchi; ListRunTasks ti dà i tempi di una corsa ancora in corso, senza --status FAILED filtro utilizzato dalla procedura precedente.

Confronta due intervalli per attività: startTime a stopTime è la durata dell'attività e creationTime a startTime indica quanto tempo ha atteso per iniziare, che copre le fasi di attesa e di avvio in Valori relativi allo stato dell'attività. Un'esecuzione può essere molto più lenta di un'altra se la durata di ogni attività corrisponde, perché nessuna metrica dell'attività copre l'attesa.

Nota

Diverse attività in un'unica esecuzione possono condividere lo stesso nome e un indice di dispersione in un nome non copre necessariamente gli stessi dati di input in entrambe le esecuzioni. Confronta l'aggregato tra le attività che condividono lo stesso nome, ad esempio la durata più lunga o il picco più alto, anziché associarle indice per indice.

Per stabilire cosa è normale per un flusso di lavoro anziché confrontare due esecuzioni, aggrega una serie di esecuzioni completate. Run Analyzer esegue questa operazione in --batch modalità, come descritto in Impatto della varianza delle dimensioni dei file tra le esecuzioni. Per raccogliere tu stesso le run, filtra la risposta di ListRuns sul workflowId. L'operazione non dispone di un proprio filtro di flusso di lavoro, quindi ListRuns pagine dopo ogni esecuzione completata prima che il filtro le restringa.

aws omics list-runs --status COMPLETED \
  --query "items[?workflowId=='workflow_id'].id"

La distribuzione su una serie di esecuzioni, non su una singola esecuzione, mostra se l'allocazione di un'attività corrisponde alla varianza dei dati e se un'esecuzione dall'aspetto lento non rientra nell'intervallo normale.

Trasforma i risultati in modifiche ai costi e alle dimensioni

L'attività consumata è contenuta nel registro del manifesto di esecuzione, il cui flusso è manifest/run/run_id/run_uuid. HealthOmics lo scrive al termine della corsa, quindi impostato duration per raggiungere il tempo di fine dell'esecuzione anziché quello di un'attività. Leggilo con lo stesso aws logs tail comando come gli altri stream. Per le statistiche che riporta, vedi Tipi di log per HealthOmics flussi di lavoro.

Una voce del task del manifesto riporta ciò che l'attività ha riservato, il tipo di istanza e la durata. Riporta ciò che l'attività ha utilizzato insieme a quelle, ma non per tutte le attività. Se una voce non riporta l'utilizzo o riporta valori inferiori a quelli consentiti dal lavoro dell'attività, la dimensione viene invece confrontata con le metriche di esecuzione dell'attività, per il motivo indicato in Callout.

Tre HealthOmics i comportamenti limitano il risparmio di una modifica:

• Il costo di un'attività segue il tipo di istanza che HealthOmics seleziona le risorse richieste, non le risorse utilizzate dall'attività. Consulta Requisiti di calcolo e memoria per le attività HealthOmics.

• Gli addebiti delle attività hanno una durata minima fatturabile, quindi abbreviare un'attività già breve non consente di risparmiare nulla. Consulta Implicazioni relative ai prezzi dello stato di esecuzione.

• L'archiviazione statica è disponibile in dimensioni fisse, pertanto una riduzione comporta un aumento della fattura solo quando scende a una dimensione supportata inferiore. Consulta Archiviazione statica di esecuzione.

Per i metodi di ottimizzazione utilizzati da questi risultati, consulta Metodi per ottimizzare le corse.