L’enquêteur des journaux

Introduction

C’est votre troisième jour chez LabEx Corporation, et le projet Phoenix vient de subir une catastrophe ! En arrivant au bureau, vous trouvez Sarah Chen et l’équipe de développement en pleine crise. L’application que vous avez aidé à organiser hier rencontre des erreurs critiques pendant sa première phase majeure de test.

Les alertes d’urgence affluent dans les systèmes de supervision, les utilisateurs signalent des défaillances de l’application et le pipeline de déploiement est complètement bloqué. Sarah se tourne vers vous, désespérée : l’ingénieur DevOps senior est absent pour maladie et la date limite du projet approche à grands pas.

« Nous avons besoin de notre meilleur enquêteur », vous dit Sarah en vous tendant le rapport d’incident. « Votre méthode systématique pour organiser nos fichiers était exactement ce qu’il nous fallait. Maintenant, nous avons besoin de cette même rigueur pour résoudre ce mystère. »

Votre mission consiste à examiner en profondeur le serveur du projet Phoenix, à analyser les journaux et les fichiers de configuration, puis à découvrir la cause racine de ces défaillances. Vous utiliserez des outils avancés de la ligne de commande Linux pour rassembler les indices et rétablir la stabilité de l’application que votre équipe a mis tant d’efforts à construire. L’avenir du projet Phoenix — et peut-être votre carrière chez TechNova — dépend de vos talents d’enquêteur !

Examiner le contenu du fichier journal de l’application

Votre première tâche consiste, en tant qu’enquêteur, à vérifier le fichier journal de l’application du projet Phoenix. L’application écrit ses journaux dans ~/project/logs/app.log. Une grande quantité de messages peut être difficile à examiner ; vous devez donc trouver rapidement les messages d’erreur critiques pour comprendre ce qui ne va pas dans le système que vous avez aidé à organiser hier.

Tâches

• Filtrez le fichier ~/project/logs/app.log afin de trouver toutes les lignes contenant le mot ERROR.
• Enregistrez les lignes filtrées dans un nouveau fichier nommé ~/project/error_report.txt.

Exigences

• Vous devez utiliser un outil de la ligne de commande pour rechercher le fichier.
• Le fichier d’entrée de la recherche est ~/project/logs/app.log.
• La sortie doit être enregistrée dans un fichier nommé ~/project/error_report.txt, situé dans le répertoire ~/project.
• Le fichier de sortie doit contenir uniquement les lignes contenant le mot ERROR.

Indications

• La commande grep est parfaitement adaptée à la recherche de motifs dans des fichiers texte.
• Pour enregistrer la sortie d’une commande dans un fichier, vous pouvez utiliser l’opérateur de redirection >. Il crée le fichier s’il n’existe pas ou l’écrase s’il existe déjà.

Exemples

Après avoir filtré correctement le fichier journal, le fichier ~/project/error_report.txt doit contenir uniquement les lignes d’erreur :

$ cat ~/project/error_report.txt
[2023-10-26 10:00:03] ERROR: Failed to process payment transaction #12345.
[2023-10-26 10:00:05] ERROR: NullPointerException at com.innovatech.Billing.process(Billing.java:101).

Le fichier doit contenir exactement 2 lignes, qui commencent toutes deux par un horodatage et contiennent le mot « ERROR ».

Examiner les messages de démarrage du système

Les erreurs de l’application peuvent être le symptôme d’un problème matériel ou lié au noyau. Le tampon circulaire du noyau est un bon endroit pour rechercher ce type de problème : il contient les messages du processus de démarrage du système et des opérations des pilotes.

Tâches

• Examinez les messages du noyau afin de trouver les lignes liées à fail ou à error.
• Enregistrez ces résultats dans un fichier nommé ~/project/boot_issues.txt.

Exigences

• Vous devez utiliser la commande dmesg pour afficher les messages du noyau.
• La recherche de fail ou error doit respecter la casse.
• Les résultats doivent être enregistrés dans un fichier nommé ~/project/boot_issues.txt.
• Remarque : vous devrez peut-être disposer de privilèges administrateur (sudo) pour accéder aux messages du noyau.

Indications

