Fehlerbehebung bei AWS Glue-für-Ray-Fehlern anhand von Protokollen - AWS Glue
Überprüfung von Ray-AuftragsprotokollenFehlerbehebung bei Ray-Auftragsfehlern

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 bei AWS Glue-für-Ray-Fehlern anhand von Protokollen

AWS Glue bietet Zugriff auf Protokolle, die von Ray-Prozessen während der Auftragsausführung ausgegeben werden. Wenn Sie bei Ray-Aufträgen auf Fehler oder unerwartetes Verhalten stoßen, sammeln Sie zunächst Informationen aus den Protokollen, um die Fehlerursache zu ermitteln. Wir stellen auch ähnliche Protokolle für interaktive Sitzungen bereit. Sitzungsprotokolle werden mit dem /aws-glue/ray/sessions-Präfix bereitgestellt.

Protokollzeilen werden während der Ausführung Ihres Auftrags in Echtzeit an CloudWatch gesendet. Druckanweisungen werden nach Abschluss der Ausführung an die CloudWatch-Protokolle angefügt. Protokolle werden nach der Ausführung eines Auftrags zwei Wochen lang aufbewahrt.

Überprüfung von Ray-Auftragsprotokollen

Wenn ein Auftrag fehlschlägt, erfassen Sie den Auftragsnamen und die ID der Auftragsausführung. Diese finden Sie in der AWS Glue-Konsole. Navigieren Sie zur Seite des Auftrags und dann zur Registerkarte Runs (Ausführungen). Ray-Auftragsprotokolle werden in den folgenden speziellen CloudWatch-Protokollgruppen gespeichert.

  • /aws-glue/ray/jobs/script-log/ – Speichert Protokolle, die von Ihrem Haupt-Ray-Skript ausgegeben werden.

  • /aws-glue/ray/jobs/ray-monitor-log/ – Speichert Protokolle, die vom Ray-Autoscaler-Prozess ausgegeben werden. Diese Protokolle werden für den Hauptknoten und nicht für andere Worker-Knoten generiert.

  • /aws-glue/ray/jobs/ray-gcs-logs/ – Speichert Protokolle, die vom GCS-Prozess (Global Control Store) ausgegeben werden. Diese Protokolle werden für den Hauptknoten und nicht für andere Worker-Knoten generiert.

  • /aws-glue/ray/jobs/ray-process-logs/ – Speichert Protokolle, die von anderen Ray-Prozessen (hauptsächlich dem Dashboard-Agenten) ausgegeben werden, die auf dem Hauptknoten ausgeführt werden. Diese Protokolle werden für den Hauptknoten und nicht für andere Worker-Knoten generiert.

  • /aws-glue/ray/jobs/ray-raylet-logs/ – Speichert Protokolle, die von jedem Raylet-Prozess ausgegeben werden. Diese Protokolle werden in einem einzigen Stream für jeden Worker-Knoten erfasst, einschließlich des Hauptknotens.

  • /aws-glue/ray/jobs/ray-worker-out-logs/ – Speichert stdout-Protokolle für jeden Worker im Cluster. Diese Protokolle werden für jeden Worker-Knoten generiert, einschließlich des Hauptknotens.

  • /aws-glue/ray/jobs/ray-worker-err-logs/ – Speichert stderr-Protokolle für jeden Worker im Cluster. Diese Protokolle werden für jeden Worker-Knoten generiert, einschließlich des Hauptknotens.

  • /aws-glue/ray/jobs/ray-runtime-env-log/ – Speichert Protokolle über den Ray-Einrichtungsprozess. Diese Protokolle werden für jeden Worker-Knoten generiert, einschließlich des Hauptknotens.

Fehlerbehebung bei Ray-Auftragsfehlern

Um die Organisation von Ray-Protokollgruppen zu verstehen und die Protokollgruppen zu finden, die Ihnen bei der Fehlerbehebung helfen, ist es hilfreich, Hintergrundinformationen zur Ray-Architektur zu haben.

