Nginx ログのカスタマイズとログ バッファの有効化の詳細な説明

序文

ウェブサイトのアクセス元をカウントしたい場合は、PHP を使用して情報を取得してデータベースに記録するか、nginx が提供するアクセス ログを直接使用してウェブサイトのアクセス詳細を記録することができます。管理者は、nginx のアクセス ログを分析することで、ユーザーのアクセス元、アクセス行動の詳細、ウェブサイトのページのアクセス人気度などを分析できます。さらに、nginx 自体にもエラー ログがあるため、運用保守担当者が nginx をデバッグしやすくなります。ログを記録する動作については、毎回ディスク操作を行うと、より多くのリソースが消費されます。この状況に基づいて、nginx ログ バッファを有効にすることができます。バッファがいっぱいになった場合、またはスケジュールされた書き込み時間に達した場合に、ログが再度書き込まれます。

アクセスログ

nginx は、リクエストを処理した直後に、クライアント リクエストに関する情報をアクセス ログに書き込みます。デフォルトでは、アクセス ログは logs/access.log に保存され、情報は事前に定義された結合形式でログに書き込まれます。

アクセス情報を正確に記録するには、次に示すように、より完全なアクセス ログ形式をカスタマイズする必要があります。

http {
  ログフォーマット ジオプロキシ
  '[$time_local] $remote_addr'
  '$realip_remote_addr $remote_user'
  '$request_method $server_protocol'
  '$scheme $server_name $uri $status'
  '$request_time $body_bytes_sent'
  '$geoip_city_country_code3 $geoip_region'
  '"$geoip_city" $http_x_forwarded_for '
  '$upstream_status $upstream_response_time'
  '"$http_referer" "$http_user_agent"';
  ...
}

このログ記録構成は geoproxy という名前で、nginx のログ記録機能を実証するためにいくつかの nginx 変数を使用します。設定オプション内の各変数の具体的な意味を詳しく説明します。

ユーザーがリクエストを開始すると、サーバー時間 $time_local が記録され、$remote_user の値は基本認証に合格したユーザー名になります。

開いている接続の IP アドレスと、geoip_proxy および realip_header ディレクティブを処理するために nginx によって使用されるクライアント IP アドレス。

次に、HTTP リクエスト メソッド $request_method、プロトコル $server_protocol、HTTP メソッド $scheme: http または https を記録します。

もちろん、サーバー名 $server_name 、要求された URI、応答ステータス コードもあります。

基本情報に加えて、リクエスト処理のミリ秒時間 $request_time やサーバー応答のデータ ブロック サイズ $body_bytes_sent などの統計結果データもあります。

さらに、クライアントの国 $geoip_city_country_code3 、地域 $geoip_region 、都市情報 $geoip_city も記録されます。

変数 $http_x_forwarded_for は、他のプロキシ サーバーによって開始された要求の X-Forwarded-For ヘッダー メッセージを記録するために使用されます。

アップストリーム モジュールからの一部のデータもログに記録されます: プロキシされたサーバーの応答ステータス コード $upstream_status 、接続を確立してからアップストリーム サーバーから応答本体の最後のバイトを受信するまでの時間 $upstream_response_time 、アップストリーム サーバーとの接続を確立してから接続を確立するまでの時間 $upstream_connect_time 、接続を確立してからアップストリーム応答ヘッダーの最初のバイトを受信するまでの時間 $upstream_header_time 。

リクエストソース $http_referer とユーザーエージェント $http_user_agent もログに記録できます。

nginx のログ機能は非常に強力で柔軟性があります。ログ形式を定義するために使用される log_format ディレクティブは、http ブロックレベルのディレクティブにのみ適用され、すべての時間値はミリ秒単位でミリ秒の解像度で測定されることに注意してください。 。

この形式のログ構成では、次の種類のログが生成されます。

[2019年2月25日:16:20:42 +0000] 10.0.1.16 192.168.0.122 デレク
GET HTTP/1.1 http www.example.com / 200 0.001 370 USA MI
「アナーバー」 - 200 0.001 「-」 「curl/7.47.0」

このログ設定を使用する必要がある場合は、ログ ディレクトリと設定名をパラメーターとして受け取る access_log ディレクティブと組み合わせて使用​​する必要があります。

サーバー{
  access_log /var/log/nginx/access.log ジオプロキシ;
  ...
}

access_log は複数のコンテキストで使用でき、各コンテキストで独自のログ ディレクトリとログ レコード形式を定義できます。

結論: nginx のログ モジュールを使用すると、さまざまなシナリオに合わせてログ形式を設定できるため、さまざまなログ ファイルを表示できます。

実際には、異なるコンテキストごとに異なるログを構成すると非常に便利です。ログの内容は、単純な情報にすることも、必要なすべての情報の詳細な記録にすることもできます。補足テキストに加えて

