– NGINX ist eine leistungsstarke und zuverlässige web-server in der Lage Umgang mit riesigen Datenmengen für das internet der meistgenutzten websites. Bei der Fehlerbehebung benötigen Sie eine Möglichkeit, den Datenverkehr zu verstehen, und NGINX bietet flexible Protokollierungsfunktionen, um wertvolle Details zu erfassen und das Verhalten Ihres Webservers zu verstehen.
NGINX bietet zwei verschiedene Dateien zum Protokollieren wertvoller Webserverdaten an., Diese beiden Dateien sind error_log und access_log. access_log wird zum Speichern von Informationen über Webclient-Anforderungen verwendet und error_log speichert andere unerwartete oder informative Nachrichten.
Konfigurieren von access_log
Die access_log-Datei erfasst alle Clientanforderungen unmittelbar nach der Verarbeitung der Anforderung und bietet eine großartige Möglichkeit, zu protokollieren, welche Seiten Benutzer von Ihrem Webserver anfordern., Sie können wählen, wohin die acess_log-Daten geschrieben werden, indem Sie die folgende Syntax der Konfigurationsdatei verwenden:
access_log path ] ];access_log off;Mit Specifyingformat können Sie ein benutzerdefiniertes Format in Ihren Protokollen verwenden, indem Sie Variablen wie die Anzahl der Bytessent an den Client ($bytes_sent) oder die Anforderungslänge ($request_length).
Normalerweise protokolliert NGINX jede Transaktion, die itprocesses in access_log. Der Parameter if=condition bietet eine leistungsfähige Möglichkeit, eine bedingte Protokollierung durchzuführen, sodass Protokollzugriffsprotokollmeldungen nur dann protokolliert werden, wenn eine Bedingung erfüllt ist., Wenn Sie beispielsweise nur Anforderungen aufzeichnen möchten, die einen HTTP 404-Statuscode zurückgeben, können Sie folgendes Snippet verwenden:
map $status $should_log {404 1;default 0;}access_log logs/access.log combined if=$should_log;Mit dieser Änderung werden alle Anforderungen erfolgreich abgeschlossen (2xx), auf eine andere Seite umgeleitet (3xx) oder ein Servererror (5xx) wird nicht in Protokollen/Zugriff protokolliert.log-nur Log-Fehler werden protokolliert.
Wenn Sie mehr als einen virtuellen host ormultiple http, server oder Speicherort directivesthensometimes es praktisch zu werden ableto deaktivieren Sie die Protokollierung für die aktuelle Richtlinie Ebene, und die spezielle-off-Wert wurde für diesen Zweck geschaffen.,Die folgende Konfigurationszeile zeigt, wie Sie verhindern können, dass NGINX Zugriffsinformationen auf ein beliebiges access_log-Ziel auf der aktuellen Ebene schreibt:
access_log off;Eine ausführlichere Erklärung der Konfigurationsoptionen finden Sie in der NGINX access_log-Dokumentation.
NGINX-Protokoll Schweregrade
NGINX unterstützt eine breite Palette von Schweregraden, um es einfach zu machen, die Informationen zu protokollieren, die Ihnen wichtig sind. Jede dieser Ebenen kann mit der Richtlinie error_log verwendet werdenum die Mindeststufe festzulegen, auf der Nachrichten protokolliert werden., Hier sind die supportedlevels in der niedrigsten bis höchsten Reihenfolge, zusammen mit einer Anleitung, wie sie verwendet werden:
- Debug – Debugging-Nachrichten, die die meiste Zeit nicht nützlich sind.
- Info-Informative Nachrichten, die gut zu wissen sein könnten.
- Hinweis-Etwas Normales, aber Bedeutendes ist passiert und es sollte beachtet werden.
- Warn-Etwas Unerwartetes ist passiert, aber es ist kein Grund zur Sorge.
- Fehler-Etwas ist fehlgeschlagen.
- Crit-Ein kritischer Zustand ist aufgetreten.
- Alarm-Sofortiges Handeln ist erforderlich.
- Emerg – Das system ist unbenutzbar.,
Konfigurieren von error_log
Standardmäßig erfasst die error_log-Datei alle Protokollnachrichten mit dem Schweregrad des Fehlers, was bedeutet, dass sie häufig zum Verständnis schwerwiegender oder kritischer Nachrichten verwendet wird, um beim Roubleshooting zu helfen. Der Standardspeicherort für error_logis logs/error.log. Die Art und Weise, wie NGINX Fehlermeldungen speichert, ist flexibel und unterstützt neben dem Schreiben von Nachrichten in eine Datei auch das Senden von error_logmessages an stderr oder den Syslog—Daemon. Wenn Sie NGINXopen source 1.5 ausführen.,2 oder neuer, Sie können auch error_log-Nachrichten an mehr als einen Ort gleichzeitig senden, indem Sie die error_log-Direktiven von multiple auf der gleichen Konfigurationsebene angeben.
Wenn Sie alle Nachrichten an oder über dem Warn-Protokoll protokollieren möchten, nehmen Sie folgende Konfigurationsänderung vor:
error_log logs/error.log warn;Protokollierung bei Syslog Mit NGINX
Sowohl die Anweisungen access_log als auch error_log unterstützen das Senden von Nachrichten an einen Syslog-Daemon mithilfe der Zeichenfolge syslog: in Ihrer Konfiguration., Das folgende Snippet zeigt die Syntax für die Verwendung einer der Direktiven mit einem Syslog-Daemon:
Wenn Sie beispielsweise alle error_log-Nachrichten mit warn oder höherem Schweregrad an den Syslogdaemon weiterleiten möchten, verwenden Sie diese Direktionszeile:
error_log syslog:server=192.168.1.1 severity=warn;Sie können die Syslogconfiguration mithilfe des beschriebenen Syslog-Parameters weiter an Ihre Umgebung anpassen.NGINXsyslog Dokumentation.
Frustrationsfreie Protokollverwaltung. (Es ist eine Sache.,)
Aggregieren, organisieren und verwalten Sie Ihre Protokolle mit Papertrail
Dinge, auf die Sie achten sollten
Die Flexibilität, die NGINX Logging bietet, kostet Geld, und es gibt einige Dinge, auf die Sie beim Schreiben Ihrer Konfigurationsdatei achten müssen. Wir haben bereits die Möglichkeit von NGINX behandelt, Loggingconfigurations auf Direktionsebene zu überschreiben, und diese Funktion ist äußerst nützlich, um zusätzliche Informationen zu generieren, wenn Benutzer auf bestimmte Pfade zugreifen, z. B. Loggingextra-Verkehrsinformationen für Benutzer, die auf den /privaten URI zugreifen., Die Verwendung verschachtelter Zugriffsprotokolle kann jedoch schnell werdenKomplex und Sie sollten darauf achten, diese Funktion nicht zu häufig zu verwenden.
Das Schreiben von access_logentries in eine Datei auf der Festplatte kann die Serverleistung beeinträchtigen und die Theresponse-Latenz für Benutzeranforderungen erhöhen. Für Webserver, die eine hohe Leistung aufrechterhalten müssenleistung bietet NGINX eine Möglichkeit, Protokollnachrichten in einen zyklischen Puffer inmemory zu schreiben, wobei die Festplatte vollständig umgangen wird. Das Extrahieren dieser Protokolle ist mehr involviertals das Lesen einer Datei, daher sollten Sie dies nur verwenden, wenn die Leistung für Ihre Arbeitslast von entscheidender Bedeutung ist.,
Um diese Funktion zu verwenden, muss Ihre Version von NGINX mit der Option—with-debug konfiguriert werden. Sie können überprüfen, ob dies der Fall ist, indem Sie dies tun:
$ nginx -V 2>&1 | grep—‘—with-debug’configure arguments: --with-debugIn der Konfigurationsdatei können Sie das Schreiben von Protokolleinträgen in den Speicher mit dem folgenden Snippet aktivieren:
error_log memory:32m debug;...http {...}Dadurch werden alle Protokollnachrichten auf Debug-Ebene geschrieben. Das Extrahieren der Protokollnachrichten aus dem Speicher erfordert die Verwendung von gdb, um eine Verbindung zum NGINX-Prozess herzustellen, und das Kopieren und Einfügen des folgenden Skripts an der Eingabeaufforderung:
set $log = ngx_cycle->logwhile $log->writer != ngx_log_memory_writerset $log = $log->nextendset $buf = (ngx_log_memory_buf_t *) $log->wdatadump binary memory debug_log.txt $buf->start $buf->endBeenden Sie GDB dann mit Strg-D., Das obige Skript schreibt den Inhalt des Speichers in das debug_log.txtfile, wo Sie es wie gewohnt lesen können.
Mit NGINX können Sie Protokolle für beide Routinezugriffe und unerwartete Fehler in separaten Dateien für eine spätere Analyse und Fehlerbehebung sammeln. Das Format der access_log-Datei kann umfassend angepasst werden,um detaillierte Informationen über Requests wie die Anzahl der an den Client gesendeten Bytes oder die Anforderungslänge einzuschließen, und die error_log-Direktive ermöglicht es Ihnen, den minimalen Schweregrad zu steuern, der für die Protokollierung von Nachrichten erforderlich ist.,Sowohl die access_log-als auch die error_log-Direktiven können Logentries an einen Syslog-Daemon übertragen, was für Entwickler, die mit mehreren Webservern arbeiten, äußerst praktisch sein kann.
Und wenn all diese Funktionen nicht ausreichen, können Sie sogar error_logentries in einen Speicherpuffer schreiben, um das Schreiben auf die Festplatte zu vermeiden und die Leistungseinwirkung für ausgelastete Server zu verringern.