JOUR 03 : L'enquêteur de journaux

Introduction

C'est le troisième jour chez LabEx Corporation, et le désastre a frappé le Projet Phoenix ! En arrivant au bureau, vous trouvez Sarah Chen et l'équipe de développement en mode gestion de crise. L'application que vous avez aidé à organiser hier a rencontré des erreurs critiques lors de sa première phase de test majeure.

Les alertes d'urgence inondent les systèmes de surveillance, les utilisateurs signalent des pannes applicatives et le pipeline de déploiement est totalement à l'arrêt. Sarah se tourne vers vous avec un regard désespéré : l'ingénieur DevOps senior est en arrêt maladie, et l'échéance du projet approche à grands pas.

« Nous avons besoin de notre meilleur enquêteur sur ce coup-là », déclare Sarah en vous remettant le rapport d'incident. « Votre approche systématique pour organiser nos fichiers était exactement ce dont nous avions besoin. Maintenant, nous avons besoin de cette même rigueur méthodologique pour résoudre ce mystère. »

Votre mission consiste à plonger au cœur du serveur du Projet Phoenix, à analyser les journaux (logs) et les fichiers de configuration, et à découvrir la cause profonde de ces défaillances. Vous utiliserez des outils de ligne de commande Linux avancés pour rassembler les indices et restaurer 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 de détective !

Examen du contenu du fichier journal de l'application

Votre première étape en tant qu'enquêteur est de vérifier le fichier journal de l'application du Projet Phoenix. L'application écrit ses logs dans ~/project/logs/app.log. Un flux massif de messages peut être déroutant, vous devez donc trouver rapidement les messages d'erreur critiques pour comprendre ce qui ne va pas dans le système que vous avez organisé hier.

Tâches

• Filtrer le fichier ~/project/logs/app.log pour trouver toutes les lignes contenant le mot ERROR.
• Enregistrer les lignes filtrées dans un nouveau fichier nommé ~/project/error_report.txt.

Exigences

• Vous devez utiliser un outil en ligne de commande pour fouiller le fichier.
• Le fichier d'entrée pour votre recherche est ~/project/logs/app.log.
• Le résultat doit être enregistré dans un fichier nommé ~/project/error_report.txt dans le répertoire ~/project.
• Le fichier de sortie ne doit contenir que les lignes comportant le mot ERROR.

Astuces

• La commande grep est parfaite pour rechercher des motifs (patterns) dans des fichiers texte.
• Pour enregistrer la sortie d'une commande dans un fichier, vous pouvez utiliser l'opérateur de redirection >. Cela créera le fichier s'il n'existe pas ou l'écrasera s'il existe déjà.

Exemples

Après avoir filtré avec succès le fichier journal, votre fichier ~/project/error_report.txt ne devrait contenir que 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, commençant toutes deux par des horodatages et contenant le mot "ERROR".

Investigation des messages de démarrage du système

Les erreurs de l'application pourraient être le symptôme d'un problème plus profond au niveau du matériel ou du noyau (kernel). Un bon endroit pour rechercher de tels problèmes est le tampon circulaire du noyau (kernel ring buffer), qui contient les messages du processus de démarrage du système et des opérations des pilotes.

Tâches

• Examiner les messages du noyau du système pour trouver toute ligne liée à fail ou error.
• Enregistrer ces découvertes dans un fichier nommé ~/project/boot_issues.txt.

Exigences

• Vous devez utiliser la commande dmesg pour visualiser les messages du noyau.
• Votre recherche pour fail ou error doit être insensible à la casse (majuscules/minuscules).
• Les résultats doivent être enregistrés dans un fichier nommé ~/project/boot_issues.txt.
• Note : Vous pourriez avoir besoin des privilèges d'administrateur (sudo) pour accéder aux messages du noyau.

Astuces

• La commande dmesg affiche les messages du noyau. Vous pouvez envoyer sa sortie vers une autre commande pour la filtrer.
• L'opérateur tube (pipe) | envoie la sortie d'une commande vers l'entrée d'une autre.
• L'option -i de la commande grep rend la recherche insensible à la casse.
• Pour rechercher plusieurs motifs à la fois (comme fail OU error), vous pouvez utiliser grep -E 'motif1|motif2'.
• Note : Si vous rencontrez une erreur "Operation not permitted", essayez d'exécuter la commande avec sudo pour obtenir les privilèges nécessaires.

Exemples

Après avoir filtré les messages du noyau, votre fichier ~/project/boot_issues.txt devrait 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 tenir compte de la casse), révélant d'éventuels problèmes matériels ou de pilotes lors du démarrage.

Examen du 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 Nginx pour voir comment il est paramétré. Parfois, des erreurs de configuration, comme un nombre trop restreint de processus de travail (worker processes), peuvent causer des goulots d'étranglement et entraîner des pannes applicatives sous forte charge.

Tâches

• Rechercher dans le fichier de configuration du serveur web situé à ~/project/config/nginx.conf.
• Trouver la ligne contenant la directive worker_processes.
• Ajouter (append) cette ligne à la fin du fichier ~/project/error_report.txt que vous avez créé à la première étape.

Exigences

• Le fichier d'entrée est ~/project/config/nginx.conf.
• Vous devez ajouter le résultat à ~/project/error_report.txt, et non l'écraser.

