Nginx-Log-Überwachung: Wichtige Befehle zur Analyse von Web-Traffic und Fehlern

Die Nginx-Log-Überwachung ist oft der schnellste Weg, um die Frage zu beantworten, die Menschen während eines Vorfalls stellen: "Was passiert eigentlich gerade?" Metriken können Ihnen sagen, dass 5xx-Fehler gestiegen sind. Logs können den Pfad, Upstream, Statuscode, Client-IP und Zeitdetails für die fehlgeschlagenen Anfragen anzeigen.

Die hier verwendeten Befehle nutzen gewöhnliche Linux-Werkzeuge: tail, grep, awk, sort, uniq, less und ihre Varianten für komprimierte Logs. Sie ersetzen keine echte Log-Plattform, sind aber genau das, was Sie brauchen, wenn Sie SSH-Zugriff auf einen Server haben und eine schnelle, vertretbare Antwort benötigen.

Verständnis der Nginx-Log-Typen

Nginx generiert typischerweise zwei Haupttypen von Logs, die in der nginx.conf oder zugehörigen Konfigurationsdateien konfiguriert sind:

Access-Logs (access.log): Zeichnet jede vom Server verarbeitete Anfrage auf. Dieses Log ist entscheidend für das Verständnis des Benutzerverhaltens, des Verkehrsvolumens, der geografischen Verteilung und der Antwortzeiten. Standardmäßig umfassen Felder oft IP-Adresse, Anfragemethode, URI, HTTP-Statuscode, Anfragegröße und User-Agent.
Error-Logs (error.log): Zeichnet Diagnoseinformationen, Warnungen und kritische Fehler auf, die von Nginx selbst festgestellt wurden (z.B. Konfigurationsprobleme, Upstream-Timeouts, Ressourcenerschöpfung). Dieses Log ist die erste Anlaufstelle zur Fehlerbehebung bei serverseitigen Ausfällen.

Standard-Log-Speicherorte

Obwohl die Speicherorte angepasst werden können, befinden sich Nginx-Logs typischerweise in den folgenden Verzeichnissen auf den meisten Distributionen:

Distributionstyp	Standard-Log-Pfad
Debian/Ubuntu	`/var/log/nginx/`
RHEL/CentOS	`/var/log/nginx/`
Benutzerdefinierte Installation (Quelle)	Variiert, überprüfen Sie `nginx.conf`

Wir verwenden /var/log/nginx/access.log und /var/log/nginx/error.log als primäre Beispiele.

1. Echtzeit-Überwachung mit `tail`

Der Befehl tail ist unerlässlich, um die aktuelle Serveraktivität in Echtzeit zu beobachten. Das Flag -f (follow) hält die Ausgabe in Echtzeit am Laufen.

Überwachung des Live-Zugriffsverkehrs

Um neue Anfragen an den Server zu sehen, verwenden Sie tail -f auf dem Access-Log:

tail -f /var/log/nginx/access.log

Gleichzeitige Überwachung von Fehlern

Es ist oft hilfreich, Fehler zu überwachen, während Sie Konfigurationsänderungen oder Bereitstellungen testen. Sie können dies tun, indem Sie zwei separate Terminal-Sitzungen ausführen oder ein Tool wie multitail (falls installiert) verwenden:

tail -f /var/log/nginx/error.log

Tipp: Wenn Sie die letzten 100 Zeilen sehen möchten, bevor Sie neuen Einträgen folgen, verwenden Sie tail -n 100 -f /var/log/nginx/access.log.

2. Suchen und Filtern mit `grep`

grep (Global Regular Expression Print) ist das Arbeitstier zum Finden bestimmter Zeilen in Logdateien. Es ermöglicht Ihnen, Logs schnell nach Statuscodes, IP-Adressen, Methoden und mehr zu filtern.

Finden bestimmter HTTP-Statuscodes

Bei der Fehlerbehebung ist es entscheidend, schnell alle Anfragen zu identifizieren, die zu einem bestimmten Fehler geführt haben. Wir verwenden Leerzeichen um den Statuscode, um Fehlalarme durch ähnliche Zahlen zu vermeiden (z.B. Vermeidung der Übereinstimmung von 200 in 2000).

