Der Log-Ermittler

Einführung

Es ist Tag 3 bei der LabEx Corporation, und im Projekt Phoenix ist eine Katastrophe eingetreten! Als Sie im Büro ankommen, befinden sich Sarah Chen und das Entwicklungsteam in einer Krisensitzung. Die Anwendung, bei deren Organisation Sie gestern geholfen haben, ist während ihrer ersten großen Testphase auf kritische Fehler gestoßen.

Notfallmeldungen überfluten die Überwachungssysteme, Benutzer melden Ausfälle der Anwendung, und die Deployment-Pipeline ist vollständig zum Stillstand gekommen. Sarah sieht Sie verzweifelt an: Der erfahrene DevOps-Engineer ist krank, und der Projekttermin rückt immer näher.

„Wir brauchen dafür unseren besten Ermittler“, sagt Sarah und reicht Ihnen den Incident-Bericht. „Ihre systematische Vorgehensweise beim Organisieren unserer Dateien war genau das, was wir gebraucht haben. Jetzt müssen Sie mit derselben methodischen Denkweise dieses Rätsel lösen.“

Ihre Aufgabe besteht darin, den Server des Projekts Phoenix gründlich zu untersuchen, Logs und Konfigurationsdateien zu analysieren und die Ursache dieser Fehler aufzudecken. Sie verwenden fortgeschrittene Linux-Kommandozeilenwerkzeuge, setzen die Hinweise zusammen und stellen die Stabilität der Anwendung wieder her, an deren Entwicklung Ihr Team so hart gearbeitet hat. Die Zukunft des Projekts Phoenix – und möglicherweise auch Ihre Karriere bei TechNova – hängt von Ihren Ermittlungsfähigkeiten ab!

Inhalte der Anwendungs-Logdatei überprüfen

Als Erstes prüfen Sie als Ermittler die Anwendungs-Logdatei des Projekts Phoenix. Die Anwendung schreibt ihre Logs nach ~/project/logs/app.log. Eine Flut von Meldungen kann schnell unübersichtlich werden. Deshalb müssen Sie die kritischen Fehlermeldungen zügig finden, um zu verstehen, was mit dem System nicht stimmt, das Sie gestern organisiert haben.

Aufgaben

• Filtern Sie die Datei ~/project/logs/app.log, um alle Zeilen zu finden, die das Wort ERROR enthalten.
• Speichern Sie die gefilterten Zeilen in einer neuen Datei mit dem Namen ~/project/error_report.txt.

Anforderungen

• Sie müssen ein Kommandozeilenwerkzeug verwenden, um die Datei zu durchsuchen.
• Die Eingabedatei für die Suche ist ~/project/logs/app.log.
• Die Ausgabe muss in einer Datei namens ~/project/error_report.txt im Verzeichnis ~/project gespeichert werden.
• Die Ausgabedatei darf nur die Zeilen enthalten, in denen das Wort ERROR vorkommt.

Hinweise

• Der Befehl grep eignet sich hervorragend, um nach Mustern in Textdateien zu suchen.
• Um die Ausgabe eines Befehls in einer Datei zu speichern, können Sie den Umleitungsoperator > verwenden. Dadurch wird die Datei angelegt, falls sie noch nicht existiert, oder überschrieben, falls sie bereits vorhanden ist.

Beispiele

Nach dem erfolgreichen Filtern der Logdatei sollte Ihre Datei ~/project/error_report.txt nur 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. Beide beginnen mit Zeitstempeln und enthalten das Wort „ERROR“.

Systemweite Bootmeldungen untersuchen

Die Anwendungsfehler könnten ein Symptom für ein tiefer liegendes Hardware- oder Kernelproblem sein. Eine gute Anlaufstelle für solche Probleme ist der Kernel-Ringpuffer. Er enthält Meldungen aus dem Bootvorgang des Systems und von Treiberoperationen.

Aufgaben

• Untersuchen Sie die Kernelmeldungen des Systems auf Zeilen, die sich auf fail oder error beziehen.
• Speichern Sie diese Ergebnisse in einer Datei namens ~/project/boot_issues.txt.

Anforderungen

