TAG 03: Der Log-Ermittler

Einführung

Es ist Tag 3 bei der LabEx Corporation, und das Projekt Phoenix steht vor dem Abgrund! Du kommst im Büro an und findest Sarah Chen und das Entwicklungsteam im Krisenmodus vor. Die Anwendung, bei deren Organisation du gestern geholfen hast, ist während ihrer ersten großen Testphase auf kritische Fehler gestoßen.

Notfallwarnungen überfluten die Überwachungssysteme, Benutzer melden Anwendungsabstürze, und die Deployment-Pipeline ist zum Stillstand gekommen. Sarah sieht dich verzweifelt an – der leitende DevOps-Engineer ist krank, und die Deadline für das Projekt rückt unaufhaltsam näher.

„Wir brauchen unseren besten Ermittler für diesen Fall“, sagt Sarah und überreicht dir den Vorfallsbericht. „Deine systematische Herangehensweise bei der Organisation unserer Dateien war genau das, was wir brauchten. Jetzt brauchen wir dasselbe methodische Denken, um dieses Rätsel zu lösen.“

Deine Mission ist es, tief in den Server von Projekt Phoenix einzutauchen, Protokolle und Konfigurationsdateien zu analysieren und die Grundursache dieser Fehler aufzudecken. Du wirst fortschrittliche Linux-Befehlszeilen-Tools verwenden, um die Hinweise zusammenzusetzen und die Stabilität der Anwendung wiederherzustellen, an der dein Team so hart gearbeitet hat. Die Zukunft von Projekt Phoenix – und möglicherweise deine Karriere bei TechNova – hängt von deinen detektivischen Fähigkeiten ab!

Überprüfung der Inhalte von Anwendungs-Logdateien

Dein erster Schritt als Ermittler ist die Überprüfung der Anwendungs-Logdatei von Projekt Phoenix. Die Anwendung schreibt ihre Protokolle in ~/project/logs/app.log. Eine Flut von Meldungen kann überwältigend sein, daher musst du die kritischen Fehlermeldungen schnell finden, um zu verstehen, was mit dem System, das du gestern mit organisiert hast, schiefläuft.

Aufgaben

• Durchsuche die Datei ~/project/logs/app.log nach allen Zeilen, die das Wort ERROR enthalten.
• Speichere die gefilterten Zeilen in einer neuen Datei namens ~/project/error_report.txt.

Anforderungen

• Du musst ein Befehlszeilen-Tool verwenden, um die Datei zu durchsuchen.
• Die Eingabedatei für deine Suche ist ~/project/logs/app.log.
• Die Ausgabe muss in einer Datei namens ~/project/error_report.txt im Verzeichnis ~/project gespeichert werden.
• Die Ausgabedatei sollte nur die Zeilen mit dem Wort ERROR enthalten.

Hinweise

• Der Befehl grep ist perfekt geeignet, um nach Mustern in Textdateien zu suchen.
• Um die Ausgabe eines Befehls in einer Datei zu speichern, kannst du den Umleitungsoperator > verwenden. Dies erstellt die Datei, falls sie nicht existiert, oder überschreibt sie, falls sie bereits vorhanden ist.

Beispiele

Nachdem du die Logdatei erfolgreich gefiltert hast, sollte deine Datei ~/project/error_report.txt nur noch die Fehlerzeilen enthalten:

$ 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).

Die Datei sollte genau 2 Zeilen enthalten, die beide mit Zeitstempeln beginnen und das Wort „ERROR“ enthalten.

Untersuchung von System-Boot-Meldungen

Die Anwendungsfehler könnten ein Symptom für ein tieferliegendes Hardware- oder Kernel-Problem sein. Ein guter Ort, um nach solchen Problemen zu suchen, ist der Kernel-Ringpuffer, der Meldungen aus dem Systemstartprozess und Treiberoperationen enthält.

Aufgaben

• Untersuche die Kernel-Meldungen des Systems auf Zeilen, die mit fail oder error in Verbindung stehen.
• Speichere diese Ergebnisse in einer Datei namens ~/project/boot_issues.txt.

Anforderungen

• Du musst den Befehl dmesg verwenden, um Kernel-Meldungen anzuzeigen.
• Deine Suche nach fail oder error sollte unabhängig von Groß- und Kleinschreibung sein.
• Die Ergebnisse müssen in einer Datei namens ~/project/boot_issues.txt gespeichert werden.
• Hinweis: Du benötigst möglicherweise Administratorrechte (sudo), um auf Kernel-Meldungen zuzugreifen.

Hinweise