• La commande dmesg affiche les messages du noyau. Vous pouvez transmettre sa sortie à une autre commande au moyen d’un « tube » pour la filtrer.
• L’opérateur de tube | envoie la sortie d’une commande vers l’entrée d’une autre commande.
• L’option -i de la commande grep rend la recherche insensible à la casse.
• Pour rechercher plusieurs motifs à la fois, par exemple fail OU error, vous pouvez utiliser grep -E 'pattern1|pattern2'.
• Remarque : si vous obtenez l’erreur « Operation not permitted », essayez d’exécuter la commande avec sudo afin d’obtenir les privilèges nécessaires.

Exemples

Après avoir filtré correctement les messages du noyau, le fichier ~/project/boot_issues.txt doit contenir les messages système pertinents :

$ cat ~/project/boot_issues.txt
[    0.330755] acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.
[    1.026520] RAS: Correctable Errors collector initialized.
[   28.260800] kernel: [   10.123456] my-driver: probe of 0000:00:1f.0 failed with error -2

Le fichier doit contenir des messages du noyau incluant des mots comme « fail » ou « error », sans distinction entre majuscules et minuscules, et signalant d’éventuels problèmes matériels ou liés aux pilotes pendant le démarrage du système.

Examiner le fichier de configuration du serveur web

Aucun problème matériel critique n’a été trouvé. Le problème se situe peut-être dans la configuration du serveur web. Examinons le fichier de configuration de Nginx pour voir comment le serveur est configuré. Une mauvaise configuration, par exemple un nombre trop faible de processus worker, peut parfois créer des goulots d’étranglement et entraîner des défaillances de l’application sous charge.

Tâches

• Recherchez dans le fichier de configuration du serveur web situé à ~/project/config/nginx.conf.
• Trouvez la ligne contenant la directive worker_processes.
• Ajoutez cette ligne à la fin du fichier ~/project/error_report.txt créé à la première étape.

Exigences

• Le fichier d’entrée est ~/project/config/nginx.conf.
• Vous devez ajouter le résultat à la fin de ~/project/error_report.txt, sans l’écraser.

Indications

• Vous pouvez utiliser à nouveau grep.
• Pour ajouter la sortie à la fin d’un fichier au lieu de l’écraser, utilisez l’opérateur >>.

Exemples

Après avoir ajouté la ligne worker_processes à votre rapport d’erreurs existant, le fichier ~/project/error_report.txt doit contenir les lignes d’erreur initiales ainsi que la nouvelle ligne de configuration :

$ cat ~/project/error_report.txt
[2023-10-26 10:00:03] ERROR: Failed to process payment transaction #12345.
[2023-10-26 10:00:05] ERROR: NullPointerException at com.innovatech.Billing.process(Billing.java:101).
worker_processes 4;

Le fichier doit contenir 3 lignes au total : les 2 lignes d’erreur initiales et 1 nouvelle ligne contenant « worker_processes 4; ».

Comparer les fichiers de configuration de staging et de production

Les différences de configuration sont une cause fréquente de problèmes en production. Une fonctionnalité peut fonctionner parfaitement en staging, mais échouer en production à cause d’une petite différence de configuration. Comparons les fichiers de configuration de l’application dans les deux environnements afin de repérer d’éventuelles différences.

Tâches

• Comparez le fichier de configuration du staging ~/project/config/staging/app.conf avec celui de la production ~/project/config/production/app.conf.
• Enregistrez les différences dans un nouveau fichier nommé ~/project/config_diff.txt.

Exigences

• Vous devez utiliser la commande diff.
• La sortie présentant les différences doit être enregistrée dans ~/project/config_diff.txt.

Indications

• La commande diff est spécialement conçue pour comparer deux fichiers ligne par ligne.
• La syntaxe de base est diff file1 file2. Elle indique les modifications à apporter à file1 pour le rendre identique à file2.
• L’ordre des fichiers est important ! diff A B et diff B A produisent des sorties différentes.
• Vous pouvez rediriger la sortie de diff vers un fichier, comme vous l’avez fait avec grep.

Exemples

Après avoir comparé les fichiers de configuration du staging et de la production, le fichier ~/project/config_diff.txt doit afficher les différences entre les deux environnements :