Astuces

• Vous pouvez à nouveau utiliser grep pour cette tâche.
• Pour ajouter du contenu à la fin d'un fichier au lieu de le remplacer, utilisez l'opérateur >>.

Exemples

Après avoir ajouté la ligne worker_processes à votre rapport d'erreur existant, le fichier ~/project/error_report.txt devrait maintenant contenir à la fois les lignes d'erreur d'origine et 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 plus 1 nouvelle ligne avec "worker_processes 4;".

Comparaison des fichiers de configuration de Staging et de Production

Une source courante de problèmes en production est une divergence entre les environnements de pré-production (staging) et de production. Une fonctionnalité peut fonctionner parfaitement en staging mais échouer en production à cause d'une infime différence de configuration. Comparons les fichiers de configuration de l'application des deux environnements pour repérer d'éventuelles différences.

Tâches

• Comparer le fichier de configuration de staging ~/project/config/staging/app.conf avec le fichier de configuration de production ~/project/config/production/app.conf.
• Enregistrer les différences dans un nouveau fichier nommé ~/project/config_diff.txt.

Exigences

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

Astuces

• La commande diff est conçue spécifiquement pour comparer deux fichiers ligne par ligne.
• La syntaxe de base est diff fichier1 fichier2, où elle indique les modifications à apporter au fichier1 pour le rendre identique au fichier2.
• L'ordre des fichiers est important ! diff A B et diff B A donneront des sorties différentes.
• Vous pouvez rediriger la sortie de diff vers un fichier tout comme vous l'avez fait avec grep.

Exemples

Après avoir comparé les fichiers de configuration de staging et de production, votre fichier ~/project/config_diff.txt devrait 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

Le résultat du diff montre quels changements devraient être faits au fichier de staging pour qu'il corresponde au fichier de production. Les lignes commençant par < indiquent le contenu du fichier de staging, tandis que les lignes commençant par > indiquent le contenu du fichier de production. Cela révèle que l'environnement de production utilise des URL de base de données, des clés API, des drapeaux de fonctionnalités (feature flags) et des valeurs de délai d'attente (timeout) différents de ceux du staging.

Vérification de la cohérence des répertoires entre les serveurs

La différence de configuration est une piste sérieuse ! Il semble que le serveur de production puisse également manquer de certains fichiers critiques présents sur le serveur de staging. Cela pourrait être dû à un échec de déploiement. Simulons cela en comparant deux répertoires représentant les structures de fichiers de deux serveurs différents.

Tâches

• Vous disposez de deux répertoires : /home/labex/project/server1_files (représentant le serveur de staging) et /home/labex/project/server2_files (représentant le serveur de production).
• Comparez ces deux répertoires pour découvrir quels fichiers sont uniques à server1_files.
• Enregistrez le résultat complet 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.
• Le résultat doit être enregistré dans /home/labex/project/missing_files.txt.

Astuces

• La commande diff peut également comparer des répertoires si vous fournissez des chemins de répertoires au lieu de chemins de fichiers.
• Utiliser l'option -r ou --recursive avec diff est une bonne pratique pour comparer des répertoires, car cela comparera tous les fichiers qu'ils contiennent.
• Le format de sortie de diff sur des répertoires indiquera explicitement quels fichiers sont "Seulement dans" (Only in) un répertoire spécifique.
• Comme pour les fichiers, l'ordre compte. diff rep1 rep2 montre ce qui est dans rep1 mais pas dans rep2, tandis que diff rep2 rep1 montre l'inverse.

Exemples

Après avoir comparé les deux répertoires serveurs, votre fichier /home/labex/project/missing_files.txt devrait indiquer quels fichiers manquent sur le serveur de production :

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

Ce résultat indique que asset2.js existe dans le premier répertoire (server1_files, le staging) mais est absent du second (server2_files, la production). En comparant le staging en premier, nous identifions facilement les fichiers manquants en production, ce qui pourrait expliquer certaines pannes applicatives.

Résumé

Travail de détective exceptionnel ! Vous avez identifié avec succès les causes profondes des défaillances critiques du Projet Phoenix et fourni à Sarah Chen ainsi qu'à l'équipe de développement des informations exploitables pour résoudre les problèmes.

Grâce à votre enquête systématique, vous avez maîtrisé des commandes de dépannage essentielles :

• grep : Pour filtrer les fichiers journaux et extraire les informations d'erreur critiques.
• dmesg : Pour enquêter sur les problèmes matériels et les erreurs au niveau du noyau système.
• diff : Pour comparer les fichiers de configuration et identifier les divergences entre les environnements.
• Tubes (pipelines) et redirections : Pour traiter et documenter efficacement vos découvertes.

Votre approche méthodique de l'analyse des journaux a sauvé le Projet Phoenix d'un échec potentiellement catastrophique. L'équipe de développement dispose désormais d'une direction claire pour corriger les erreurs de configuration et les fichiers de déploiement manquants que vous avez découverts.

Sarah Chen a été si impressionnée par vos compétences d'enquêteur qu'elle vous recommande pour un rôle en cybersécurité. Demain, vous endosserez le rôle de Gardien de la Forteresse pour sécuriser l'infrastructure du Projet Phoenix et la protéger contre les menaces futures !