Finden aller 404 (Nicht gefunden)-Fehler:

grep " 404 " /var/log/nginx/access.log

Finden aller 5xx-Serverfehler:

grep -E " 50[0-9] " /var/log/nginx/access.log

Filtern nach Anfragepfad oder IP-Adresse

Um alle Anfragen eines bestimmten Client-IP oder alle Versuche, auf einen bestimmten Pfad zuzugreifen (z.B. /admin), zu sehen:

# Nach Client-IP-Adresse filtern
grep "192.168.1.10" /var/log/nginx/access.log

# Nach Versuchen, auf eine bestimmte URL zuzugreifen, filtern
grep "/wp-login.php" /var/log/nginx/access.log

Echtzeit-Filterung

Sie können die Ausgabe von tail -f in grep weiterleiten, um nur bestimmte Ereignisse zu überwachen, während sie auftreten:

# Live-Feed nur für 5xx-Fehler
tail -f /var/log/nginx/access.log | grep -E " 50[0-9] "

3. Umgang mit großen und rotierten Logs

Logdateien können schnell massiv werden. Nginx verwendet typischerweise Log-Rotationsdienstprogramme (logrotate), um alte Logs mit gzip zu komprimieren.

Überprüfen großer Dateien mit `less`

Anstatt die gesamte Datei in den Speicher zu laden (was eine Terminal-Sitzung zum Absturz bringen kann), verwenden Sie less, um sie seitenweise durchzugehen. less ermöglicht auch die Rückwärtsnavigation und effiziente Suche.

less /var/log/nginx/access.log
# Innerhalb von less drücken Sie 'G', um zum Ende zu gelangen, 'g', um zum Anfang zu gelangen, und '/', um zu suchen.

Durchsuchen komprimierter Logs mit `zgrep`

Um rotierte Logs (.gz-Dateien) zu durchsuchen, ohne sie manuell zu dekomprimieren, verwenden Sie die z-Varianten der üblichen Befehle (zcat, zgrep).

# Suche nach einem 403-Fehler in einer komprimierten Logdatei
zgrep " 403 " /var/log/nginx/access.log.1.gz

4. Strukturierte Analyse mit `awk`, `cut` und `sort`

Nginx-Logs, insbesondere solche im standardmäßigen kombinierten Format, sind durch Leerzeichen strukturiert. Diese Struktur ermöglicht es Werkzeugen wie awk und cut, bestimmte Datenfelder für statistische Analysen zu extrahieren.

Im standardmäßigen kombinierten Format sind die wichtigsten Felder typischerweise:

$1: Remote-IP-Adresse
$7: Angeforderte URI
$9: HTTP-Statuscode
$10: Gesendete Bytes
$12: HTTP-Referer
$14: User-Agent

Finden der am häufigsten angeforderten Seiten

Diese Pipeline verwendet awk zum Extrahieren der URI ($7), sort zum Gruppieren identischer Einträge, uniq -c zum Zählen und sort -nr zum numerischen Auflisten in umgekehrter Reihenfolge (höchste Anzahl zuerst).

awk '{print $7}' /var/log/nginx/access.log | \
sort | uniq -c | sort -nr | head -10

Zählen von Statuscodes

Um schnell eine Aufschlüsselung aller im Log aufgezeichneten Statuscodes zu erhalten:

awk '{print $9}' /var/log/nginx/access.log | \
sort | uniq -c | sort -nr

Beispielausgabe:

Identifizieren von Anfragen mit hoher Latenz (falls protokolliert)

Wenn Ihre Nginx-Konfiguration die Upstream-Antwortzeit ($upstream_response_time) protokolliert, können Sie awk verwenden, um langsame Anfragen (z.B. langsamer als 1 Sekunde) zu finden.

Hinweis: Dies setzt voraus, dass die Antwortzeit das 12. Feld ($12) ist. Überprüfen Sie Ihre log_format-Konfiguration, bevor Sie der Feldnummer vertrauen.

awk '($12 > 1.0) {print $12, $7}' /var/log/nginx/access.log | sort -nr

Best Practices für die Log-Analyse

Verwenden Sie `grep -v` zum Ausschließen