$ cat ~/project/config_diff.txt
1,5c1,5
< ## Staging Configuration
< database.url=jdbc:mysql://staging-db:3306/nexus
< api.key=staging_key_abc123
< feature.flag.new_dashboard=true
< timeout.ms=3000
---
> ## Production Configuration
> database.url=jdbc:mysql://prod-db:3306/nexus
> api.key=prod_key_xyz789
> feature.flag.new_dashboard=false
> timeout.ms=5000

La sortie de diff indique les modifications à apporter au fichier de configuration du staging pour le rendre identique à celui de la production. Les lignes commençant par < proviennent du fichier de staging, tandis que les lignes commençant par > proviennent du fichier de production. Cela révèle que l’environnement de production utilise des URL de base de données, des clés d’API, des indicateurs de fonctionnalité et des valeurs de délai d’attente différents de ceux du staging.

Vérifier la cohérence des répertoires entre les serveurs

La différence de configuration constitue une piste importante ! Il semble que le serveur de production puisse également être dépourvu de certains fichiers essentiels présents sur le serveur de staging. Cela pourrait être dû à un déploiement ayant échoué. Simulons cette situation en comparant deux répertoires qui représentent les structures de fichiers de deux serveurs différents.

Tâches

• Vous disposez de deux répertoires : /home/labex/project/server1_files représente le serveur de staging, et /home/labex/project/server2_files représente le serveur de production.
• Comparez ces deux répertoires afin de déterminer quels fichiers sont propres à server1_files.
• Enregistrez la sortie complète de la comparaison dans un fichier nommé /home/labex/project/missing_files.txt.

Exigences

• Vous devez utiliser la commande diff pour comparer les deux répertoires.
• La sortie doit être enregistrée dans /home/labex/project/missing_files.txt.

Indications

• La commande diff peut également comparer des répertoires lorsque vous lui fournissez des chemins de répertoires plutôt que des chemins de fichiers.
• Il est recommandé d’utiliser l’option -r ou --recursive avec diff pour comparer des répertoires, car cette option compare récursivement tous les fichiers qu’ils contiennent.
• Le format de sortie de diff pour les répertoires indique explicitement quels fichiers sont « Only in » un répertoire donné.
• Comme pour les fichiers, l’ordre des répertoires est important. diff dir1 dir2 indique ce qui se trouve dans dir1 mais pas dans dir2, tandis que diff dir2 dir1 affiche l’inverse.

Exemples

Après avoir comparé les deux répertoires des serveurs, le fichier /home/labex/project/missing_files.txt doit indiquer quels fichiers sont absents du serveur de production :

$ cat /home/labex/project/missing_files.txt
Only in /home/labex/project/server1_files: asset2.js

Cette sortie indique que asset2.js existe dans le premier répertoire (server1_files, qui représente le serveur de staging), mais qu’il est absent du deuxième répertoire (server2_files, qui représente le serveur de production). En comparant d’abord le staging, puis la production, vous pouvez identifier facilement les fichiers absents de la production, ce qui pourrait expliquer certaines défaillances de l’application.

Résumé

Excellent travail d’enquête ! Vous avez identifié avec succès les causes racines des défaillances critiques du projet Phoenix et fourni à Sarah Chen ainsi qu’à l’équipe de développement des informations concrètes pour résoudre ces problèmes.

Grâce à votre investigation méthodique, vous maîtrisez désormais plusieurs commandes essentielles de dépannage :

• grep : pour filtrer les fichiers journaux et extraire les informations critiques sur les erreurs.
• dmesg : pour examiner les problèmes matériels et les problèmes liés au noyau au niveau du système.
• diff : pour comparer les fichiers de configuration et repérer les différences entre les environnements.
• Les pipelines de commandes et la redirection : pour traiter et documenter efficacement vos résultats.

Votre approche méthodique de l’analyse des journaux a évité au projet Phoenix une défaillance potentiellement catastrophique. L’équipe de développement dispose maintenant d’une direction claire pour corriger les différences de configuration et les fichiers de déploiement manquants que vous avez découverts.

Sarah Chen a été tellement impressionnée par vos talents d’enquêteur qu’elle vous recommande pour un poste dans la sécurité. Demain, vous endosserez le rôle du Gardien de la Forteresse afin de sécuriser l’infrastructure du projet Phoenix et de la protéger contre les menaces futures !