また、json および xml 形式でデータを記録することもできます。実際、nginx ログは、サーバー トラフィック、クライアントの使用状況、クライアント ソースなどの情報を理解するのに役立ちます。さらに、アクセス ログは、アップストリーム サーバーまたは特定の URI に関連する応答や問題を見つけるのにも役立ちます。アクセス ログは、トラフィック状況の分析や実際のユーザー インタラクション シナリオのシミュレートに使用できるため、テストにも役立ちます。ログは、トラブルシューティング、デバッグ、アプリケーション分析、ビジネス調整に不可欠です。

エラーログ

nginx のエラー ログを正確に見つけるには、組み込みの error_log ディレクティブを使用して、エラー ログ ディレクトリとエラー ログ記録のレベルを定義します。設定は次のとおりです。

error_log /var/log/nginx/error.log 警告;

error_log ディレクティブは、必須のログ ディレクトリとオプションのエラー レベル オプションを受け取ります。

error_log ディレクティブは、if ディレクティブを除くすべてのコンテキストで使用できます。エラー ログ レベルには次のものがあります:

debug、info、notice、warn、error、crit、alert、emerge です。与えられたログ

レベル順序は、ログ レベルを最小から最も厳密なものまで並べた順序です。デバッグログに注意することが重要です

nginx サーバーを使用するには、--with-debug フラグを使用してコンパイルする必要があります。

サーバー構成エラーが発生した場合は、まずエラー ログをチェックして問題を特定する必要があります。エラーログ

また、アプリケーション サーバー (FastCGI サーバーなど) を見つけるための強力なツールでもあります。エラー ログを通じて、ワーカー プロセスの接続エラー、メモリ割り当て、クライアント IP、アプリケーション サーバーなどの問題をデバッグできます。 エラー ログ形式ではカスタム ログ形式はサポートされませんが、現在の時刻、ログ レベル、特定の情報などのデータも記録されます。

注: エラー ログのデフォルト設定はグローバルに適用されます。これを上書きするには、メイン (最上位) 構成コンテキストに error_log ディレクティブを配置します。同じ設定レベルで複数の error_log ディレクティブを指定する機能は、NGINX Open Source バージョン 1.5.2 で追加されました。

syslog経由で統合サーバーにログを送信する

ログはディスク上のディレクトリに書き込む必要がなくなり、統合ログ サーバーに送信する必要があるため、元のディレクトリ部分をサーバーの IP アドレスに置き換えるだけです。構成は次のとおりです。

error_log syslog:server=10.0.1.42 デバッグ;
access_log syslog:server=10.0.1.42、tag=nginx、severity=info geoproxy;

#error_log server=unix:/var/log/nginx.sock デバッグ;
#access_log syslog:server=[2001:db8::1]:1234、facility=local7、tag=nginx、severity=info;

error_log および access_log ディレクティブの syslog パラメータの後には、コロン : といくつかのパラメータ オプションが続きます。含まれるもの: 必要なサーバー タグは、接続先の IP、DNS 名、または UNIX ソケットを示します。

上記の通りハイエンドでプレイ可能です。

オプションのパラメータは facility 、 severity 、 tag です。

サーバー パラメータは、ポート付きの IP アドレスまたは DNS 名を受け入れます。デフォルトは UDP ポート 514 です。

facility パラメータは、syslog タイプの facility を設定します。値は、syslog RFC 標準で定義されている 23 個の値のいずれかです。デフォルト値は local7 です。その他の可能な値は次のとおりです: auth、authpriv、daemon、cron、ftp、lpr、kern、mail、news、syslog、user、uucp、local0 ... local7

タグ パラメータは、ログ ファイルに表示されるタイトルを示します。デフォルト値は nginx です。

重大度はメッセージの重大度を設定します。デフォルトは情報レベルのログです。

ログバッファ

システムに負荷がかかっている場合は、ログ バッファを有効にして、nginx ワーカー プロセスのブロックを減らします。大量のディスク読み取りと書き込み、および CPU リソースの使用も、サーバー リソースの大きな消費につながります。ログ データをメモリにバッファリングすることは、小さな最適化方法である可能性があります。バッファ パラメータは、バッファのサイズを意味します。バッファがいっぱいになると、ログはファイルに書き込まれます。フラッシュ パラメータは、バッファ内のログがバッファ メモリに保持される最大時間を意味します。キャッシュ内のログが最大キャッシュ時間を超えると、ファイルにも書き込まれます。欠点は、ログをログ ファイルに書き込むときに若干の遅延が発生することです。リアルタイム デバッグ中は、ログ バッファリングをオフにする必要があります。 。構成は次のとおりです。

http {
  access_log /var/log/nginx/access.log メインバッファ=32k フラッシュ=1m;
}

参考リンク:

1. nginx クックブック
2. nginx 設定ログ

要約する

以上がこの記事の全内容です。この記事の内容が皆様の勉強や仕事に何らかの参考学習価値をもたらすことを願います。123WORDPRESS.COM をご愛顧いただき、誠にありがとうございます。