View a markdown version of this page

Fehlerbehebung - AWS HealthOmics

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.

Problembehandlung bei Workflows

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 Fehler beim Ausführen.

Wie behebe ich eine fehlgeschlagene Aufgabe?

Überprüfen Sie den Fehlercode in der Meldung zum 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 50 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 Größe der Ausführungsparameter verwalten.

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. Hinweise für nicht reagierende Läufe

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.

Warum wird mein Lauf nicht im Cache gespeichert?

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

  2. 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//.

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

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

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

  4. 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-Protokolle. 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 mithilfe der Workflow-Engine-Funktionen, ob die Aufgabe so konfiguriert ist, dass das Caching deaktiviert wird:

  • Für WDL-Workflows: Prüfen Sie, ob für die Aufgabe im Meta-Bereich die Option Volatile true auf gesetzt ist

  • Für Nextflow-Workflows: Prüfen Sie, ob für die Aufgabe die Cache-Direktive auf gesetzt ist false

  • Für CWL-Workflows: Prüfen Sie, ob für die Aufgabe für die Funktion EnableReuse auf gesetzt ist false WorkReuse

Problembehandlung bei Datenspeichern

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 für die 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. GitHub

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.