NGINX Access Logs und Error Logs

Protokolle sind sehr nützlich, um die Aktivitäten einer Anwendung zu überwachen, abgesehen davon, dass sie Ihnen wertvolle Informationen liefern, während Sie Probleme beheben. Wie jede andere Anwendung zeichnet auch NGINX Ereignisse wie Besucher Ihrer Website, aufgetretene Probleme und mehr in Protokolldateien auf. Diese Informationen ermöglichen es Ihnen, vorbeugende Maßnahmen zu ergreifen, falls Sie ernsthafte Diskrepanzen in den Protokollereignissen bemerken. Dieser Artikel wird Sie detailliert anleiten, wie Sie das NGINX-Logging konfigurieren, damit Sie einen besseren Einblick in seine Aktivitäten erhalten.

Logs in NGINX

Standardmäßig schreibt NGINX seine Ereignisse in zwei Arten von Protokollen – das Fehlerprotokoll und das Zugriffsprotokoll. In den meisten der beliebten Linux-Distributionen wie Ubuntu, CentOS oder Debian können sowohl das Zugriffs- als auch das Fehlerprotokoll in /var/log/nginx gefunden werden, vorausgesetzt, Sie haben die Zugriffs- und Fehlerprotokolle bereits in der Kernkonfigurationsdatei von NGINX aktiviert. Lassen Sie uns mehr über das NGINX-Zugriffsprotokoll, das Fehlerprotokoll und wie Sie sie aktivieren können, erfahren, falls Sie dies noch nicht getan haben.

Was ist NGINX access log?

NGINX protokolliert die Aktivitäten aller Besucher Ihrer Website in den Zugriffsprotokollen. Hier können Sie finden, welche Dateien zugegriffen wurden, wie NGINX auf eine Anfrage reagiert hat, welchen Browser ein Client verwendet, die IP-Adresse von Clients und mehr. Es ist möglich, die Informationen aus dem Zugriffsprotokoll zu verwenden, um den Verkehr zu analysieren und die Nutzung der Websites im Laufe der Zeit zu finden. Weiterhin kann man durch eine angemessene Überwachung der Zugriffsprotokolle herausfinden, ob ein Benutzer einige ungewöhnliche Anfragen sendet, um Schwachstellen in der eingesetzten Webanwendung zu finden.

Was ist NGINX error log?

Andererseits wird NGINX das Ereignis im Fehlerprotokoll aufzeichnen, wenn es auf irgendwelche Probleme stößt. Dies kann passieren, wenn es einen Fehler in der Konfigurationsdatei gibt. Daher sollten Sie die Fehlerprotokolle überprüfen, wenn NGINX nicht starten kann oder plötzlich gestoppt hat, um mehr Details zu finden. Sie können auch einige Warnungen im Fehlerprotokoll finden, aber das bedeutet nicht, dass ein Problem aufgetreten ist, aber das Ereignis könnte in naher Zukunft ein ernstes Problem darstellen.

Wie aktiviert man NGINX access log?

Generell kann das Zugriffsprotokoll mit der Direktive access_log entweder im http- oder im Serverbereich aktiviert werden. Das erste Argument log_file ist obligatorisch, während das zweite Argument log_format optional ist. Wenn Sie kein Format angeben, werden die Protokolle im Standard-Combined-Format geschrieben.

access_log log_file log_format;

Das Zugriffsprotokoll ist standardmäßig im http-Kontext der Kernkonfigurationsdatei von NGINX aktiviert. Das bedeutet, dass das Zugriffsprotokoll aller virtuellen Hosts in derselben Datei aufgezeichnet wird.

http {
      ...
      access_log  /var/log/nginx/access.log;
      ...
}

Es ist immer besser, die Zugriffsprotokolle aller virtuellen Hosts zu trennen, indem sie in einer separaten Datei aufgezeichnet werden. Dazu müssen Sie die Direktive access_log, die im http-Abschnitt definiert ist, mit einer weiteren access_log-Direktive im Serverkontext überschreiben.

http {
      ...
      access_log  /var/log/nginx/access.log;

         server {
                  listen 80; 
                  server_name domain1.com
                  access_log  /var/log/nginx/domain1.access.log;
                  ...
                  ...
                }
}

Laden Sie NGINX neu, um die neuen Einstellungen anzuwenden. Um die Zugriffsprotokolle für die Domain domain1.com in der Datei /var/log/nginx/domain1.access.log anzusehen, verwenden Sie den folgenden tail-Befehl im Terminal.

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

Eigene Formate in Access Log anwenden

Das Standardprotokollformat, das verwendet wird, um ein Ereignis im Zugriffsprotokoll aufzuzeichnen, ist das Combined Log Format. Sie können das Standardverhalten überschreiben, indem Sie Ihr eigenes benutzerdefiniertes Protokollformat erstellen und dann den Namen des benutzerdefinierten Formats in der Direktive access_log angeben. Das folgende Beispiel definiert ein benutzerdefiniertes Protokollformat, indem es das vordefinierte Combined Format mit dem Wert des Gzip-Kompressionsverhältnisses der Antwort erweitert. Das Format wird dann angewendet, indem das Protokollformat mit der Direktive access_log angegeben wird.