Manchmal müssen Sie häufiges Rauschen herausfiltern, wie z.B. Health Checks oder bekannte harmlose Bots. Das Flag -v in grep kehrt die Übereinstimmung um und zeigt Zeilen an, die nicht dem Muster entsprechen.

# Access-Logs anzeigen, alle erfolgreichen 200-Antworten ausschließen
grep -v " 200 " /var/log/nginx/access.log

# Logs anzeigen, bekannte Googlebot-User-Agents ausschließen
grep -v "Googlebot" /var/log/nginx/access.log

Vergleichen Sie Access-Logs mit Error-Logs

Wenn Sie einen Anstieg der 502- oder 504-Antworten sehen, überprüfen Sie das Error-Log für denselben Zeitraum. Access-Logs zeigen das clientseitige Ergebnis. Error-Logs erklären oft den proxyscitigen Grund:

grep "upstream" /var/log/nginx/error.log | tail -50
grep -E "connect\\(\\) failed|upstream timed out|no live upstreams" /var/log/nginx/error.log

Zum Beispiel deutet ein 502 im Access-Log plus connect() failed (111: Connection refused) im Error-Log auf einen Upstream-Dienst hin, der keine Verbindungen akzeptiert. Ein 504 plus upstream timed out deutet auf einen langsamen Upstream oder eine Timeout-Einstellung hin, die für diesen Anforderungspfad zu niedrig ist.

Seien Sie vorsichtig mit Feldnummern

Viele Beispiele gehen von Nginxs kombiniertem Log-Format aus. Produktionskonfigurationen fügen oft $request_time, $upstream_response_time, $host, $request_id oder weitergeleitete IP-Felder hinzu. Bevor Sie einen awk '{print $9}'-Befehl in einer ernsthaften Untersuchung verwenden, überprüfen Sie das aktive Format:

nginx -T 2>/dev/null | grep -A3 "log_format"

Wenn Ihr Log-Format die Anfrage in Anführungszeichen setzt, funktionieren leerzeichengetrennte awk-Felder dennoch für einfache Überprüfungen, aber sie sind leicht falsch zu interpretieren für User-Agents und Referrer, da diese Werte Leerzeichen enthalten. Für tiefere Analysen leiten Sie Logs an einen Parser weiter oder verwenden Sie ein Format wie JSON-Escaping in einem dedizierten Access-Log.

Sicherer Umgang

Nginx-Access-Logs enthalten sensible Daten wie IP-Adressen und möglicherweise Anforderungsparameter. Stellen Sie sicher, dass Sie bei der Übertragung von Logs zur Analyse sichere Protokolle (SCP/SFTP) verwenden und den Zugriff auf das Log-Verzeichnis auf autorisiertes Personal beschränken (typischerweise der root- oder syslog-Benutzer).

# Berechtigungen überprüfen
ls -l /var/log/nginx/

Ein praktischer Arbeitsablauf

Beginnen Sie mit dem Symptom. Wenn Benutzer Fehler melden, zählen Sie Statuscodes und isolieren Sie die fehlschlagenden Pfade. Wenn der Server langsam erscheint, suchen Sie nach Anforderungszeitfeldern oder fügen Sie sie dem Log-Format vor dem nächsten Vorfall hinzu. Wenn eine IP laut ist, zählen Sie die häufigsten Client-Adressen:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

Gehen Sie dann vom Breiten zum Engen: Statuscode, Pfad, Upstream-Fehler, Zeitfenster, Client-Muster. Notieren Sie die genauen Befehle, die Sie in den Vorfallsnotizen verwendet haben. Sie erleichtern die nächste Überprüfung erheblich und helfen einem anderen Ingenieur, Ihre Ergebnisse zu reproduzieren, anstatt sich auf eine vage Erinnerung zu verlassen, wie die Logs "aussahen".

Nginx-Logs sind Klartext, was eine Stärke ist, wenn die richtigen Werkzeuge zur Hand sind. Kennen Sie Ihr Log-Format, vertrauen Sie nicht blind kopierten Feldnummern und kombinieren Sie Access-Log-Muster mit Error-Log-Nachrichten, bevor Sie entscheiden, was kaputt ist.