In AWS Glue-ETL entspricht ein Worker einer Instance. Wenn Sie Worker für einen AWS Glue-Auftrag konfigurieren, legen Sie die Art und Anzahl der Instances fest, die dem Auftrag zugeordnet sind. Ray verwendet den Begriff Worker auf unterschiedliche Weise.

Ray verwendet Head-Knoten und Worker-Knoten, um die Verantwortlichkeiten einer Instance innerhalb eines Ray-Clusters zu unterscheiden. Ein Ray-Worker-Knoten kann mehrere Akteurs-Prozesse hosten, die Berechnungen durchführen, um das Ergebnis Ihrer verteilten Berechnung zu erzielen. Akteure, die eine Replik einer Funktion ausführen, werden als Repliken bezeichnet. Replikatakteure können auch als Worker-Prozesse bezeichnet werden. Replikate können auch auf dem Hauptknoten ausgeführt werden, der als Head bezeichnet wird, da er zusätzliche Prozesse zur Koordinierung des Clusters ausführt.

Jeder Akteur, der zu Ihrer Berechnung beiträgt, generiert einen eigenen Protokollstream. Das gibt uns einige Einblicke:

  • Die Anzahl der Prozesse, die Protokolle ausgeben, kann größer sein als die Anzahl der Worker, die dem Auftrag zugewiesen sind. Oft hat jeder Kern auf jeder Instance einen Akteur.

  • Ray-Head-Knoten geben Cluster-Management- und Startprotokolle aus. Im Gegensatz dazu geben Ray-Worker-Knoten nur Protokolle für die an ihnen ausgeführten Arbeiten aus.

Weitere Informationen zur Ray-Architektur finden Sie in den Architektur-Whitepapers in der Ray-Dokumentation.

Problembereich: Zugriff auf Amazon S3

Prüfen Sie die Fehlermeldung der Auftragsausführung. Wenn dies nicht genug Informationen enthält, lesen Sie /aws-glue/ray/jobs/script-log/.

Problembereich: PIP-Abhängigkeitsmanagement

Überprüfen Sie /aws-glue/ray/jobs/ray-runtime-env-log/.

Problembereich: Überprüfung von Zwischenwerten im Hauptprozess

Schreiben Sie von Ihrem Hauptskript nach stderr oder stdout und rufen Sie Protokolle von /aws-glue/ray/jobs/script-log/ ab.

Problembereich: Überprüfung von Zwischenwerten in einem untergeordneten Prozess

Schreiben Sie nach stderr oder stdout von Ihrer remote-Funktion. Rufen Sie anschließend Protokolle von /aws-glue/ray/jobs/ray-worker-out-logs/ oder /aws-glue/ray/jobs/ray-worker-err-logs/ ab. Ihre Funktion wurde möglicherweise auf einem beliebigen Replikat ausgeführt, sodass Sie möglicherweise mehrere Protokolle untersuchen müssen, um die beabsichtigte Ausgabe zu finden.

Problembereich: Interpretation von IP-Adressen in Fehlermeldungen

In bestimmten Fehlersituationen kann Ihr Auftrag möglicherweise eine Fehlermeldung ausgeben, die eine IP-Adresse enthält. Diese IP-Adressen sind flüchtig und werden vom Cluster zur Identifizierung und Kommunikation zwischen den Knoten verwendet. Protokolle für einen Knoten werden in einem Protokollstream mit einem eindeutigen Suffix basierend auf der IP-Adresse veröffentlicht.

In CloudWatch können Sie Ihre Protokolle filtern, um diejenigen zu überprüfen, die für diese IP-Adresse spezifisch sind, indem Sie dieses Suffix identifizieren. Wenn Sie beispielsweise FAILED_IP und JOB_RUN_ID angeben, können Sie das Suffix wie folgt identifizieren: 

filter @logStream like /JOB_RUN_ID/
| filter @message like /IP-/
| parse @message "IP-[*]" as ip
| filter ip like /FAILED_IP/
| fields replace(ip, ":", "_") as uIP
| stats count_distinct by uIP as logStreamSuffix
| display logStreamSuffix