http {
            log_format custom '$remote_addr - $remote_user [$time_local] '
                           '"$request" $status $body_bytes_sent '
                           '"$http_referer" "$http_user_agent" "$gzip_ratio"';

            server {
                    gzip on;
                    ...
                    access_log /var/log/nginx/domain1.access.log custom;
                    ...
            }
}

Sobald Sie das oben genannte Protokollformat in Ihrer Umgebung angewendet haben, laden Sie NGINX neu. Verfolgen Sie nun das Zugriffsprotokoll, um das Gzip-Verhältnis am Ende des Protokollereignisses zu finden.

# tail -f /var/log/nginx/domain1.access.log
47.29.201.179 - - [28/Feb/2019:13:17:10 +0000] "GET /?p=1 HTTP/2.0" 200 5316 "https://domain1.com/?p=1" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.119 Safari/537.36" "2.75"

Wie aktiviert man NGINX error log?

Die Direktive error_log richtet das Fehlerlogging in eine Datei oder stderr oder syslog ein, indem das minimale Schweregradniveau der zu protokollierenden Fehlermeldungen angegeben wird. Die Syntax der error_log-Direktive ist:

error_log log_file log_level;

Das erste Argument log_file definiert den Pfad der Protokolldatei und das zweite Argument log_level definiert das Schweregradniveau des zu protokollierenden Logereignisses. Wenn Sie das log_level nicht angeben, werden standardmäßig nur Logereignisse mit einem Schweregradniveau von Fehler aufgezeichnet. Beispielsweise setzt das folgende Beispiel das Schweregradniveau der zu protokollierenden Fehlermeldungen auf crit. Weiterhin impliziert die error_log-Direktive im http-Kontext, dass das Fehlerprotokoll für alle virtuellen Hosts in einer einzigen Datei verfügbar sein wird.

http {
       	  ...
	  error_log  /var/log/nginx/error_log  crit;
	  ...
}

Es ist auch möglich, Fehlerprotokolle für alle virtuellen Hosts separat aufzuzeichnen, indem die error_log-Direktive im server-Kontext überschrieben wird. Das folgende Beispiel macht genau das, indem die error_log-Direktive im server-Kontext überschrieben wird.

http {
       ...
       ...
       error_log  /var/log/nginx/error_log;
       server {
	        	listen 80;
		        server_name domain1.com;
       		        error_log  /var/log/nginx/domain1.error_log  warn;
                        ...
	   }
       server {
	        	listen 80;
		        server_name domain2.com;
      		        error_log  /var/log/nginx/domain2.error_log  debug;
                        ...
	   }
}

Alle oben beschriebenen Beispiele zeichnen die Logereignisse in eine Datei auf. Sie können auch die error_log-Direktive konfigurieren, um die Logereignisse an einen Syslog-Server zu senden. Die folgende error_log-Direktive sendet die Fehlerprotokolle an einen Syslog-Server mit einer IP-Adresse von 192.168.10.11 im Debug-Format.

error_log syslog:server=192.168.10.11 debug;

In einigen Situationen möchten Sie möglicherweise das Fehlerprotokoll deaktivieren. Um dies zu tun, setzen Sie den Dateinamen des Protokolls auf /dev/null.

error_log /dev/null;

NGINX Fehlerprotokoll Schweregradstufen

Es gibt viele Arten von Schweregradstufen, die mit einem Logereignis verbunden sind und unterschiedliche Prioritäten haben. Alle Schweregradstufen sind unten aufgelistet. In den folgenden Schweregradstufen hat debug die höchste Priorität und umfasst auch die restlichen Stufen. Wenn Sie beispielsweise error als Schweregradstufe angeben, werden auch Logereignisse erfasst, die als crit, alert und emergency gekennzeichnet sind.

• emerg: Notfallmeldungen, wenn Ihr System instabil sein könnte.
• alert: Alarmmeldungen bei ernsthaften Problemen.
• crit: Kritische Probleme, die sofort behoben werden müssen.
• error: Ein Fehler ist aufgetreten. Etwas ist schiefgegangen bei der Verarbeitung einer Seite.
• warn: Eine Warnmeldung, die Sie beachten sollten.
• notice: Eine einfache Protokollnotiz, die Sie ignorieren können.
• info: Nur eine Informationsmeldung, die Sie wissen möchten.
• debug: Debugging-Informationen, die verwendet werden, um den Ort des Fehlers zu bestimmen.

Zusammenfassung

Die Zugriffs- und Fehlerprotokolle in NGINX halten nicht nur ein Auge auf die Aktivität der Benutzer, sondern sparen auch Zeit und Mühe im Debugging-Prozess. Darüber hinaus können Sie das Zugriffsprotokoll anpassen, wenn Sie mehr Informationen benötigen. Es ist immer besser, Zugriffs- und Fehlerprotokolle zu aktivieren, da diese beiden Dateien alle Hinweise für eine bessere Wartung des NGINX-Servers enthalten.