検索

ホームページ >運用・保守 >Nginx >nginxのエラーログを分析する方法

nginxのエラーログを分析する方法

步履不停
步履不停オリジナル
2019-06-21 09:51:506537ブラウズ

nginxのエラーログを分析する方法

1. ログの概要

nginx ログには、アクセス ログとエラー ログの 2 つの主な種類があります。アクセス ログは主にクライアントから nginx にアクセスするすべてのリクエストを記録し、形式はカスタマイズ可能です。エラー ログは主にクライアントが nginx にアクセスしてエラーが発生した場合のログを記録し、形式はサポートされていませんカスタマイズ。オプションで両方のログをオフにすることができます。

アクセス ログを通じて、ユーザーの地理的出身地、ジャンプ元、端末の使用状況、特定の URL への訪問回数などの関連情報を取得できます。エラー ログを参照すると、システム内の特定のサービスや サーバーなどのパフォーマンスのボトルネックを取得できます。したがって、ログをうまく活用することで、多くの貴重な情報を得ることができます。

2. アクセス ログ

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

'$ Requesst_Time $ Upstream_time_time

#変数の説明##$remote_addrリクエストされた リクエスト アドレス、つまり、ブラウザ (#IPimg.alipay .com$upstream_statusステータス#"https://cashier.alipユーザー ターミナル エージェントSSL TLSv10.205
##変数名

##例

クライアント アドレス

113.140.15.90

##$remote_user

クライアント ユーザー名

 -

#$time_local

訪問時間とタイムゾーン

18/7月/2012:17:00:01 0800

#$request

URI および HTTPプロトコル

#"GET /pa/img/home/logo-alipay-t.png HTTP/1.1 "

$http_host
またはドメイン名)

10.253.70.103

##$ステータス

#HTTPリクエスト ステータス

##200

##上流

200

$body_bytes_sent

クライアントに送信されるファイル コンテンツのサイズ

 547

#$http_referer

##ソースにジャンプ

ay.com.../"

##$http_user_agent

「Mozilla/4.0 (互換性; MSIE 8.0; Windows NT 5.1; Trident/4.0; SV1; GTB7.0; .NET4.0C ;

$ssl_protocol
プロトコル バージョン

 #$ssl_cipher

##交換データのアルゴリズム
#RC4- SHA

$upstream_addr

バックグラウンドのアドレスアップストリーム

、つまり実際にサービスを提供するホストのアドレス

10.228.35.247 :80

#リクエスト時間

リクエスト全体の合計時間

$upstream_response_time

リクエスト プロセス中、upstream応答時間

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 (互換性; 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/8/12-00:00:00&-T=+ 2880&- 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 (Gecko のような KHTML) Chrome/21.0.1180.60 Safari/537.1"

nginxのエラーログを分析する方法

##備考: $ http_referer はリダイレクトに関連しています。

オフライン テスト ($http_host):

nginxのエラーログを分析する方法

注: $http_host の値は、ブラウザに入力する値に関連しています。

3. エラー ログ

##"(111: 接続が拒否されました) アップストリームへの接続中に"に遭遇するとハングアップするか失敗し、次のエラー##"(110: 接続がタイムアウトしました) "(110: 接続がタイムアウトしました) アップストリームの読み取り中に"" (104: ピアによる接続リセット) アップストリームへの接続中に「##アップストリーム#「クライアントは大きすぎる本文を送信することを意図していました」client# です##送信された 「ngx_slab_alloc() が失敗しました: SSL セッション共有キャッシュにメモリがありません」大不不够等原因造成「SSL ハンドシェイク中に新しい SSL セッションをセッション キャッシュに追加できませんでした」大不够等の原因造成#「send() が失敗しました (111: 接続が拒否されました)」
エラー メッセージ

 エラーの説明

「アップストリームが時期尚早に(時期尚早) 接続が閉じられました「

uri をリクエストするときに発生する例外は、アップストリーム ## が原因です# これは、ユーザーに応答が返されないときにユーザーが切断することが原因で発生します。システムには影響せず、無視してかまいません

##「recv() が失敗しました (104: ピアによって接続がリセットされました)」

#（		 1

）サーバー 同時接続の数がその収容能力を超えているため、サーバーは Down の一部の接続をドロップします; （

2

）クライアントはブラウザを閉じましたが、サーバーはまだクライアントにデータを送信しています; （

3

）停止を押します

# # ブラウザ上で

ユーザーが接続しているとき、ユーザーがバックエンド

upstream

##が表示されます。 ##"(111: 接続が拒否されました) 上流からの応答ヘッダーの読み取り中に"

ユーザーが接続に成功した後にデータを読み取るときに、バックエンド upstream がハングまたはブロックされている場合、このエラーが表示されます

#"(111: 接続が拒否されました) 上流へのリクエスト送信中"#の場合Nginx

と 		upstream

は正常に接続され、データを送信していますが、バックエンド upstream がハングまたはブロックされている場合、アップストリーム "#" への接続中にエラー

#nginx次の

upstream

## への接続時にタイムアウトが発生しました##"(110: 接続がタイムアウトしました) アップストリームの読み取り中に"

nginxアップストリームからの応答の読み取り中にタイムアウトしました

#"(110: 接続がタイムアウトしました) アップストリームからの応答ヘッダーの読み取り中に"

nginx

アップストリームからの応答ヘッダーの読み取り中にタイムアウト

nginx

アップストリームからの応答の読み取り中にタイムアウトしました

##upstreamSend RST

、接続をリセットします

「アップストリームからの応答ヘッダーの読み取り中に、アップストリームが無効なヘッダーを送信しました」

upstream送信された応答ヘッダーが無効です

#「アップストリームからの応答ヘッダーの読み取り中に、アップストリームは有効な HTTP/1.0 ヘッダーを送信しませんでした」

送信された応答ヘッダーは無効です

## は、受け入れが許可されるクライアント リクエスト コンテンツの最大値を設定するために使用されます。デフォルト値は 1M,

body が設定値を超えています

「ログを再度開く」

 #ユーザーが

kill -USR1command を送信

「正常にシャットダウンしています」、

用户送信 kill -WINCH コマンド

「アップストリーム内にサーバーはありません」

アップストリーム下未構成サーバー

「アップストリームへの接続中にライブ アップストリームがありません」

アップストリーム下のserver全都挂了

"SSL_do_handshake( ) 失敗しました"

SSL グリップ

「クライアントへの送信中に SSL_write() が失敗しました (SSL:)」

##"(13: 許可が拒否されました) アップストリーム読み取り中"

##"(98: アドレスはすでに入力されていますアップストリームに接続するときに使用します）「

#"(99: 要求されたアドレスを割り当てることができません) アップストリームへの接続中"

##ssl_session_cache

ssl_session_cache

#

Nginx 関連の技術記事の詳細については、Nginx チュートリアル 列にアクセスして学習してください。

以上がnginxのエラーログを分析する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

nginx chrome safari html while Session .net 并发 history windows 算法 http https ssl Access
声明：
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
前の記事：nginx が 404 で表示されるのはなぜですか次の記事：nginx が 404 で表示されるのはなぜですか

関連記事

続きを見る