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

# Debug di un HealthOmics esecuzione del flusso di lavoro
<a name="workflows-run-debug"></a>

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

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

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

1. 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](#workflows-run-debug-compare).

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](workflows-run-optimize.md). Per le operazioni API e i campi di risposta utilizzati nei passaggi seguenti, consulta [Ottieni informazioni sulla corsa](getinfo-about-runs.md).

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.

**Topics**
+ [Diagnostica un'esecuzione non riuscita](#workflows-run-debug-failed)
+ [Ispeziona l'uso delle risorse con le metriche di esecuzione](#workflows-run-debug-metrics)
+ [Confronta le esecuzioni dello stesso flusso di lavoro](#workflows-run-debug-compare)
+ [Trasforma i risultati in modifiche ai costi e alle dimensioni](#workflows-run-debug-cost)

## Diagnostica un'esecuzione non riuscita
<a name="workflows-run-debug-failed"></a>

**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](workflows-run-errors.md). Se `status` non è `FAILED`, vedi [Valori dello stato di esecuzione](monitoring-runs.md#run-status-values) 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](workflows-ecr.md) e [Autorizzazioni Amazon ECR](permissions-ecr.md). Se il passaggio successivo restituisce un'attività non riuscita, leggi invece quell'attività.

1. Elenca le attività non riuscite. Ogni elemento include le attività `taskId`, che utilizza il passaggio successivo, più il nome, il suo `creationTime`e, una volta raggiunti, il tipo di istanza, `startTime`e `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.

1. 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}}
   ```

1. 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](monitoring-cloudwatch-logs.md#cloudwatch-logs).
**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](workflow-run-tasks.md#debugging-tasks).

1. 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](monitoring-cloudwatch-logs.md#log-descriptions).  
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](#workflows-run-debug-cost).

**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](workflows-ecr.md).

**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?](troubleshooting.md#troubleshooting-metrics-right-size), 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](#workflows-run-debug-cost) 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](memory-and-compute-tasks.md).

**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](workflows-run-errors.md#workflows-guidance-unresponsive-runs). Se il limite che ha posto fine alla corsa proveniva da un gruppo di corse, vedi [Utilizzo dei gruppi di HealthOmics esecuzione](creating-run-groups.md).

## Ispeziona l'uso delle risorse con le metriche di esecuzione
<a name="workflows-run-debug-metrics"></a>

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](monitoring-run-metrics.md#monitoring-run-metrics-available) 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](monitoring-run-metrics.md#monitoring-run-metrics-enabling). Per la sintassi della query e la procedura della console, vedere [Interrogazione HealthOmics eseguire metriche](monitoring-run-metrics.md#monitoring-run-metrics-viewing).

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](monitoring-run-metrics.md#monitoring-run-metrics-common-attributes).

**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](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-PromQL.html#CloudWatch-PromQL-Limits).

## Confronta le esecuzioni dello stesso flusso di lavoro
<a name="workflows-run-debug-compare"></a>

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 `name`e 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à](workflow-run-tasks.md#task-status-values). 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](workflows-run-optimize.md#workflows-run-file-variance). 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
<a name="workflows-run-debug-cost"></a>

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](monitoring-cloudwatch-logs.md#log-descriptions).

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](monitoring-run-metrics.md#monitoring-run-metrics-callouts).

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](memory-and-compute-tasks.md).
+ 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](monitoring-runs.md#run-status-billing).
+ 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](workflows-run-types.md#workflows-run-type-static).

Per i metodi di ottimizzazione utilizzati da questi risultati, consulta [Metodi per ottimizzare le corse](workflows-run-optimize.md#run-optimize-methods).