• Der Befehl dmesg zeigt Kernel-Meldungen an. Du kannst seine Ausgabe zur Filterung an einen anderen Befehl „weiterleiten“ (pipe).
• Der Pipe-Operator | sendet die Ausgabe eines Befehls an die Eingabe eines anderen.
• Die Option -i des Befehls grep macht die Suche unabhängig von Groß- und Kleinschreibung.
• Um nach mehreren Mustern gleichzeitig zu suchen (wie fail ODER error), kannst du grep -E 'pattern1|pattern2' verwenden.
• Hinweis: Falls du einen Fehler wie „Operation not permitted“ erhältst, versuche den Befehl mit sudo auszuführen, um die notwendigen Berechtigungen zu erhalten.

Beispiele

Nachdem du die Kernel-Meldungen erfolgreich gefiltert hast, sollte deine Datei ~/project/boot_issues.txt relevante Systemmeldungen enthalten:

$ 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

Die Datei sollte Kernel-Meldungen enthalten, die Wörter wie „fail“ oder „error“ (unabhängig von Groß-/Kleinschreibung) enthalten und auf potenzielle Hardware- oder Treiberprobleme während des Systemstarts hinweisen.

Überprüfung der Webserver-Konfigurationsdatei

Es wurden keine kritischen Hardwareprobleme gefunden. Das Problem könnte in der Webserver-Konfiguration liegen. Lass uns die Nginx-Konfigurationsdatei untersuchen, um zu sehen, wie sie eingerichtet ist. Manchmal können Fehlkonfigurationen, wie z. B. zu wenige Arbeitsprozesse (worker processes), Leistungsengpässe verursachen und bei hoher Last zu Anwendungsfehlern führen.

Aufgaben

• Durchsuche die Webserver-Konfigurationsdatei unter ~/project/config/nginx.conf.
• Finde die Zeile, die die Anweisung worker_processes enthält.
• Hänge diese Zeile an die Datei ~/project/error_report.txt an, die du im ersten Schritt erstellt hast.

Anforderungen

• Die Eingabedatei ist ~/project/config/nginx.conf.
• Du musst das Ergebnis an ~/project/error_report.txt anhängen, nicht überschreiben.

Hinweise

• Du kannst für diese Aufgabe erneut grep verwenden.
• Um eine Ausgabe an eine Datei anzuhängen, anstatt sie zu überschreiben, verwende den Operator >>.

Beispiele

Nachdem du die worker_processes-Zeile an deinen bestehenden Fehlerbericht angehängt hast, sollte die Datei ~/project/error_report.txt nun sowohl die ursprünglichen Fehlerzeilen als auch die neue Konfigurationszeile enthalten:

$ 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;

Die Datei sollte insgesamt 3 Zeilen enthalten: 2 ursprüngliche Fehlerzeilen plus 1 neue Zeile mit „worker_processes 4;“.

Vergleich von Staging- und Produktions-Konfigurationsdateien

Eine häufige Quelle für Produktionsprobleme ist eine Diskrepanz zwischen Staging- und Produktionsumgebungen. Ein Feature funktioniert in der Staging-Umgebung möglicherweise einwandfrei, schlägt aber in der Produktion aufgrund eines kleinen Konfigurationsunterschieds fehl. Lass uns die Konfigurationsdateien der Anwendung aus beiden Umgebungen vergleichen, um Unterschiede zu finden.

Aufgaben

• Vergleiche die Staging-Konfigurationsdatei ~/project/config/staging/app.conf mit der Produktions-Konfigurationsdatei ~/project/config/production/app.conf.
• Speichere die Unterschiede in einer neuen Datei namens ~/project/config_diff.txt.

Anforderungen

• Du musst den Befehl diff verwenden.
• Die Ausgabe, die die Unterschiede zeigt, muss in ~/project/config_diff.txt gespeichert werden.

Hinweise

• Der Befehl diff wurde speziell entwickelt, um zwei Dateien Zeile für Zeile zu vergleichen.
• Die grundlegende Syntax lautet diff datei1 datei2, wobei angezeigt wird, welche Änderungen an datei1 vorgenommen werden müssen, damit sie identisch mit datei2 ist.
• Die Reihenfolge der Dateien ist wichtig! diff A B und diff B A zeigen unterschiedliche Ausgaben.
• Du kannst die Ausgabe von diff genauso in eine Datei umleiten wie bei grep.

Beispiele

Nach dem Vergleich der Staging- und Produktions-Konfigurationsdateien sollte deine Datei ~/project/config_diff.txt die Unterschiede zwischen den beiden Umgebungen zeigen:

$ 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