• Sie müssen den Befehl dmesg verwenden, um die Kernelmeldungen anzuzeigen.
• Ihre Suche nach fail oder error muss unabhängig von der Groß- und Kleinschreibung erfolgen.
• Die Ergebnisse müssen in einer Datei namens ~/project/boot_issues.txt gespeichert werden.
• Hinweis: Für den Zugriff auf Kernelmeldungen benötigen Sie möglicherweise Administratorrechte (sudo).

Hinweise

• Der Befehl dmesg zeigt Kernelmeldungen an. Sie können seine Ausgabe per Pipe an einen anderen Befehl zur Filterung weiterleiten.
• Der Pipe-Operator | sendet die Ausgabe eines Befehls an die Eingabe eines anderen Befehls.
• Die Option -i des Befehls grep macht die Suche unabhängig von der Groß- und Kleinschreibung.
• Um gleichzeitig nach mehreren Mustern zu suchen, etwa nach fail ODER error, können Sie grep -E 'pattern1|pattern2' verwenden.
• Hinweis: Wenn der Fehler „Operation not permitted“ auftritt, versuchen Sie, den Befehl mit sudo auszuführen, um die erforderlichen Berechtigungen zu erhalten.

Beispiele

Nach dem erfolgreichen Filtern der Kernelmeldungen sollte Ihre 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 Kernelmeldungen enthalten, in denen Wörter wie „fail“ oder „error“ vorkommen, unabhängig von der Groß- und Kleinschreibung. Dies weist auf mögliche Hardware- oder Treiberprobleme während des Systemstarts hin.

Die Konfigurationsdatei des Webservers untersuchen

Es wurden keine kritischen Hardwareprobleme gefunden. Die Ursache könnte in der Webserverkonfiguration liegen. Untersuchen wir die Nginx-Konfigurationsdatei, um zu sehen, wie der Server eingerichtet ist. Fehlkonfigurationen, beispielsweise zu wenige Worker-Prozesse, können zu Leistungsengpässen führen und bei hoher Last Anwendungsausfälle verursachen.

Aufgaben

• Durchsuchen Sie die Webserver-Konfigurationsdatei unter ~/project/config/nginx.conf.
• Finden Sie die Zeile mit der Direktive worker_processes.
• Hängen Sie diese Zeile an die Datei ~/project/error_report.txt an, die Sie im ersten Schritt erstellt haben.

Anforderungen

• Die Eingabedatei ist ~/project/config/nginx.conf.
• Sie müssen das Ergebnis an ~/project/error_report.txt anhängen, nicht die Datei überschreiben.

Hinweise

• Sie können auch für diese Aufgabe grep verwenden.
• Um die Ausgabe an eine Datei anzuhängen, statt sie zu überschreiben, verwenden Sie den Operator >>.

Beispiele

Nach dem Anhängen der Zeile zu worker_processes an den vorhandenen Fehlerbericht 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 und 1 neue Zeile mit worker_processes 4;.

Staging- und Produktionskonfiguration vergleichen

Eine häufige Ursache für Probleme in der Produktionsumgebung ist eine Abweichung zwischen Staging- und Produktionsumgebung. Eine Funktion kann in Staging einwandfrei funktionieren, aber in der Produktion aufgrund eines kleinen Konfigurationsunterschieds fehlschlagen. Vergleichen wir die Konfigurationsdateien der Anwendung aus beiden Umgebungen, um Unterschiede zu erkennen.

Aufgaben

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

Anforderungen

• Sie müssen den Befehl diff verwenden.
• Die Ausgabe mit den Unterschieden muss in ~/project/config_diff.txt gespeichert werden.

Hinweise

• Der Befehl diff wurde speziell dafür entwickelt, zwei Dateien zeilenweise zu vergleichen.
• Die grundlegende Syntax lautet diff file1 file2. Dabei zeigt diff, welche Änderungen an file1 erforderlich sind, damit die Datei mit file2 identisch wird.
• Die Reihenfolge der Dateien ist wichtig! diff A B und diff B A erzeugen unterschiedliche Ausgaben.
• Sie können die Ausgabe von diff genauso wie zuvor die Ausgabe von grep in eine Datei umleiten.

Beispiele

