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.
Fehlerbehebung
Die folgenden Themen können Ihnen bei der Behebung von Problemen helfen, die bei der Verwendung von HealthOmics Workflows und Datenspeichern auftreten.
Themen
Problembehandlung bei Workflows
Themen
Wie behebe ich Fehler bei einem fehlgeschlagenen Lauf?
Verwenden Sie die GetRun API-Operation, um den Grund für den Fehler abzurufen. Weitere Informationen finden Sie unter Gründe für den Ausfall der Ausführung.
Wie behebe ich eine fehlgeschlagene Aufgabe?
Überprüfen Sie den Fehlercode in der Meldung über den Ausfall der Aufgabe, um den Fehler zu verstehen. Überprüfen Sie die Aufgabenanmeldungen CloudWatch , um detaillierte Protokollierungsmeldungen für die Aufgabe zu erhalten. Wenn Sie keine detaillierten Protokollmeldungen erhalten, können Sie Ihren Workflow so ändern, dass er zusätzliche Protokollanweisungen ausgibt. Weitere Informationen finden Sie unter Überwachung HealthOmics mit CloudWatch Protokollen.
Wo finde ich die Engine-Logs?
HealthOmics veröffentlicht Engine-Logs nahezu CloudWatch in Echtzeit für alle Läufe (erfolgreich und fehlgeschlagen). Engine-Logs werden nach Abschluss des Laufs auch an Ihren Amazon S3-Bucket übermittelt. Weitere Informationen erhalten Sie unter Überwachung HealthOmics mit CloudWatch Protokollen und Loggt sich in Amazon S3 ein.
Wie kann ich die Größe der Eingabeparameter für einen Workflow reduzieren?
Sie können bis zu 256 KB an Eingabeparametern für einen Workflow angeben. Sie können Verzeichnisimporte oder Musterblätter verwenden, um diese Größenbeschränkung einzuhalten. Weitere Informationen finden Sie unter Verwaltung der Größe von Ausführungsparametern.
Warum wird mein Lauf nicht abgeschlossen?
Wenn es Probleme mit Ihrem Code gibt und die Prozesse nicht ordnungsgemäß beendet wurden, reagiert Ihr Lauf möglicherweise nicht mehr oder „hängt“. Weitere Informationen darüber, wie Sie nicht reagierende Läufe verhindern und abfangen können, finden Sie unter. Anleitung für nicht reagierende Läufe
Problembehandlung bei Laufmesswerten
Themen
Warum ist mein Lauf fehlgeschlagen, weil der Speicherplatz knapp wurde?
Wie dimensioniere ich die Rechenleistung und den Speicher für meinen Workflow richtig?
Wie unterscheidet sich das von den Ressourcenstatistiken für das Run-Manifestprotokoll?
Wie unterscheiden sich die Ausführungsmetriken in Query Studio vom Nextflow-Ausführungsbericht?
Warum läuft meine Aufgabe langsamer als erwartet?
Eine Aufgabe kann langsam ausgeführt werden, wenn sie an die Central Processing Unit (CPU) oder an die Graphics Processing Unit (GPU) gebunden ist oder auf input/output (I/O) wartet. Verwenden Sie die CloudWatch Messwerte für die Ausführung nahezu in Echtzeit, um die Ressourcenauslastung zu überprüfen, während die Aufgabe noch ausgeführt wird:
-
Vergleiche
aws.omics.task.cpu.usagemitaws.omics.task.cpu.limit. Eine anhaltende Auslastung des Grenzwerts weist darauf hin, dass der Task mehr CPU zugewiesen ist CPU-bound und möglicherweise davon profitieren könnte. -
Informationen zu GPU-Workloads finden Sie unter.
aws.omics.task.gpu.utilizationEine niedrige Auslastung kann darauf hinweisen, dass die Aufgabe die GPU nicht effektiv nutzt. -
Suchen Sie
aws.omics.task.filesystem.operationsnachaws.omics.task.filesystem.iound nach I/O Engpässen.
Weitere Informationen finden Sie unter Metriken für private Workflows ausführen.
Warum ist mein Lauf fehlgeschlagen, weil der Speicherplatz knapp wurde?
Ein Lauf kann fehlschlagen, wenn der Speicherplatz auf dem gemeinsam genutzten Dateisystem erschöpft ist. Vergleichen Sie das Verzeichnisaws.omics.run.filesystem.usage, das den verwendeten Speicher auf dem gemeinsam genutzten Dateisystem des Laufs angibt, mit demaws.omics.run.filesystem.limit, welches die Gesamtkapazität angibt. Sie können Dashboards oder Alarme erstellen, um die Speichernutzung zu überwachen. Weitere Informationen finden Sie unter Metriken für private Workflows ausführen.
Wie dimensioniere ich die Rechenleistung und den Speicher für meinen Workflow richtig?
Führen Sie Ihren Workflow einmal aus und überprüfen Sie die CloudWatch Kennzahlen, um die tatsächliche Auslastung mit den zugewiesenen Grenzwerten zu vergleichen:
-
Wenn die CPU-, GPU- oder Speicherauslastung deutlich unter dem Grenzwert bleibt, können Sie die Zuweisung reduzieren, um die Kosten zu senken.
-
Wenn die Auslastung konstant am Limit liegt, erhöhen Sie die Zuweisung, um die Leistung zu verbessern oder Ausfälle zu vermeiden.
-
Wird verwendet
aws.omics.run.filesystem.usage, um eine geeignete Dateisystemgröße für den Lauf festzulegen.
Weitere Informationen finden Sie unter Metriken für private Workflows ausführen.
Warum sehe ich keine Metriken für meinen Lauf?
Wenn die Lauf- und Aufgabenmetriken nicht im cloudwatch.aws/omics Bereich in angezeigt werden CloudWatch, überprüfe Folgendes:
-
Vergewissern Sie sich, dass die für den Lauf verwendete IAM-Rolle die Berechtigung hat, Metriken zu CloudWatch veröffentlichen.
-
Metriken werden während der Ausführung des Laufs nahezu in Echtzeit veröffentlicht. Warten Sie mit einer kurzen Verzögerung (etwa 30 Sekunden), bis die ersten Datenpunkte angezeigt werden.
-
Für Aufgaben, die weniger als 30 Sekunden ausgeführt werden, gibt es möglicherweise keine Metriken.
-
Vergewissern Sie sich, dass Sie die richtige AWS Region und das richtige Konto anzeigen.
Weitere Informationen finden Sie unter Metriken für private Workflows ausführen.
Wie unterscheidet sich das von den Ressourcenstatistiken für das Run-Manifestprotokoll?
In den Ausführungsmanifestprotokollen werden aggregierte Statistiken für einen abgeschlossenen Lauf gemeldet, z. B. die maximale und durchschnittliche CPU- und Speichermenge, sodass Sie einen abgeschlossenen Lauf auf Optimierungsmöglichkeiten überprüfen können. CloudWatch Bei den Ausführungsmetriken handelt es sich um eine Zeitreihe: Sie HealthOmics veröffentlichen Datenpunkte mit der unter angegebenen HäufigkeitVerfügbare Metriken, sodass Sie die Änderungen der Auslastung während der Ausführung überwachen und detailliertere Daten zur Fehlerbehebung bei Ihren Läufen verwenden können. Weitere Informationen zu Laufmetriken finden Sie unter. Metriken für private Workflows ausführen
Wie unterscheiden sich die Ausführungsmetriken in Query Studio vom Nextflow-Ausführungsbericht?
Beide berichten über die Ressourcenauslastung für Ihren Workflow. Sie unterscheiden sich in Bezug auf den Zeitpunkt, die Motorabdeckung und die Art und Weise, wie Sie sie verwenden. Verwenden Sie Laufmetriken, um einen laufenden Lauf zu überwachen, und verwenden Sie den Nextflow-Ausführungsbericht, um einen abgeschlossenen Lauf zu überprüfen.
-
Laufmetriken sind nahezu in Echtzeit verfügbar, während der Lauf ausgeführt wird, sodass du den Fortschritt überwachen, Alarme einrichten und Fehler bei einem laufenden Lauf beheben kannst. Der Nextflow-Ausführungsbericht wird erstellt, wenn der Lauf abgeschlossen ist. Sie können ihn also nur verwenden, um einen Lauf im Nachhinein zu überprüfen.
-
HealthOmics gibt Laufmetriken für jeden privaten Workflow-Lauf aus, unabhängig davon, welche Workflow-Engine der Lauf verwendet. Der Ausführungsbericht ist spezifisch für Nextflow und HealthOmics exportiert ihn nur, wenn Sie ihn so konfigurieren, dass er unter geschrieben wird.
/mnt/workflow/output/ -
Run-Metriken sind CloudWatch Zeitreihen, sodass Sie sie mit PromQL abfragen, Alarme auslösen und sie einem Dashboard hinzufügen können. Der Ausführungsbericht ist eine statische Datei im Amazon S3-Ausgabespeicherort Ihres Laufs.
Weitere Informationen zum Ausführungsbericht finden Sie unterGenerieren Sie Nextflow-Ausführungsberichte. Weitere Hinweise zu Run-Metriken finden Sie unterMetriken für private Workflows ausführen.
Behebung von Problemen beim Zwischenspeichern von Anrufen
Die folgenden Themen können Ihnen bei der Behebung von Problemen helfen, die beim Zwischenspeichern von Anrufen auftreten.
Themen
Warum wird mein Lauf nicht im Cache gespeichert?
-
Stellen Sie sicher, dass der Lauf für die Verwendung eines Caches konfiguriert ist, indem Sie das CacheID-Feld in der Antwort auf den GetRun API-Vorgang überprüfen. Führen Sie mithilfe der CLI diesen Befehl aus:
aws omics get-run —id <run_id>. -
Wenn der Lauf erfolgreich war, überprüfen Sie, ob das in der GetRun Antwort zurückgegebene Cache-Verhalten CACHE_ALWAYS ist. Wenn das Cacheverhalten auf CACHE_ON_FAILURE gesetzt ist, werden Läufe nur dann im Cache gespeichert, wenn sie fehlschlagen.
Warum verwendet eine Aufgabe den Cache-Eintrag nicht?
<cache_id><cache_uuid>Öffnen Sie in der /aws/omics/WorkflowLog CloudWatch Protokollgruppe den Log-Stream für den Run-Cache: runCache//.
-
Stellen Sie sicher, dass bei einer vorherigen Ausführung ein Cacheeintrag für die Aufgabe erstellt wurde, von der Sie erwartet hatten, dass sie zwischengespeichert wird. Läufe, die im Cache gespeichert wurden, werden mit der Logmeldung CACHE_ENTRY_CREATED aufgezeichnet.
-
Suchen Sie das CACHE_MISS-Protokoll für die Aufgabe und führen Sie die abgeschlossene Aufgabe aus. Wenn kein Protokolleintrag vorhanden ist, überprüfen Sie, ob der Lauf für die Verwendung des Caches konfiguriert wurde.
-
Wenn ein Cache-Eintrag erstellt wurde, stellen Sie sicher, dass die CPUs, der Arbeitsspeicher, die GPUs und der Container-Digest für beide Aufgaben identisch sind. Die Aufgaben-ARN für die Aufgabe, die den Cache-Eintrag erstellt hat, ist in der Protokollnachricht enthalten.
-
Wenn die Rechenanforderungen für beide Aufgaben übereinstimmen, stellen Sie sicher, dass sich die Eingaben zwischen den Aufgaben nicht geändert haben. Öffnen Sie dazu die Engine-Logs. Die Motorprotokolle sind in der CloudWatch Protokollgruppe/aws/omics/WorkflowLog für alle Läufe verfügbar. Sie sind nach Abschluss des Laufs auch im Ausgabeverzeichnis verfügbar.
Warum ist das Caching von Aufrufen für eine Aufgabe deaktiviert?
Prüfen Sie, ob die Aufgabe so konfiguriert ist, dass das Caching mithilfe der Workflow-Engine-Funktionen deaktiviert wird:
Für WDL-Workflows: Prüfen Sie, ob für die Aufgabe im Meta-Bereich die Option Volatile
trueauf gesetzt istFür Nextflow-Workflows: Prüfen Sie, ob für die Aufgabe die Cache-Direktive auf gesetzt ist
falseFür CWL-Workflows: Prüfen Sie, ob für die Aufgabe für die Funktion EnableReuse auf gesetzt ist
falseWorkReuse
Problembehandlung bei Datenspeichern
Themen
Warum schlägt S3 bei meinem Lesesatz GetObject fehl?
In den meisten Fällen ist der Fehler auf eine fehlende Berechtigung zurückzuführen. Die Leseberechtigung für Sequenzspeicher S3 ist eine bidirektionale Konfiguration, bei der sowohl die S3-Zugriffsrichtlinie für den Sequenzspeicher den Zugriff ermöglicht, als auch dem IAM-Prinzipal eine Richtlinie zugeordnet sein muss, die den Zugriff ermöglicht. Weitere Informationen zu den Richtlinienanforderungen finden Sie unter. Berechtigungen für den Datenzugriff mit Amazon S3 URIs Vergewissern Sie sich, dass die folgenden Konfigurationen vorhanden sind:
-
Die S3-Zugriffsrichtlinie für den Sequenzspeicher hat den Zugriff auf den IAM-Prinzipal oder das Stammverzeichnis des Prinzipalkontos explizit zugelassen.
-
Stellen Sie sicher, dass der IAM-Prinzipal über eine Richtlinie verfügt, die ausdrücklich die Berechtigung für den Zugriff auf die Ressource erteilt. Beachten Sie, dass die IAM-Prinzipalrichtlinie bei der Definition von Berechtigungen den Access Point-ARN und nicht den auf dem Access Point-Alias basierenden Pfad verwenden muss und dass der ARN in dem Zustand ist und nicht zur Angabe einer Ressource verwendet wird.
-
Wenn Ihr Shop einen vom Kunden verwalteten Schlüssel (CMK-KMS) verwendet, stellen Sie sicher, dass der IAM-Prinzipal über kms:decrypt-Berechtigungen für den Schlüssel verfügt. Informationen zur Konfiguration der kontoübergreifenden Nutzung finden Sie im Leitfaden für den kontoübergreifenden KMS-Zugriff.
Wenn Sie eine Richtlinie haben, die tagbasierte Zugriffskontrollen verwendet, stellen Sie Folgendes sicher:
-
Stellen Sie sicher, dass der Sequenzspeicher die Synchronisierung der Tags abgeschlossen hat. Dazu muss der Status des Speichers lauten active und nichtupdating.
-
Stellen Sie sicher, dass der Tag-Schlüssel oder der Schlüsselwert des Lesesatzes und der Richtlinie keine Tippfehler enthalten.
Warum kann ich meinen Annotations- oder Variantenspeicher in Athena nicht sehen?
Stelle sicher, dass du in Lake Formation einen Ressourcen-Link erstellst, der auf dem Store basiert, der mit dir geteilt wurde. Sobald Sie einen Ressourcenlink erstellt haben, für den Sie eine Zugriffsberechtigung haben, sollte der Shop in Athena sichtbar sein. Weitere Informationen finden Sie unter Konfiguration von Lake Formation zur Verwendung HealthOmics.
Warum kann ich nicht auf meinen Datenspeicher in Athena zugreifen?
Wenn Ihr Annotations- oder Variantenspeicher sichtbar ist, Sie aber eine Fehlermeldung erhalten, die besagt, dass der Zugriff verweigert wurde, überprüfen Sie, welche Version der Abfrage-Engine Sie verwenden. Nur Abfragen, die mit der Engine-Version 3 ausgeführt werden, werden unterstützt. Weitere Informationen zu den Versionen der Athena-Abfrage-Engine finden Sie in der Amazon Athena-Dokumentation.
Fehlerbehebung mit Kiro CLI
Kiro CLI kann dir helfen, deinen Fehlerbehebungsprozess zu optimieren, indem du:
-
Analysieren von Workflow-Ausführungen und Debuggen von Aufgabenfehlern
-
Erfassung relevanter Protokolle und Fehlermeldungen
-
Erstellung von AWS Support-Fällen mit allen erforderlichen Debugging-Protokollen im Anhang
-
Redigiert personenbezogene Daten (PII) aus Informationen, die an den Support übermittelt wurden AWS
Weitere Informationen zur Verwendung von Kiro CLI mit AWS HealthOmics zur Fehlerbehebung und Erstellung von Support-Fällen finden Sie im Agentic-Tutorial zur HealthOmics generativen KI unter.
Warnung
Wenn Sie mit Kiro CLI arbeiten, überprüfen Sie alle generierten Inhalte und vorgeschlagenen Maßnahmen, bevor Sie fortfahren. Geben Sie Feedback, um die Antwortqualität zu verbessern und die Anforderungen Ihres Workflows zu erfüllen. Weitere Informationen findest du unter Sicherheitsüberlegungen und bewährte Methoden für Kiro.