Introduction
Le lot du commerçant a réussi hier, mais la commande d’aujourd’hui signale une erreur. La répéter sans lire le message peut masquer la véritable cause ou encourager un raccourci destructeur. Une entrée manquante, une adresse de service incorrecte et une tâche de traitement en échec nécessitent des réponses différentes.
Vous suivrez une courte démarche de diagnostic : identifier le système de fichiers et la connexion, vérifier l’existence et la lisibilité des entrées, vérifier le chemin de sortie, puis examiner l’état et les journaux d’une application acceptée. Une erreur côté client peut survenir avant la soumission d’une application. Une application soumise possède une identité YARN dont les diagnostics apportent des preuves supplémentaires.
Ce lab fournit volontairement plusieurs échecs, dont une application pédagogique précompilée qui rejette un enregistrement d’entrée marqué. Ce sont des cas d’apprentissage contrôlés, et non des pannes d’infrastructure aléatoires. Vous les conserverez comme preuves et terminerez une exécution WordCount correcte avec d’autres chemins d’entrée et de sortie. Aucun code Java, réinstallation de service, formatage ou suppression étendue n’est nécessaire. Tous les éléments d’exercice sont indépendants ; utilisez le Terminal.
Diagnostiquer les erreurs de connexion et d’entrée
Dans cette étape, vous distinguerez une mauvaise adresse de service d’un fichier manquant en lisant de véritables erreurs du client.
Commencez dans l’espace de travail local :
cd /home/labex/project
Rappelez-vous d’abord le système de fichiers configuré :
hdfs getconf -confKey fs.defaultFS
Il doit être hdfs://localhost:9000. Demandez maintenant volontairement au client de se connecter au port 1, où aucun NameNode n’écoute. Les propriétés -D ci-dessous limitent les nouvelles tentatives de connexion et définissent un délai de connexion de 2 000 millisecondes pour cette invocation, afin de borner l’erreur intentionnelle. Elles ne modifient pas la configuration partagée.
La redirection > file 2>&1 enregistre la sortie normale dans un fichier local et envoie la sortie d’erreur vers cette même destination. La commande suivante doit échouer.
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
Lisez l’erreur enregistrée :
cat /home/labex/project/output/connection-error.log
Repérez l’échec ou le refus de connexion et l’adresse incorrecte. Cela survient avant qu’une liste de système de fichiers puisse réussir. Ne formatez pas HDFS et ne réinstallez pas les services ; la commande utilisait le mauvais point de connexion. Revenez au point de connexion configuré en utilisant le chemin par défaut :
hdfs dfs -ls /user/labex/job-diagnostics/data
Vous devriez voir clean.txt et rejected.txt. La connexion fonctionne. Demander à ce système de fichiers sain un fichier inexistant est un autre problème. La commande suivante doit échouer.
hdfs dfs -ls /user/labex/job-diagnostics/data/missing.txt > /home/labex/project/output/missing-input.log 2>&1
Examinez le message :
cat /home/labex/project/output/missing-input.log
Il doit indiquer que le chemin nommé n’existe pas. Vérifiez l’entrée prévue avec l’opération de lecture connue :
hdfs dfs -cat /user/labex/job-diagnostics/data/clean.txt
Les deux lignes sont notebook pen et notebook folder. Corriger le chemin d’entrée résout un problème de fichier manquant ; modifier la configuration du serveur ne le résoudrait pas. Conservez les journaux d’erreurs comme preuves.
Reconnaître un chemin de sortie existant
Dans cette étape, vous observerez pourquoi un traitement refuse un répertoire de sortie déjà existant et choisirez de le préserver plutôt que d’effectuer une suppression étendue.
La préparation a créé un répertoire de résultats vide existing pour représenter un emplacement de sortie déjà réservé. Examinez cette entrée de répertoire :
hdfs dfs -ls -d /user/labex/job-diagnostics/results/existing
Le format de sortie de l’exemple MapReduce prévoit de créer un nouveau répertoire de sortie. Un répertoire existant peut déclencher un rejet côté client avant qu’une application de traitement soit acceptée. La commande suivante doit échouer.
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
Lisez le message enregistré :
cat /home/labex/project/output/existing-output.log
Repérez un message indiquant que le répertoire de sortie existe déjà ou FileAlreadyExistsException. C’est un conflit de chemins, pas la preuve que l’algorithme de comptage des produits est incorrect.
Listez les applications acceptées par YARN :
yarn application -list -appStates ALL
Ces erreurs du client ne doivent pas produire une application de traitement terminée. Un client peut contacter les services du cluster ou obtenir un identifiant pendant la préparation de la soumission ; une application acceptée et son état constituent des preuves distinctes.
Vous préserverez le répertoire réservé et utiliserez un nouveau chemin de sortie lors de l’exécution réussie. Supprimer tout results ou supprimer l’entrée brute serait une modification bien plus large que le problème ne l’exige.
Examiner une véritable application en échec
Dans cette étape, vous soumettrez une application pédagogique contrôlée et utiliserez sa véritable identité YARN et ses journaux pour expliquer l’échec.
Le fichier controlled-failure.jar préparé accepte un chemin d’entrée et un nouveau chemin de sortie. Son mapper rejette volontairement le marqueur BAD_RECORD. Vous n’avez pas besoin d’examiner ou de modifier le code Java ; le but est de distinguer l’échec d’une tâche d’une application acceptée des erreurs du client précédentes.
Lisez d’abord l’entrée marquée :
hdfs dfs -cat /user/labex/job-diagnostics/data/rejected.txt
Elle contient une ligne normale de produits suivie de BAD_RECORD. Le traitement pédagogique utilise une seule tentative de Map pour ne pas répéter plusieurs fois le même échec intentionnel. La commande suivante doit échouer.
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
Attendez l’invite, puis lisez la fin de son journal :
tail -n 25 /home/labex/project/output/failed-job.log
Contrairement aux cas précédents, cette exécution doit avoir une application YARN soumise et des preuves d’échec de tâche. Recueillez son véritable identifiant avec le même motif de liste d’applications que dans le lab précédent :
yarn application -list -appStates ALL | grep -o 'application_[0-9]*_[0-9]*' > /home/labex/project/output/failed-application-id.txt
Interrogez et enregistrez son rapport :
yarn application -status "$(cat /home/labex/project/output/failed-application-id.txt)" > /home/labex/project/output/failed-application-status.txt
Lisez le rapport :
cat /home/labex/project/output/failed-application-status.txt
Repérez l’identité de l’application, le statut final et les diagnostics. Le statut final doit être FAILED ; le rapport est une preuve issue de YARN, et non une étiquette d’échec écrite à la main. Lisez aussi les véritables journaux agrégés :
yarn logs -applicationId "$(cat /home/labex/project/output/failed-application-id.txt)" > /home/labex/project/output/failed-application.log
Utilisez grep pour y trouver le diagnostic pédagogique connu :
grep 'Training input rejected' /home/labex/project/output/failed-application.log
Le message désigne l’enregistrement marqué. Vous êtes passé d’un code de sortie non nul générique à une explication précise étayée par les journaux de l’application et des tâches. Préservez ces preuves au lieu de considérer chaque échec comme une raison de redémarrer le cluster.
Corriger la sélection du lot et terminer une exécution
Dans cette étape, vous utiliserez l’entrée correcte et un nouveau répertoire de sortie, puis conserverez un bref diagnostic fondé sur les preuves.
L’entrée de reporting prévue est clean.txt ; le fichier rejeté était une donnée d’exercice pédagogique. Conservez les deux originaux. Soumettez l’exemple WordCount connu uniquement sur le fichier correct, avec un nouveau répertoire de résultats :
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
Cette commande doit se terminer avec succès. L’entrée contient deux occurrences de notebook, une de pen et une de folder. Lisez le résultat :
hdfs dfs -cat '/user/labex/job-diagnostics/results/successful-run/part-*' | sort
Comptages attendus :
folder 1
notebook 2
pen 1
Le journal du programme pilote réussi inclut son identifiant d’application. sort -u trie et supprime les lignes d’identifiants identiques répétées, ne laissant que l’identifiant de cette invocation :
grep -o 'application_[0-9]*_[0-9]*' /home/labex/project/output/successful-job.log | sort -u > /home/labex/project/output/successful-application-id.txt
Confirmez le véritable état de réussite de l’application :
yarn application -status "$(cat /home/labex/project/output/successful-application-id.txt)"
Le statut final doit être SUCCEEDED. Rassemblez les preuves précédentes dans un relevé de diagnostic local :
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
Ajoutez le choix de réparation. printf affiche le texte et \n crée des sauts de ligne ; >> ajoute le texte au lieu de remplacer les preuves recueillies :
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
Ce relevé relie erreur, observation et action. Pour un service indisponible ou un défaut de plateforme hors de votre périmètre d’accès, enregistrez le point de connexion et le message, puis signalez le problème plutôt que de reformater le stockage. Pour les problèmes enseignés ici, un choix précis de chemin ou d’entrée suffisait.
Résumé
Vous avez distingué les erreurs de connexion, les entrées manquantes et les chemins de sortie existants d’un échec de tâche dans une application YARN acceptée. Vous avez utilisé l’état réel de l’application et les journaux des tâches pour expliquer un rejet contrôlé, puis terminé un lot correct avec une entrée saine et un nouveau chemin de sortie.
Le défi final du cours combine ces habitudes avec l’organisation des entrées et les permissions. Il vous demande de terminer un nouveau lot de façon autonome avec les méthodes déjà pratiquées.
