Nginx Access, error log detailed

1. Introduction to the Log

There are two main types of Nginx logs: Access logs and error logs. The access log mainly records each request that the client accesses Nginx, the format can be customized; the error log mainly records the log when the client accesses Nginx error, and the format does not support customization. Both types of logs can be selectively closed.

Through the access log, you can get the user's geographical source, jump source, use terminal, a URL to visit the amount of relevant information, through the error log, you can get the system a service or server performance bottleneck. So make good use of the logs and you can get a lot of valuable information.

2. Access log

[Access.log]

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 ';

Variable name

Variable description

Examples Show

$remote _addr

Client Address

113.140.15.90

$remote _user

Client User Name

-

$time _local

Access time and time zone

18/jul/2012:17:00:01 +0800

$request

URI and HTTP protocol for the request

"Get/pa/img/home/logo-alipay-t.png http/1.1"

$http _host

Request address, which is the address (IP or domain name) you entered in the browser

Img.alipay.com

10.253.70.103

$status

HTTP request Status

200

$upstream _status

Upstream status

200

$body _bytes_sent

Send to client file content size

547

$http _referer

Jump Source

"Https://cashier.alipay.com.../"

$http _user_agent

User Terminal Agent

"Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; trident/4.0; SV1; GTB7.0;. net4.0c;

$ssl _protocol

SSL protocol version

TLSv1

$ssl _cipher

Algorithms in the exchange of data

Rc4-sha

$upstream _addr

The address of the backend upstream, which is the host address that really provides the service

10.228.35.247:80

$request _time

Total time for the entire request

0.205

$upstream _response_time

Upstream response time during the request

0.002

On-line examples:

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 (compatible; 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

Offline test ($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 "94193" http://spanner.alipay.net/optionFrame/history.html "" mozilla/5.0 (Windows NT 6.1) applewebkit/537.1 (khtml, like Gecko) chrome/21.0.1180.60 safari/537.1 "

clip_image001

Note: $http _referer is related to redirection.

Offline test ($http _host):

clip_image002

Note: The value of $http _host is related to the value you enter in the browser.

3. Error log

Error message

Error description

"Upstream prematurely (premature) Closed connection"

The exception that occurs when the URI is requested is due to the user's disconnection from the connection when the upstream has not returned to the user, which has no effect on the system and can be ignored

"Recv () failed (104:connection reset by Peer)"

(1) The number of concurrent connections to the server exceeds its capacity, and the server will drop some of the connections;

(2) The client has turned off the browser and the server is sending data to the client;

(3) The browser side pressed the stop

"(111:connection refused) while connecting to upstream"

The user will receive this error if he or she encounters a backend upstream hangs or is not connected.

"(111:connection refused) while reading response headers from upstream"

When the user reads the data after the connection is successful, it will receive the error if the backend upstream hangs or does not pass.

"(111:connection refused) while sending request to upstream"

Nginx and upstream send data after successful connection, if you encounter the backend upstream hangs or does not pass, you will receive this error

"(110:connection timed out) while connecting to upstream"

Upstream timeout after Nginx connection

"(110:connection timed out) while reading upstream"

Nginx reads a response from upstream time-out

"(110:connection timed out) while reading response headers from upstream"

Nginx timed out when reading a response header from upstream

"(110:connection timed out) while reading upstream"

Nginx reads a response from upstream time-out

"(104:connection reset by peer) and connecting to upstream"

Upstream sends the RST to reset the connection

"Upstream sent invalid header while reading response headers from upstream"

Invalid response header sent by upstream

"Upstream sent no valid http/1.0 header while reading response headers from upstream"

Invalid response header sent by upstream

"Client intended to send too large body"

The maximum value that is used to set the allowed client request content, the default value is 1m,client sent body exceeds the set value

"Reopening logs"

User sends KILL-USR1 command

"Gracefully shutting down",

User sends Kill-winch command

"No servers is inside upstream"

Server not configured under upstream

"No live upstreams while connecting to upstream"

The servers under upstream are all hung up.

"Ssl_do_handshake () failed"

SSL handshake failed

"Ssl_write () failed (SSL:) while sending to client"

"(13:permission denied) while reading upstream"

"(98:address already in use) and connecting to upstream"

"(99:cannot assign requested address) while connecting to upstream"

"Ngx_slab_alloc () Failed:no memory in SSL session shared cache"

Ssl_session_cache size is not enough to cause

"Could not add new SSL session to the session ' cache while SSL handshaking"

Ssl_session_cache size is not enough to cause

"Send () failed (111:connection refused)"

The problem is that Apache 80 is forwarding to 8080 of Apache when it fails:

[ERROR] (99) Cannot assign requested Address:proxy:HTTP:attempt to connect to 127.0.0.1:8080 (*) failed

Netstat time wait too many causes [ERROR] cannot assign requested address

Sysctl-w net.ipv4.tcp_tw_recycle=1 for fast recovery of time-wait sockets in a TCP connection

Changed this parameter in observation: Apache no error, time wait number also dropped

Net.ipv4.tcp_syncookies = 1

Indicates that SYN Cookies are turned on. When there is a SYN wait queue overflow, cookies are enabled to protect against a small number of SYN attacks, the default is 0, which means close;

Net.ipv4.tcp_tw_reuse = 1

means to turn on reuse. Allows time-wait sockets to be re-used for new TCP connections, which defaults to 0, which means shutdown;

Net.ipv4.tcp_tw_recycle = 1

Represents a quick recycle of time-wait sockets on a TCP connection, which defaults to 0, which means shutdown.

Net.ipv4.tcp_fin_timeout = 30

Indicates that if the socket is closed by a local requirement, this parameter determines when it remains in the fin-wait-2 state.

Net.ipv4.tcp_keepalive_time = 1200

Indicates the frequency at which TCP sends keepalive messages when KeepAlive is employed. The default is 2 hours, which is changed to 20 minutes.

Net.ipv4.ip_local_port_range = 1024?? 65000

Represents the range of ports used for an outward connection. Small by default: 32768 to 61000, 1024 to 65000.

Net.ipv4.tcp_max_syn_backlog = 8192

Represents the length of the SYN queue, which defaults to 1024, and a larger queue length of 8192, which can accommodate more network connections waiting to be connected.

Net.ipv4.tcp_max_tw_buckets = 5000

Indicates that the system maintains the maximum number of time_wait sockets at the same time, and if this number is exceeded, the time_wait socket is immediately cleared and a warning message is printed. The default is 180000, which changes to 5000. For Apache, Nginx and other servers, the parameters of the last few lines can be a good way to reduce the number of time_wait sockets, but for squid, the effect is not small. This parameter can control the maximum number of time_wait sockets and avoid the squid server being dragged to death by a large number of time_wait sockets ...

Nginx Access, error log detailed