Nach dem Vergleich der Staging- und Produktionskonfigurationsdateien sollte Ihre Datei ~/project/config_diff.txt die Unterschiede zwischen den beiden Umgebungen anzeigen:

$ 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 der Produktionskonfigurationsdatei entspricht. Zeilen mit < enthalten Inhalte aus der Staging-Datei, Zeilen mit > Inhalte aus der Produktionsdatei. Dadurch wird sichtbar, dass die Produktionsumgebung andere Datenbank-URLs, API-Schlüssel, Feature-Flags und Timeout-Werte als die Staging-Umgebung verwendet.

Verzeichnisübereinstimmung zwischen Servern überprüfen

Der Konfigurationsunterschied ist ein wichtiger Hinweis! Möglicherweise fehlen auf dem Produktionsserver außerdem kritische Dateien, die auf dem Staging-Server vorhanden sind. Ursache könnte ein fehlgeschlagenes Deployment sein. Simulieren wir dies, indem wir zwei Verzeichnisse vergleichen, die die Dateistrukturen zweier verschiedener Server darstellen.

Aufgaben

• Ihnen stehen zwei Verzeichnisse zur Verfügung: /home/labex/project/server1_files (steht für den Staging-Server) und /home/labex/project/server2_files (steht für den Produktionsserver).
• Vergleichen Sie diese beiden Verzeichnisse, um herauszufinden, welche Dateien nur in server1_files vorhanden sind.
• Speichern Sie die vollständige Vergleichsausgabe in einer Datei namens /home/labex/project/missing_files.txt.

Anforderungen

• Sie müssen 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 Sie Verzeichnispfade statt Dateipfaden angeben.
• Die Option -r oder --recursive von diff eignet sich für Verzeichnisvergleiche, da damit alle enthaltenen Dateien rekursiv verglichen werden.
• Das Ausgabeformat von diff für Verzeichnisse nennt ausdrücklich, welche Dateien „Only in“ einem bestimmten Verzeichnis vorhanden sind.
• Wie bei Dateien ist auch beim Vergleich von Verzeichnissen die Reihenfolge wichtig. diff dir1 dir2 zeigt, was in dir1, aber nicht in dir2 vorhanden ist; diff dir2 dir1 zeigt das Gegenteil.

Beispiele

Nach dem Vergleich der beiden Serververzeichnisse sollte Ihre Datei /home/labex/project/missing_files.txt anzeigen, 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, dem Staging-Server) vorhanden ist, aber im zweiten Verzeichnis (server2_files, dem Produktionsserver) fehlt. Indem Sie zuerst Staging und danach Produktion vergleichen, können Sie leicht Dateien identifizieren, die in der Produktion fehlen und dadurch einige der Anwendungsausfälle erklären könnten.

Zusammenfassung

Hervorragende Ermittlungsarbeit! Sie haben die Hauptursachen für die kritischen Fehler im Projekt Phoenix erfolgreich identifiziert und Sarah Chen sowie dem Entwicklungsteam verwertbare Informationen zur Behebung der Probleme geliefert.

Durch Ihre systematische Untersuchung haben Sie wichtige Befehle zur Fehleranalyse beherrscht:

• grep: Zum Filtern von Logdateien und Extrahieren wichtiger Fehlerinformationen.
• dmesg: Zum Untersuchen von Hardware- und Kernelproblemen auf Systemebene.
• diff: Zum Vergleichen von Konfigurationsdateien und Erkennen von Abweichungen zwischen Umgebungen.
• Befehlspipelines und Umleitungen: Zum effizienten Verarbeiten und Dokumentieren Ihrer Ergebnisse.

Ihre methodische Loganalyse hat das Projekt Phoenix vor einem möglicherweise katastrophalen Ausfall bewahrt. Das Entwicklungsteam weiß nun genau, wie die entdeckten Konfigurationsabweichungen und fehlenden Deployment-Dateien behoben werden können.

Sarah Chen war von Ihren Ermittlungsfähigkeiten so beeindruckt, dass sie Sie für eine Stelle im Bereich Security empfiehlt. Morgen schlüpfen Sie in die Rolle des Fortress Guardian, um die Infrastruktur des Projekts Phoenix abzusichern und vor zukünftigen Bedrohungen zu schützen!