Die diff-Ausgabe zeigt, welche Änderungen an der Staging-Konfigurationsdatei vorgenommen werden müssten, damit sie mit der Produktions-Konfigurationsdatei übereinstimmt. Zeilen, die mit < beginnen, zeigen den Inhalt der Staging-Datei, während Zeilen, die mit > beginnen, den Inhalt der Produktions-Datei zeigen. Dies enthüllt, dass die Produktionsumgebung im Vergleich zur Staging-Umgebung unterschiedliche Datenbank-URLs, API-Schlüssel, Feature-Flags und Timeout-Werte verwendet.

Überprüfung der Verzeichniskonsistenz zwischen Servern

Der Konfigurationsunterschied ist ein starker Hinweis! Es scheint, als ob auf dem Produktionsserver auch einige kritische Dateien fehlen könnten, die auf dem Staging-Server vorhanden sind. Dies könnte auf ein fehlgeschlagenes Deployment zurückzuführen sein. Lass uns dies simulieren, indem wir zwei Verzeichnisse vergleichen, die die Dateistrukturen von zwei verschiedenen Servern darstellen.

Aufgaben

• Du hast zwei Verzeichnisse: /home/labex/project/server1_files (repräsentiert den Staging-Server) und /home/labex/project/server2_files (repräsentiert den Produktionsserver).
• Vergleiche diese beiden Verzeichnisse, um herauszufinden, welche Dateien nur in server1_files vorhanden sind.
• Speichere die vollständige Vergleichsausgabe in einer Datei namens /home/labex/project/missing_files.txt.

Anforderungen

• Du musst den Befehl diff verwenden, um die beiden Verzeichnisse zu vergleichen.
• Die Ausgabe muss in /home/labex/project/missing_files.txt gespeichert werden.

Hinweise

• Der Befehl diff kann auch Verzeichnisse vergleichen, wenn du Verzeichnispfade anstelle von Dateipfaden angibst.
• Die Verwendung der Option -r oder --recursive mit diff ist eine bewährte Methode zum Vergleichen von Verzeichnissen, da sie alle darin enthaltenen Dateien vergleicht.
• Das Ausgabeformat von diff bei Verzeichnissen gibt explizit an, welche Dateien sich „Only in“ (nur in) einem bestimmten Verzeichnis befinden.
• Genau wie bei Dateien ist die Reihenfolge beim Vergleichen von Verzeichnissen wichtig. diff dir1 dir2 zeigt, was in dir1, aber nicht in dir2 ist, während diff dir2 dir1 das Gegenteil zeigt.

Beispiele

Nach dem Vergleich der beiden Serververzeichnisse sollte deine Datei /home/labex/project/missing_files.txt zeigen, welche Dateien auf dem Produktionsserver fehlen:

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

Diese Ausgabe zeigt, dass asset2.js im ersten Verzeichnis (server1_files, repräsentiert den Staging-Server) existiert, aber im zweiten Verzeichnis (server2_files, repräsentiert den Produktionsserver) fehlt. Durch den Vergleich von Staging zuerst und Produktion danach können wir leicht Dateien identifizieren, die in der Produktion fehlen, was einige der Anwendungsfehler erklären könnte.

Zusammenfassung

Hervorragende Detektivarbeit! Du hast die Grundursachen für die kritischen Fehler von Projekt Phoenix erfolgreich identifiziert und Sarah Chen sowie dem Entwicklungsteam verwertbare Informationen zur Lösung der Probleme geliefert.

Durch deine systematische Untersuchung hast du wichtige Befehle zur Fehlerbehebung gemeistert:

• grep: Zum Filtern von Logdateien und Extrahieren kritischer Fehlerinformationen.
• dmesg: Zur Untersuchung von Hardware- und Kernel-Problemen auf Systemebene.
• diff: Zum Vergleichen von Konfigurationsdateien und Identifizieren von Diskrepanzen zwischen Umgebungen.
• Befehlspipelines und Umleitungen: Zur effizienten Verarbeitung und Dokumentation deiner Ergebnisse.

Deine methodische Herangehensweise an die Log-Analyse hat Projekt Phoenix vor einem potenziell katastrophalen Ausfall bewahrt. Das Entwicklungsteam hat nun eine klare Richtung, um die von dir entdeckten Konfigurationsunterschiede und fehlenden Deployment-Dateien zu beheben.

Sarah Chen war von deinen Ermittlungsfähigkeiten so beeindruckt, dass sie dich für eine Sicherheitsrolle empfiehlt. Morgen wirst du in die Rolle des „Festungswächters“ schlüpfen, um die Infrastruktur von Projekt Phoenix zu sichern und sie vor zukünftigen Bedrohungen zu schützen!