Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Debuggen eines HealthOmics Workflow-Ausführung
HealthOmics meldet das Verhalten eines Laufs anhand mehrerer Quellen, von denen jede eine andere Frage beantwortet. Lesen Sie sie bei einem fehlgeschlagenen Lauf in dieser Reihenfolge, anstatt mit den Protokollen zu beginnen:
1. Lesen Sie den Ausführungsdatensatz, um zu erfahren, ob der Lauf fehlgeschlagen ist und warum.
1. Lesen Sie die Aufgabenaufzeichnungen, ob eine Aufgabe fehlgeschlagen ist, für welche Aufgaben und für welche Instanztypen sie fehlgeschlagen sind. Eine Ausführung kann auch fehlschlagen, bevor eine Aufgabe erstellt wurde oder nachdem jede Aufgabe abgeschlossen wurde.
1. Lesen Sie die Protokolle: das Aufgabenprotokoll für das, was eine Aufgabe gemeldet hat, das Ausführungsprotokoll für das, was der Lauf außerhalb einer Aufgabe gemeldet hat, und das Engine-Protokoll für das, was die Engine gemeldet hat.
1. Lesen Sie die Ausführungsmetriken und führen Sie das Manifestprotokoll aus, um zu erfahren, was die Aufgabe verbraucht hat.
Für einen Lauf, der zwar abgeschlossen wurde, aber langsamer oder teurer als erwartet war, beginnen Sie mit [Vergleiche die Läufe desselben Workflows](#workflows-run-debug-compare).
Die Ressourcen- und Kostenleitlinien in diesem Thema beziehen sich auf private Workflows, und zwar aus dem unter [Führen Sie die Optimierung für ein privates aus HealthOmics Arbeitsablauf](workflows-run-optimize.md). Die API-Operationen und Antwortfelder, die in den folgenden Schritten verwendet werden, finden Sie unter [Holen Sie sich Informationen zum Lauf](getinfo-about-runs.md).
Ersetzen Sie in den Befehlen in diesem Thema die folgenden Werte durch Ihre eigenen:
`{{run_id}}`
Die ID der Ausführung, die Sie debuggen.
`{{duration}}`
Das Fenster, das **aws logs tail** lautet: eine relative Zeit wie `2h` für einen Lauf, der kürzlich beendet wurde, oder einen Zeitstempel wie `2026-03-26T22:00:00` für einen älteren.
`{{run_uuid}}`
Der `uuid` Feld des Datensatzes dieses Laufs.
`{{task_id}}`
Die ID einer fehlgeschlagenen Aufgabe in diesem Lauf.
`{{workflow_id}}`
Die ID des Workflows, dessen Ausführungen Sie auflisten möchten.
**Topics**
+ [Diagnostiziert einen fehlgeschlagenen Lauf](#workflows-run-debug-failed)
+ [Untersuchen Sie die Ressourcennutzung anhand von Run-Metriken](#workflows-run-debug-metrics)
+ [Vergleiche die Läufe desselben Workflows](#workflows-run-debug-compare)
+ [Verwandeln Sie die Ergebnisse in Kosten- und Größenänderungen](#workflows-run-debug-cost)
## Diagnostiziert einen fehlgeschlagenen Lauf
**Um einen fehlgeschlagenen Lauf zu diagnostizieren**
1. Rufen Sie den Laufdatensatz ab und lesen Sie `status`, `failureReason`, `statusMessage`, und `logLocation`. Bewahren Sie die Antwort auf: In späteren Schritten wird sie verwendet. `logLocation` gibt die ARNs des Ausführungsprotokolls an (`runLogStream`) und das Motorprotokoll (`engineLogStream`).
```
aws omics get-run --id {{run_id}}
```
Schlagen Sie den Wert von nach `failureReason` in [Gründe für Ausführungsfehler](workflows-run-errors.md). Wenn `status` ist nicht `FAILED`, siehst du [Werte für den Ausführungsstatus](monitoring-runs.md#run-status-values) stattdessen.
Einige Fehler treten schon einmal auf HealthOmics erstellt eine beliebige Aufgabe oder nach Abschluss jeder Aufgabe, sodass für die nächsten drei Schritte kein Datensatz zum Lesen übrig bleibt. Eine Rolle, ein Eingabe-, Import- oder Exportfehler sind das Gleiche wie ein Bild HealthOmics lehnt ab, bevor die Aufgabe erstellt wird (ECR\_IMAGE\_NOT\_FOUND, ECR\_PERMISSION\_ERROR, ECR\_REPOSITORY\_NICHT\_GEFUNDEN, oder INVALID\_ECR\_IMAGE\_URI). Gehen Sie bei jedem von ihnen später in diesem Verfahren zum Ausführungsprotokoll über. Bei einem Image-Fehler `statusMessage` benennt die Bild-URI, fahren Sie also fort von [Container-Images für private Workflows](workflows-ecr.md) und [Amazon-ECR-Berechtigungen](permissions-ecr.md). Wenn der nächste Schritt eine fehlgeschlagene Aufgabe zurückgibt, lesen Sie stattdessen diese Aufgabe.
1. Listet die fehlgeschlagenen Aufgaben auf. Jedes Element enthält die Aufgaben `taskId`, das im nächsten Schritt verwendet wird, plus seinen Namen, `creationTime`, und, sobald es sie erreicht hat, seinen Instanztyp, `startTime`, und `stopTime`.
```
aws omics list-run-tasks --id {{run_id}} --status FAILED
```
Wenn dadurch keine Aufgaben zurückgegeben werden, ist der Lauf einer der Fälle in Schritt 1: Überspringen Sie die nächsten beiden Schritte und lesen Sie das Ausführungsprotokoll.
1. Rufen Sie für jede fehlgeschlagene Aufgabe ihren Datensatz ab. Es fügt hinzu `failureReason`, `statusMessage`, `imageDetails`, und `logStream` zu dem, was der vorherige Schritt zurückgegeben hat. `logStream` ist der ARN des Log-Streams, den der nächste Schritt liest, und der Name des Streams folgt `log-stream:` darin.
```
aws omics get-run-task --id {{run_id}} --task-id {{task_id}}
```
1. Lesen Sie das Aufgabenprotokoll. Die Ereignisse, die den Fehler erklären, befinden sich am Ende des Streams.
```
aws logs tail /aws/omics/WorkflowLog \
--log-stream-names run/{{run_id}}/task/{{task_id}} \
--since {{duration}}
```
Eingestellt {{duration}} um zu starten, bevor die Aufgabe ausgeführt wurde: Der Befehl liest von damals bis heute, und sein Standardfenster sind die letzten 10 Minuten, sodass eine Ausführung, die früher abgeschlossen wurde, keine Ereignisse zurückgibt. Die Protokollgruppe und das Format jedes Streams finden Sie unter [Loggt sich ein CloudWatch](monitoring-cloudwatch-logs.md#cloudwatch-logs).
**Anmerkung**
Warum eine Aufgabe möglicherweise überhaupt kein Protokoll hat und wie Sie eine Aufgabe besser debuggen können, finden Sie unter [Problembehandlung bei Workflow-Aufgaben](workflow-run-tasks.md#debugging-tasks).
1. Lesen Sie, welches der beiden anderen Protokolle des Laufs die Frage beantwortet, die Sie hierher gebracht hat. Beide verwenden den Befehl Schritt 4 mit einem anderen Stream.
```
aws logs tail /aws/omics/WorkflowLog \
--log-stream-names run/{{run_id}} \
--since {{duration}}
```
Der Lauf hat keine fehlgeschlagene Aufgabe
Lesen Sie das Laufprotokoll, `run/{{run_id}}`, wie im vorherigen Befehl. Es meldet den eigenen Fortschritt des Laufs, einschließlich der Import- und Exportschritte, die ohne Aufgabe fehlschlagen. Was es meldet, finden Sie unter [Protokolltypen für HealthOmics Workflows](monitoring-cloudwatch-logs.md#log-descriptions).
Eine Aufgabe ist fehlgeschlagen und ihr Protokoll erklärt nicht, warum
Lesen Sie das Motorprotokoll, `run/{{run_id}}/engine`, in dem berichtet wird, was die Engine aus dem Ausfall gemacht hat, z. B. die Position in der Workflow-Definition. Sein ARN ist in `logLocation.engineLogStream` ab Schritt 1; wenn dieses Feld nicht in der Antwort enthalten ist, enthält der Lauf kein Motorprotokoll.
Um die Definition an der Position zu lesen, die die Engine benennt, exportieren Sie sie. Der folgende Befehl gibt eine Download-URL für die Definition zurück, die der Lauf verwendet hat.
```
aws omics get-workflow --id {{workflow_id}} --export DEFINITION
```
Wo Sie fortfahren müssen, hängt vom Grund des Fehlers ab. Die folgende Liste behandelt die häufigsten Ressourcen- und Containerfehler. Wie viel die Aufgaben in Anspruch genommen haben und ob es sich bei dem Fehler um ein Größenproblem handelte, finden Sie unter [Verwandeln Sie die Ergebnisse in Kosten- und Größenänderungen](#workflows-run-debug-cost).
**CONTAINER\_FEHLER KANN NICHT GESTARTET WERDEN, FEHLER IN DER GRÖSSE DES CONTAINERS KANN NICHT GESTARTET WERDEN, oder IMAGE\_VERIFICATION\_FAILURE**
HealthOmics hat die Aufgabe erstellt und konnte ihren Container nicht starten, sodass die Aufgabe kein Protokoll erstellt hat. Nehmen Sie das Bild aus den Datensätzen der Aufgabe `imageDetails`, dann sieh [Container-Images für private Workflows](workflows-ecr.md).
**FEHLER BEI UNZUREICHENDEM ARBEITSSPEICHER**
Vergleichen Sie den Speicherverbrauch der Aufgabe mit ihrer Zuweisung, wie unter beschrieben [Wie dimensioniere ich die Rechenleistung und den Speicher für meinen Workflow richtig?](troubleshooting.md#troubleshooting-metrics-right-size), wobei entweder die zugehörigen Ausführungsmetriken oder die Statistiken im Ausführungsmanifestprotokoll verwendet werden [Verwandeln Sie die Ergebnisse in Kosten- und Größenänderungen](#workflows-run-debug-cost) lokalisiert. Erhöhen Sie dann den Speicher in der Workflow-Definition und überprüfen Sie, in welchem Instanztyp der neue Wert ausgewählt wird [Rechen- und Speicheranforderungen für HealthOmics Aufgaben](memory-and-compute-tasks.md).
**TASK\_TIMED\_OUT oder RUN\_TIMED\_OUT**
Bestätigen Sie, ob die Aufgabe noch funktionierte, als das Timeout abgelaufen war. Wenn nicht, behandeln Sie es als nicht reagierend und nicht als langsam, und sehen Sie [Hinweise für Läufe, die nicht reagieren](workflows-run-errors.md#workflows-guidance-unresponsive-runs). Wenn das Limit, das den Lauf beendete, von einer Run-Gruppe stammte, siehe [HealthOmics Run-Gruppen verwenden](creating-run-groups.md).
## Untersuchen Sie die Ressourcennutzung anhand von Run-Metriken
Die Ausführungsmetriken decken einen Lauf ab, der noch im Gange ist. Sie können sie also verwenden, bevor ein Lauf abgeschlossen ist. Welche Serien für einen Lauf existieren, hängt von seinem Laufspeichertyp, seinem Scratch-Speichermodus und davon ab, ob für seine Aufgaben Beschleuniger angefordert wurden. Prüfen Sie daher die Bedingungen unter [Verfügbare Metriken](monitoring-run-metrics.md#monitoring-run-metrics-available) bevor Sie zu dem Schluss kommen, dass eine Metrik fehlt. Wenn ein Rechenlauf überhaupt keine Datenreihen enthält, überprüfen Sie, ob die entsprechende Funktion diese auch veröffentlichen könnte, wie unter [Metriken für einen Lauf aktivieren](monitoring-run-metrics.md#monitoring-run-metrics-enabling). Die Abfragesyntax und das Konsolenverfahren finden Sie unter [Abfragen HealthOmics Metriken ausführen](monitoring-run-metrics.md#monitoring-run-metrics-viewing).
Beschränken Sie jede Abfrage auf einen Lauf mit der Bezeichnung „Run Resource“. Per-task Metriken tragen auch das Task-Resource-Label, das eine Reihe mit dem Aufgabendatensatz und seinen Protokollen verknüpft. Für beide Labels siehe [Gängige -Attribute](monitoring-run-metrics.md#monitoring-run-metrics-common-attributes).
**Anmerkung**
CloudWatch begrenzt sowohl die Anzahl der Zeitreihen, die eine PromQL-Abfrage zurückgibt, als auch den Zeitraum, den sie umfasst. Ein Lauf erzeugt mindestens eine Serie pro Aufgabe für jede aufgabenbezogene Metrik und mehr, wenn die Metrik nach Richtung oder nach GPU aufgeteilt wird. Bei einer Ausführung mit vielen Aufgaben aggregieren Sie die Reihen in der Abfrage selbst oder filtern Sie nach einer Aufgabe, einer Richtung oder einer GPU. Teilen Sie einen langen Lauf in aufeinanderfolgende Fenster auf. Die aktuellen Grenzwerte finden Sie unter [Limits und Einschränkungen von PromQL](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-PromQL.html#CloudWatch-PromQL-Limits).
## Vergleiche die Läufe desselben Workflows
Wenn eine Ausführung langsamer oder teurer ist als eine frühere Ausführung desselben Workflows, vergleichen Sie die beiden Ausführungen Aufgabe für Aufgabe. Ordnen Sie die Aufgaben nach Namen statt nach Aufgaben-ID aus: Rufen Sie die Aufgaben beider Läufe ab und gruppieren Sie sie nach `name`, und vergleichen Sie die Dauer und die Spitzenwerte für jeden Namen. Ein Lesen des Manifestprotokolls jedes Durchlaufs gibt Ihnen die Zeiten der einzelnen Aufgaben und, sofern der Eintrag sie meldet, die Spitzenwerte; **ListRunTasks** gibt dir die Zeiten für einen Lauf, der noch läuft, ohne `--status FAILED` Filter, den das vorhergehende Verfahren verwendet.
Vergleichen Sie zwei Zeiträume pro Aufgabe: `startTime` zu `stopTime` ist die Dauer der Aufgabe und `creationTime` zu `startTime` gibt an, wie lange es auf den Start gewartet hat. Dies umfasst die Phasen Ausstehend und Starten in [Werte für den Aufgabenstatus](workflow-run-tasks.md#task-status-values). Ein Lauf kann viel langsamer sein als ein anderer, solange die Dauer jeder Aufgabe gleich ist, da keine Task-Metrik die Wartezeit abdeckt.
**Anmerkung**
Mehrere Aufgaben in einem Lauf können denselben Namen haben, und ein Streuindex in einem Namen deckt nicht unbedingt dieselben Eingabedaten in beiden Durchläufen ab. Vergleichen Sie das Aggregat der Aufgaben, die einen gemeinsamen Namen haben, z. B. die längste Dauer oder den höchsten Spitzenwert, anstatt sie Index für Index zu paaren.
Aggregieren Sie eine Gruppe der abgeschlossenen Läufe, um festzustellen, was für einen Workflow normal ist, anstatt zwei Läufe zu vergleichen. Run Analyzer macht das in `--batch` Modus, wie beschrieben unter [Auswirkung der Dateigrößenabweichung zwischen Durchläufen](workflows-run-optimize.md#workflows-run-file-variance). Um die Läufe selbst zu sammeln, filtern Sie die Antwort von **ListRuns** auf `workflowId`. Die Operation hat also keinen eigenen Workflow-Filter **ListRuns** durchsucht jeden abgeschlossenen Durchlauf, bevor Ihr Filter sie einschränkt.
```
aws omics list-runs --status COMPLETED \
--query "items[?workflowId=='{{workflow_id}}'].id"
```
Die Verteilung über eine Reihe von Durchläufen, nicht über einen einzelnen Lauf, zeigt, ob die Zuordnung einer Aufgabe der Varianz in Ihren Daten entspricht und ob ein langsam aussehender Lauf außerhalb des normalen Bereichs liegt.
## Verwandeln Sie die Ergebnisse in Kosten- und Größenänderungen
Was eine Aufgabe verbraucht hat, steht im Run-Manifest-Protokoll, dessen Stream `manifest/run/{{run_id}}/{{run_uuid}}`. HealthOmics schreibt es, nachdem der Lauf beendet ist, also setze {{duration}} um die Stoppzeit des Laufs und nicht die einer Aufgabe zu erreichen. Lies es mit dem gleichen **aws logs tail** Befehl wie bei den anderen Streams. Die Statistiken, die es meldet, finden Sie unter [Protokolltypen für HealthOmics Workflows](monitoring-cloudwatch-logs.md#log-descriptions).
Ein Manifest-Aufgabeneintrag gibt an, was die Aufgabe reserviert hat, welchen Instanztyp sie hat und wie lange sie dauert. Er gibt an, was die Aufgabe zusammen mit diesen verwendet hat, aber nicht für jede Aufgabe. Wenn ein Eintrag keine Nutzung oder weniger meldet, als die Arbeit der Aufgabe ausmachen kann, wird stattdessen die Größe mit den Ausführungsmetriken der Aufgabe verglichen, und zwar aus dem unter [Callouts](monitoring-run-metrics.md#monitoring-run-metrics-callouts).
Drei HealthOmics Verhaltensweisen schränken ein, was durch eine Änderung gespeichert wird:
+ Die Kosten einer Aufgabe richten sich nach dem Instanztyp HealthOmics wählt für die von Ihnen angeforderten Ressourcen aus, nicht für die Ressourcen, die die Aufgabe verwendet. Siehe [Rechen- und Speicheranforderungen für HealthOmics Aufgaben](memory-and-compute-tasks.md).
+ Aufgabengebühren haben eine abrechnungsfähige Mindestdauer, sodass es nichts bringt, eine bereits kurze Aufgabe zu verkürzen. Siehe [Auswirkungen des Ausführungsstatus auf die Preisgestaltung](monitoring-runs.md#run-status-billing).
+ Static Run Storage ist in festen Größen erhältlich, sodass sich die Kosten bei einer Reduzierung nur ändern, wenn die Kapazität auf eine kleinere unterstützte Größe fällt. Siehe [Statisch ausgeführter Speicher](workflows-run-types.md#workflows-run-type-static).
Die Optimierungsmethoden, in die diese Ergebnisse einfließen, finden Sie unter [Methoden zur Optimierung von Läufen](workflows-run-optimize.md#run-optimize-methods).