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 einen fehlgeschlagenen Lauf?
Verwenden Sie den GetRunAPI-Vorgang, 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?
Sehen Sie sich den Fehlercode in der Fehlermeldung für die Aufgabe an, um den Fehler zu verstehen. Sehen Sie sich die Task-Logs an CloudWatch , um detaillierte Log-Meldungen für die Aufgabe zu sehen. Wenn Sie keine detaillierten Protokollmeldungen erhalten, können Sie Ihren Workflow überarbeiten, um zusätzliche Protokollanweisungen auszugeben. Weitere Informationen finden Sie unter Überwachung HealthOmics mit CloudWatch Protokollen.
Wo finde ich die Engine-Protokolle für erfolgreich abgeschlossene Läufe?
HealthOmics veröffentlicht nur Protokolle CloudWatch für fehlgeschlagene Läufe. Wenn ein Lauf erfolgreich abgeschlossen wurde, werden die HealthOmics Engine-Protokolle an Ihren Amazon S3 S3-Bucket gesendet. Weitere Informationen finden Sie unter 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 ist 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 „blockiert“. Weitere Informationen darüber, wie Sie nicht reagierende Läufe verhindern und catch können, finden Sie unterHinweise 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.
Themen
Warum wird mein Lauf nicht im Cache gespeichert?
-
Vergewissern Sie sich, dass der Lauf für die Verwendung eines Caches konfiguriert ist, indem Sie das Feld CacheID in der Antwort auf den GetRun API-Vorgang überprüfen. Führen Sie mit der CLI diesen Befehl aus:
aws omics get-run —id <run_id>. -
Wenn die Ausführung erfolgreich war, überprüfen Sie, ob das in der GetRun Antwort zurückgegebene Cache-Verhalten CACHE_ALWAYS lautet. Wenn das Cache-Verhalten 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 Protokollstream für den Run-Cache: RunCache//.
-
Vergewissern Sie sich, dass bei einem vorherigen Lauf ein Cache-Eintrag für die Aufgabe erstellt wurde, von der Sie erwartet haben, dass sie zwischengespeichert wird. Läufe, die im Cache gespeichert wurden, werden mit der Protokollmeldung CACHE_ENTRY_CREATED aufgezeichnet.
-
Suchen Sie das CACHE_MISS-Protokoll für die Aufgabe und führen Sie es aus, wenn es abgeschlossen ist. 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 CPUs, dass der Speicher GPUs - und der Container-Digest für beide Aufgaben identisch sind. Der Task-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. Wenn der Lauf den Status FAILED hat, befinden sich die Protokolle in der Cloudwatch Log Group/aws/omics/WorkflowLog. Andernfalls befinden sich die Engine-Logs im Ausgabeverzeichnis des Laufs.
Problembehandlung bei Datenspeichern
Themen
Warum schlägt S3 auf meinem Lesesatz GetObject fehl?
In den meisten Fällen ist der Fehler auf eine fehlende Erlaubnis zurückzuführen. Die Leseberechtigung für den Sequenzspeicher S3 ist eine bidirektionale Konfiguration, bei der sowohl die S3-Zugriffsrichtlinie für den Sequenzspeicher als auch der IAM-Prinzipal über eine Richtlinie verfügen 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 ausdrücklich zugelassen.
-
Vergewissern Sie sich, dass der IAM-Prinzipal über eine Richtlinie verfügt, die ausdrücklich die Erlaubnis für die Ressource, auf die zugegriffen wird, vorsieht. 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 diesem 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: Entschlüsselungsberechtigungen für den Schlüssel verfügt. Informationen zur Konfiguration der kontoübergreifenden Nutzung finden Sie im Leitfaden für kontoübergreifenden Zugriff auf KMS.
Wenn Sie über eine Richtlinie verfügen, 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 im Lesesatz und in der Richtlinie keine Tippfehler enthalten.
Warum kann ich meinen Annotationsspeicher oder Variantenspeicher in Athena nicht sehen?
Stellen Sie in Lake Formation sicher, dass Sie einen Ressourcenlink erstellen, der auf dem Shop basiert, der mit Ihnen geteilt wurde. Sobald Sie einen Ressourcenlink erstellt haben, auf den Sie zugreifen dürfen, sollte der Shop in Athena sichtbar sein. Weitere Informationen finden Sie unter Konfiguration von Lake Formation für die Verwendung HealthOmics.
Warum kann ich in Athena nicht auf meinen Datenspeicher zugreifen?
Wenn Ihr Annotations- oder Variantenspeicher sichtbar ist, Sie aber eine Fehlermeldung erhalten, dass der Zugriff verweigert wurde, überprüfen Sie, welche Version der Abfrageengine Sie verwenden. Es werden nur Abfragen unterstützt, die mit Engine-Version 3 ausgeführt werden. Weitere Informationen zu den Versionen der Athena-Abfrage-Engine finden Sie in der Amazon Athena Athena-Dokumentation.
