So analysieren Sie das Nginx-Fehlerprotokoll

1. Protokolleinführung

Es gibt zwei Haupttypen von Nginx-Protokollen: Zugriffsprotokolle und Fehlerprotokolle. Das Zugriffsprotokoll zeichnet hauptsächlich jede Anfrage des Clients auf, der auf nginx zugreift, und das Format kann angepasst werden. Das Fehlerprotokoll zeichnet hauptsächlich das Protokoll auf, wenn der Client auf nginx zugreift und ein Fehler auftritt, und das Format unterstützt keine Anpassung . Beide Protokolle können optional ausgeschaltet werden.

Über das Zugriffsprotokoll können Sie relevante Informationen wie die geografische Herkunft des Benutzers, die Sprungquelle, die Terminalnutzung und die Anzahl der Besuche einer bestimmten URL abrufen Im Fehlerprotokoll können Sie den Leistungsengpass eines bestimmten Systemdienstes oder Servers usw. ermitteln. Daher können Sie durch die sinnvolle Nutzung von Protokollen viele wertvolle Informationen erhalten.

2. Zugriffsprotokoll

[Zugriffsprotokoll]

log_format main '$remote_addr $remote_user [$time_local] "$request" $http_host '

'$status $upstream_status $body_bytes_sent "$http_referer" '

'"$http_user_agent" $ssl_protocol $ssl_cipher $upstream_addr '

"$request_time $upstream_response_time';

Variablenname	Variablenbeschreibung	Beispiel
$remote_addr	Kundenadresse	113.140.15.90
$remote_user	Client-Benutzername	-
$time_local	Besuchen Sie Zeit und Zeitzone	18/Jul/2012:17:00:01 +0800
$request	AngefordertURI und HTTPProtokoll	"GET /pa/img/home/logo-alipay-t.png HTTP / 1,1"
$http_host	Adresse anfordern, also die Adresse, die Sie im Browser eingeben (IP oder Domainname)	img.alipay.com 10.253.70.103
$status	HTTPAnfragestatus	200
$upstream_status	upstream Status	200
$body_bytes_sent	Größe des an den Client gesendeten Dateiinhalts	547
$http_referer	Quelle springen	"https://cashier.alipay.com.../"
$http_user_agent	Benutzer-Terminal-Agent	"Mozilla/4.0 (kompatibel; MSIE 8.0; Windows NT 5.1; Trident/4.0; SV1; GTB7.0; .NET4.0C ;
$ssl_protocol	SSLProtokollversion	TLSv1
$ssl_cipher	Algorithmen in Austauschdaten	RC4-SHA
$upstream_addr	BackendUpstream Adresse, also die Hostadresse, die tatsächlich Dienste bereitstellt	10.228.35.247:80
$request_time	Gesamtzeit der gesamten Anfrage	0,205
$upstream_response_time	Während des Anfrageprozesses UpstreamAntwortzeit	0,002

 

线上实例：

116.9.137.90 - [02/Aug/2012:14:47:12 +0800] „GET /images/XX/20100324752729.png HTTP/1.1“img.alipay.com 200 200 2038 https://cashier.alipay.com/XX/PaymentResult.htm?payNo=XX&outBizNo=2012XX “ Mozilla/4.0 (kompatibel; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; Tablet PC 2.0; 360SE )" TLSv1 AES128-SHA 10.228.21.237:80 0,198 0,001 $http_referer

）：

10.14.21.197 - - [14/Aug/2012:17:28:22 +0800] "GET /spanner/watch/v1?--db=ztg-1&--mode=compare&--index=status&--option=&--cluster=whole&-F=2012%2F8%2F12-00%3A00%3A00&-T =%2B2880&-i=1&-n=0&_=1344936501292 HTTP/1.1" 200 94193 "http://spanner.alipay.net/optionFrame/history.html" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.1 (KHTML , wie Gecko) Chrome/21.0.1180.60 Safari/537.1"

 

备注：

$http_referer和重定向有关.

 

线下测试（$http_host ）:

 备注:

$http_host的值和你在浏览器里输入的值有关

3、错误日志

 

错误信息

错误说明

