Einführung
Gestern war der Batch des Einzelhändlers erfolgreich, doch heute meldet der Befehl einen Fehler. Ihn zu wiederholen, ohne die Meldung zu lesen, kann die eigentliche Ursache verdecken oder zu einer zerstörerischen Abkürzung verleiten. Eine fehlende Eingabe, eine falsche Dienstadresse und ein fehlgeschlagener Verarbeitungstask erfordern unterschiedliche Reaktionen.
Sie folgen einer kleinen Diagnosereihenfolge: Dateisystem und Verbindung ermitteln, Vorhandensein und Lesbarkeit der Eingabe prüfen, den Ausgabepfad prüfen und dann Status und Protokolle einer angenommenen Anwendung untersuchen. Ein clientseitiger Fehler kann auftreten, bevor eine Anwendung übermittelt wird. Eine übermittelte Anwendung hat eine YARN-Kennung, deren Diagnose weitere Belege liefert.
Dieses Lab stellt absichtlich mehrere Fehler bereit, darunter eine vorkompilierte Übungsanwendung, die einen markierten Eingabedatensatz ablehnt. Das sind kontrollierte Lernbeispiele, keine zufälligen Infrastrukturfehler. Sie bewahren sie als Belege auf und schließen einen sauberen WordCount-Lauf mit einem anderen Eingabe- und Ausgabepfad ab. Java-Programmierung, Neuinstallation von Diensten, Formatierung oder großflächiges Löschen sind nicht erforderlich. Alle Beispieldaten sind unabhängig; verwenden Sie das Terminal.
Diagnostizieren Sie Verbindungs- und Eingabefehler
In diesem Schritt unterscheiden Sie anhand echter Clientfehlermeldungen eine falsche Dienstadresse von einer fehlenden Datei.
Beginnen Sie im lokalen Arbeitsverzeichnis:
cd /home/labex/project
Rufen Sie sich zuerst das konfigurierte Dateisystem in Erinnerung:
hdfs getconf -confKey fs.defaultFS
Es sollte hdfs://localhost:9000 sein. Fordern Sie den Client nun absichtlich auf, sich mit Port 1 zu verbinden, an dem kein NameNode lauscht. Die folgenden Eigenschaften mit -D begrenzen die Verbindungswiederholungen und setzen für diesen Aufruf ein Verbindungstimeout von 2.000 Millisekunden. So bleibt der absichtliche Fehler zeitlich begrenzt. Die gemeinsame Konfiguration wird nicht bearbeitet.
Die Umleitung > file 2>&1 speichert die normale Ausgabe in einer lokalen Datei und leitet die Fehlerausgabe an dasselbe Ziel. Der nächste Befehl soll fehlschlagen.
hdfs dfs -Dipc.client.connect.max.retries=0 -Dipc.client.connect.timeout=2000 -ls hdfs://localhost:1/user/labex > /home/labex/project/output/connection-error.log 2>&1
Lesen Sie den gespeicherten Fehler:
cat /home/labex/project/output/connection-error.log
Achten Sie auf einen Verbindungsfehler oder eine Verbindungsverweigerung und die falsche Adresse. Dies geschieht, bevor eine Dateisystemauflistung erfolgreich sein kann. Formatieren Sie HDFS nicht und installieren Sie keine Dienste neu; der Befehl hat den falschen Endpunkt verwendet. Kehren Sie über den Standardpfad zum konfigurierten Endpunkt zurück:
hdfs dfs -ls /user/labex/job-diagnostics/data
Sie sollten clean.txt und rejected.txt sehen. Die Verbindung funktioniert. Ein anderes Problem ist die Anfrage nach einer nicht vorhandenen Datei in diesem gesunden Dateisystem. Der nächste Befehl soll fehlschlagen.
hdfs dfs -ls /user/labex/job-diagnostics/data/missing.txt > /home/labex/project/output/missing-input.log 2>&1
Prüfen Sie die Meldung:
cat /home/labex/project/output/missing-input.log
Sie sollte melden, dass der benannte Pfad nicht existiert. Prüfen Sie die vorgesehene Eingabe mit der bekannten Leseoperation:
hdfs dfs -cat /user/labex/job-diagnostics/data/clean.txt
Die beiden Zeilen lauten notebook pen und notebook folder. Ein korrigierter Eingabepfad löst ein Problem mit einer fehlenden Datei; eine Änderung der Serverkonfiguration würde es nicht lösen. Bewahren Sie die Fehlerprotokolle als Belege auf.
Erkennen Sie einen bereits vorhandenen Ausgabepfad
In diesem Schritt beobachten Sie, warum ein Job ein bereits vorhandenes Ausgabeverzeichnis ablehnt, und entscheiden sich für das Bewahren statt für großflächiges Löschen.
Die Vorbereitung hat ein leeres Ergebnisverzeichnis existing angelegt, das einen bereits reservierten Ausgabeort darstellt. Prüfen Sie diesen Verzeichniseintrag:
hdfs dfs -ls -d /user/labex/job-diagnostics/results/existing
Das Ausgabeformat des MapReduce-Beispiels erwartet, ein neues Ausgabeverzeichnis zu erstellen. Ein vorhandenes Verzeichnis kann eine clientseitige Ablehnung auslösen, bevor eine Verarbeitungsanwendung angenommen wird. Der nächste Befehl soll fehlschlagen.
hadoop jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.5.0.jar wordcount /user/labex/job-diagnostics/data/clean.txt /user/labex/job-diagnostics/results/existing > /home/labex/project/output/existing-output.log 2>&1
Lesen Sie die gespeicherte Meldung:
cat /home/labex/project/output/existing-output.log
Suchen Sie eine Meldung über ein bereits vorhandenes Ausgabeverzeichnis oder FileAlreadyExistsException. Dies ist ein Pfadkonflikt, kein Beleg für einen Fehler im Produktzählalgorithmus.
Listen Sie die von YARN angenommenen Anwendungen auf:
yarn application -list -appStates ALL
Diese Clientfehler sollten keine abgeschlossene Verarbeitungsanwendung erzeugen. Ein Client kann während der Vorbereitung der Übermittlung Clusterdienste kontaktieren oder eine Kennung erhalten; eine angenommene Anwendung und ihr Status sind eigenständige Belege.
Sie bewahren das reservierte Verzeichnis auf und verwenden für den erfolgreichen Lauf einen neuen Ausgabepfad. Ganz results zu entfernen oder Rohdateneingaben zu löschen wäre eine wesentlich weitergehende Änderung, als das Problem erfordert.
Untersuchen Sie eine tatsächlich fehlgeschlagene Anwendung
In diesem Schritt übermitteln Sie eine kontrollierte Übungsanwendung und erklären den Fehler anhand ihrer echten YARN-Kennung und Protokolle.
Das vorbereitete controlled-failure.jar erwartet einen Eingabepfad und einen neuen Ausgabepfad. Sein Mapper lehnt den Marker BAD_RECORD absichtlich ab. Sie müssen keinen Java-Code untersuchen oder bearbeiten; hier geht es darum, einen Taskfehler einer angenommenen Anwendung von den vorherigen Clientfehlern zu unterscheiden.
Lesen Sie zuerst die markierte Eingabe:
hdfs dfs -cat /user/labex/job-diagnostics/data/rejected.txt
Sie enthält eine normale Produktzeile, gefolgt von BAD_RECORD. Der Übungsjob verwendet einen Map-Versuch, damit derselbe absichtliche Fehler nicht wiederholt erneut versucht wird. Der nächste Befehl soll fehlschlagen.
hadoop jar /home/labex/project/tools/controlled-failure.jar /user/labex/job-diagnostics/data/rejected.txt /user/labex/job-diagnostics/results/failed-example > /home/labex/project/output/failed-job.log 2>&1
Warten Sie auf die Eingabeaufforderung und lesen Sie dann das Ende des Protokolls:
tail -n 25 /home/labex/project/output/failed-job.log
Anders als in den vorherigen Fällen sollte dieser Lauf eine übermittelte YARN-Anwendung und Belege für einen Taskfehler haben. Erfassen Sie ihre tatsächliche ID mit demselben Muster für die Anwendungsliste wie im vorherigen Lab:
yarn application -list -appStates ALL | grep -o 'application_[0-9]*_[0-9]*' > /home/labex/project/output/failed-application-id.txt
Fragen Sie ihren Bericht ab und speichern Sie ihn:
yarn application -status "$(cat /home/labex/project/output/failed-application-id.txt)" > /home/labex/project/output/failed-application-status.txt
Lesen Sie den Bericht:
cat /home/labex/project/output/failed-application-status.txt
Suchen Sie Anwendungskennung, Abschlussstatus und Diagnoseangaben. Der Abschlussstatus sollte FAILED sein; der Bericht ist ein Beleg von YARN und keine handgeschriebene Fehlerkennzeichnung. Lesen Sie auch die echten zusammengeführten Protokolle:
yarn logs -applicationId "$(cat /home/labex/project/output/failed-application-id.txt)" > /home/labex/project/output/failed-application.log
Suchen Sie darin mit grep die bekannte Übungsdiagnose:
grep 'Training input rejected' /home/labex/project/output/failed-application.log
Die Meldung verweist auf den markierten Datensatz. Sie sind von einem allgemeinen Befehlsrückgabewert ungleich null zu einer konkreten Erklärung gelangt, die durch Anwendungs- und Taskprotokolle gestützt wird. Bewahren Sie diese Belege auf, statt jeden Fehler als Anlass zum Neustart des Clusters zu behandeln.
Korrigieren Sie die Batch-Auswahl und schließen Sie einen Lauf ab
In diesem Schritt verwenden Sie die saubere Eingabe und ein neues Ausgabeverzeichnis und halten anschließend eine kurze, beleggestützte Diagnose fest.
Die vorgesehene Berichtseingabe ist clean.txt; die abgelehnte Datei war ein Übungsbeispiel. Bewahren Sie beide Originale auf. Übermitteln Sie das bekannte WordCount-Beispiel nur mit der sauberen Datei und verwenden Sie ein neues Ergebnisverzeichnis:
hadoop jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.5.0.jar wordcount /user/labex/job-diagnostics/data/clean.txt /user/labex/job-diagnostics/results/successful-run > /home/labex/project/output/successful-job.log 2>&1
Dieser Befehl sollte erfolgreich zurückkehren. Die Eingabe enthält zwei Vorkommen von notebook, eines von pen und eines von folder. Lesen Sie das Ergebnis:
hdfs dfs -cat '/user/labex/job-diagnostics/results/successful-run/part-*' | sort
Erwartete Anzahlen:
folder 1
notebook 2
pen 1
Das Protokoll des erfolgreichen Treibers enthält dessen Anwendungs-ID. sort -u sortiert und entfernt wiederholte identische ID-Zeilen, sodass die eine ID dieses Aufrufs übrig bleibt:
grep -o 'application_[0-9]*_[0-9]*' /home/labex/project/output/successful-job.log | sort -u > /home/labex/project/output/successful-application-id.txt
Bestätigen Sie den tatsächlichen Status der erfolgreichen Anwendung:
yarn application -status "$(cat /home/labex/project/output/successful-application-id.txt)"
Der Abschlussstatus sollte SUCCEEDED sein. Führen Sie die früheren Belege in einer lokalen Diagnosedatei zusammen:
cat /home/labex/project/output/connection-error.log /home/labex/project/output/missing-input.log /home/labex/project/output/existing-output.log /home/labex/project/output/failed-application-status.txt > /home/labex/project/output/diagnosis.md
Hängen Sie die gewählte Korrektur an. printf gibt den Text aus, und \n erzeugt Zeilenumbrüche; >> hängt an, statt die erfassten Belege zu ersetzen:
printf '\nRepair: select /user/labex/job-diagnostics/data/clean.txt and use the new /user/labex/job-diagnostics/results/successful-run output. Preserve original inputs and the existing result directory.\n' >> /home/labex/project/output/diagnosis.md
Diese Aufzeichnung verbindet Fehler, Beobachtung und Maßnahme. Ist ein Dienst nicht verfügbar oder liegt ein Plattformfehler außerhalb Ihres Zugriffsbereichs vor, halten Sie Endpunkt und Meldung fest und melden Sie das Problem, statt den Speicher neu zu formatieren. Bei den hier geübten Problemen genügte eine gezielte Pfad- oder Eingabeauswahl.
Zusammenfassung
Sie haben Verbindungsfehler, fehlende Eingaben und vorhandene Ausgabepfade von einem Taskfehler in einer angenommenen YARN-Anwendung unterschieden. Mit tatsächlichem Anwendungszustand und Taskprotokollen haben Sie eine kontrollierte Ablehnung erklärt und anschließend einen korrekten Batch mit sauberer Eingabe und neuem Ausgabepfad abgeschlossen.
Die letzte Challenge des Kurses kombiniert diese Vorgehensweisen mit Eingabeorganisation und Berechtigungen. Sie schließen darin einen neuen Batch eigenständig mit bereits geübten Methoden ab.
