JOUR 03 : L'enquêteur de logs

Introduction

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

Des alertes d'urgence inondent les systèmes de surveillance, les utilisateurs signalent des pannes d'application et le pipeline de déploiement est à l'arrêt. Sarah se tourne vers vous avec un regard désespéré : 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 sur ce coup-là », dit Sarah en vous tendant 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 réflexion méthodique pour résoudre ce mystère. »

Votre mission est de plonger au cœur du serveur du Projet Phoenix, d'analyser les journaux et les fichiers de configuration, et de découvrir la cause profonde de ces échecs. Vous utiliserez des outils avancés en ligne de commande Linux pour assembler les indices et rétablir la stabilité de l'application que votre équipe a travaillé si dur à 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 consiste à vérifier le fichier journal de l'application du Projet Phoenix. L'application écrit ses journaux dans ~/project/logs/app.log. Un déluge de messages peut être accablant, vous devez donc trouver rapidement les messages d'erreur critiques pour comprendre ce qui ne va pas avec le système que vous avez aidé à organiser hier.

Tâches

• Filtrez le fichier ~/project/logs/app.log pour 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 en ligne de commande pour effectuer la recherche dans le fichier.
• Le fichier d'entrée pour votre recherche est ~/project/logs/app.log.
• La sortie doit être enregistrée dans un fichier nommé ~/project/error_report.txt dans le répertoire ~/project.
• Le fichier de sortie ne doit contenir que les lignes contenant le mot ERROR.

Conseils

• La commande grep est parfaite pour rechercher des motifs 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".

Enquête sur les messages de démarrage du système

Les erreurs de l'application pourraient être le symptôme d'un problème matériel ou de noyau plus profond. 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

• Examinez les messages du noyau système pour toute ligne liée à 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.
• Votre recherche de fail ou error doit être insensible à la casse.
• Les résultats doivent être enregistrés dans un fichier nommé ~/project/boot_issues.txt.
• Remarque : Vous pourriez avoir besoin de privilèges administratifs (sudo) pour accéder aux messages du noyau.

Conseils

• La commande dmesg affiche les messages du noyau. Vous pouvez "rediriger" (pipe) sa sortie vers une autre commande pour le filtrage.
• L'opérateur 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 'pattern1|pattern2'.
• Remarque : 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é avec succès 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" (insensible à la casse), montrant des problèmes potentiels de matériel ou de pilote lors du démarrage du système.

Examen du fichier de configuration du serveur Web

Aucun problème matériel critique n'a été trouvé. Le problème pourrait se situer dans la configuration du serveur web. Examinons le fichier de configuration Nginx pour voir comment il est configuré. Parfois, des erreurs de configuration, comme un nombre trop faible de processus de travail (worker processes), peuvent provoquer des goulots d'étranglement de performance et entraîner des pannes d'application sous charge.

Tâches

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

Exigences

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

Conseils

• Vous pouvez utiliser grep à nouveau pour cette tâche.
• Pour ajouter une sortie à un fichier au lieu de l'écraser, 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 originales 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 : 2 lignes d'erreur originales 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 staging (pré-production) et de production. Une fonctionnalité peut fonctionner parfaitement en staging mais échouer en production en raison d'une petite différence de configuration. Comparons les fichiers de configuration de l'application des deux environnements pour repérer les différences.

Tâches

• Comparez le fichier de configuration de staging ~/project/config/staging/app.conf avec le fichier de configuration de 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 montrant les différences doit être enregistrée dans ~/project/config_diff.txt.

Conseils

• 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 montre quels changements doivent être apportés au fichier1 pour le rendre identique au fichier2.
• L'ordre des fichiers compte ! diff A B et diff B A montreront 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 montrer 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 montre quels changements devraient être apportés au fichier de configuration de staging pour qu'il corresponde au fichier de configuration de production. Les lignes commençant par < montrent le contenu du fichier de staging, tandis que les lignes commençant par > montrent 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 indicateurs de fonctionnalité et des valeurs de délai d'attente différents par rapport au staging.

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

La différence de configuration est une piste solide ! Il semble que le serveur de production puisse également manquer de certains fichiers critiques qui existent sur le serveur de staging. Cela pourrait être dû à un déploiement ayant échoué. Simulons cela en comparant deux répertoires qui représentent les structures de fichiers de deux serveurs différents.

Tâches

• Vous avez 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 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.

Conseils

• La commande diff peut également comparer des répertoires si vous fournissez des chemins de répertoire au lieu de chemins de fichier.
• L'utilisation de l'option -r ou --recursive avec diff est une bonne pratique pour comparer des répertoires, car elle comparera tous les fichiers qu'ils contiennent.
• Le format de sortie de diff sur les répertoires indiquera explicitement quels fichiers sont "Only in" (seulement dans) un répertoire spécifique.
• Tout comme pour les fichiers, l'ordre compte lors de la comparaison de répertoires. diff dir1 dir2 montre ce qui est dans dir1 mais pas dans dir2, tandis que diff dir2 dir1 montre l'inverse.

Exemples

Après avoir comparé les deux répertoires de serveurs, votre fichier /home/labex/project/missing_files.txt devrait montrer quels fichiers manquent sur le 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, représentant le serveur de staging) mais manque dans le second répertoire (server2_files, représentant le serveur de production). En comparant d'abord le staging puis la production, nous pouvons facilement identifier les fichiers qui manquent en production, ce qui pourrait expliquer certaines des pannes de l'application.

Résumé

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

Grâce à votre enquête systématique, vous maîtrisez désormais les commandes de dépannage essentielles :

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

Votre approche méthodique de l'analyse des journaux a sauvé le Projet Phoenix d'une défaillance potentiellement catastrophique. L'équipe de développement a maintenant 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é tellement impressionnée par vos compétences d'enquête qu'elle vous recommande pour un rôle dans la sécurité. Demain, vous vous glisserez dans la peau du Gardien de la Forteresse pour sécuriser l'infrastructure du Projet Phoenix et la protéger contre les menaces futures !