（过早的）（用户在连接时，若遇到后端UpstreamDer gesendete Antwortheader ist ungültig"Upstream hat beim Lesen des Antwortheaders vom Upstream keinen gültigen HTTP/1.0-Header gesendet"UpstreamDer gesendete Antwortheader ist ungültig"Der Client wollte es tun send too big body“1M , Client Befehl

Weitere technische Artikel zum Thema Nginx finden Sie in der Spalte Nginx-Tutorial, um mehr darüber zu erfahren!

"stromaufwärts vorzeitig	geschlossene Verbindung"
请求uri的时候出现的异常，是由于Upstream还未返回应答给用户时用户断掉连接造成的，对系统没有影响，可以忽略	"recv() fehlgeschlagen (104: Verbindung vom Peer zurückgesetzt)"
1 ）服务器的并发连接数超过了其承载量,服务器会将其中一些连接Down掉；	（2）客户关掉了浏览器，而服务器还在给客户端发送数据；  （ 3）浏览器端按了Stopp "(111: Verbindung verweigert) beim Herstellen einer Verbindung zum Upstream"
upstream 挂掉或者不通，会收到该错误	"(111: Verbindung abgelehnt) beim Lesen des Antwortheaders vom Upstream"	Wenn Benutzer nach einer erfolgreichen Verbindung Daten lesen und das Backend Upstream hängt oder blockiert ist, erhalten sie diesen Fehler
"(111: Verbindung verweigert) beim Senden der Anfrage an den Upstream"	Nginx und Upstream sind erfolgreich verbunden und senden Daten. Wenn das Backend Upstream hängt oder blockiert ist, erhalten Sie das Fehler
"(110: Zeitüberschreitung der Verbindung) beim Herstellen einer Verbindung zum Upstream "	nginx Zeitüberschreitung beim Herstellen einer Verbindung zum nachfolgenden Upstream
"(110: Zeitüberschreitung der Verbindung) beim Upstream-Lesen"	nginxZeitüberschreitung beim Lesen der Antwort von Upstream
"(110: Zeitüberschreitung der Verbindung) beim Lesen des Antwortheaders vom Upstream"	nginxZeitüberschreitung beim Lesen von Antwortheadern von Upstream
"(110: Zeitüberschreitung der Verbindung) beim Upstream-Lesen"	nginxZeitüberschreitung beim Lesen der Antwort von Upstream
"(104: Verbindung vom Peer zurückgesetzt) ​​beim Herstellen einer Verbindung zum Upstream"	UpstreamSenden „Upstream ungültig gesendet“ Header beim Lesen des Antwortheaders vom Upstream“
	wird verwendet, um den Maximalwert des Clientanforderungsinhalts festzulegen, der akzeptiert werden darf. Der Standardwert ist
gesendete Text überschreitet den eingestellten Wert	"Protokolle erneut öffnen"Benutzer sendet kill -USR1
"ordnungsgemäß heruntergefahren",	Benutzer gesendet kill -WINCHBefehl
„Keine Server befinden sich im Upstream“	Upstream ist nicht unter Server
„keine Live-Upstreams während der Verbindung zum Upstream“	Upstream Serveralles aufgehängt
"SSL_do_handshake( ) fehlgeschlagen"	SSLHandshake fehlgeschlagen
„SSL_write() fehlgeschlagen (SSL:) beim Senden an den Client“
"(13: Erlaubnis verweigert) beim Lesen im Upstream"
"(98: Adresse bereits verwendet ) während der Verbindung zum Upstream“
"(99: Angeforderte Adresse kann nicht zugewiesen werden) beim Herstellen einer Verbindung zum Upstream"
"ngx_slab_alloc() failed: no Memory in SSL Session Shared Cache"	ssl_session_cache wird durch unzureichende Größe und andere Gründe verursacht
„Während des SSL-Handshakes konnte keine neue SSL-Sitzung zum Sitzungscache hinzugefügt werden“	ssl_session_cache nicht groß genug usw. Ursachen
"send() failed (111: Connection failed)"

Das obige ist der detaillierte Inhalt vonSo analysieren Sie das Nginx-Fehlerprotokoll. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!