CentOS7のNginxにログモジュールを追加する方法
序章
サーバー管理は、サービスの初期構成だけではありません。 また、これらのサービスを監視し、可能な限りスムーズに実行されていることを確認する必要があります。 管理者にとって最も重要な知識源の1つは、システムイベントに関する情報を含むログファイルです。
NginxなどのWebサーバーの場合、ログには、Webサーバーを介してリソースにアクセスする各試行に関する貴重な情報が含まれます。 各Webサイトの訪問者と表示された画像、またはダウンロードされたファイルは、ログに細心の注意を払って登録されます。 エラーが発生すると、それらもログに保存されます。 適切に構造化されたログファイルを操作する方がはるかに簡単です。
このガイドでは、Nginxのロギングモジュールを利用する方法を見ていきます。 サーバーブロックごとに個別のログファイルを設定してから、ログ出力をカスタマイズします。 また、リクエストに関する追加情報(このチュートリアルの例では、リクエストの処理にかかる時間)を、Nginxにデフォルトで含まれているものを超えてアクセスログに追加します。
前提条件
このチュートリアルに従うには、次のものが必要です。
-
この初期サーバーセットアップチュートリアルでセットアップされた1台のCentOS7サーバー(sudo非rootユーザーを含む)。
-
CentOS7チュートリアルにNginxをインストールする方法に従ってサーバーにインストールされたNginx。
ステップ1—テストファイルの作成
このステップでは、デフォルトのNginxWebサイトディレクトリにいくつかのテストファイルを作成します。 これらを使用して、ロギング構成をテストします。
Nginx(またはその他のWebサーバー)がファイルのHTTP要求を受信すると、そのファイルを開き、そのコンテンツをネットワーク経由で転送することでユーザーに提供します。 ファイルが小さいほど、転送速度は速くなります。 ファイルが完全に転送されると、リクエストは完了したと見なされ、転送ログに記録されます。
このチュートリアルの後半では、ロギング構成を変更して、各リクエストにかかった時間に関する有用な情報を含めます。 変更された構成をテストし、さまざまな要求の違いに気付く最も簡単な方法は、さまざまな時間で送信されるさまざまなサイズの複数のテストファイルを作成することです。
名前の付いた1メガバイトのファイルを作成しましょう 1mb.test
デフォルトのNginxディレクトリで truncate
.
- sudo truncate -s 1M /usr/share/nginx/html/1mb.test
同様に、サイズの異なる2つのファイル(最初は10メガバイト、次に100メガバイト)を作成し、それに応じて名前を付けます。
- sudo truncate -s 10M /usr/share/nginx/html/10mb.test
- sudo truncate -s 100M /usr/share/nginx/html/100mb.test
最後になりましたが、空のファイルも作成しましょう。
- sudo touch /usr/share/nginx/html/empty.test
次のステップでこれらのファイルを使用してログファイルにデフォルト構成を入力し、チュートリアルの後半でカスタマイズされた構成を示します。
ステップ2—デフォルト構成を理解する
ログモジュールはコアNginxモジュールです。つまり、使用するために個別にインストールする必要はありません。 ただし、デフォルトの構成は最低限です。 このステップでは、デフォルト構成がどのように機能するかを確認します。
新規インストールでは、Nginxはすべてのリクエストをアクセスログとエラーログの2つの別々のファイルに記録します。 にあるエラーログ /var/log/nginx/error.log
、異常なサーバーエラー、またはリクエストの処理中のエラーに関する情報を格納します。
にあるアクセスログ /var/log/nginx/access.log
、より頻繁に使用されます。 Nginxへのすべてのリクエストに関する情報が保存される場所です。 このログでは、特に、ユーザーがアクセスしているファイル、使用しているWebブラウザー、ユーザーが持っているIPアドレス、およびNginxが各リクエストに応答したHTTPステータスコードを確認できます。
アクセスログファイルの行例を見てみましょう。 まず、ステップ1で作成した空のファイルをNginxにリクエストして、ログファイルが空にならないようにします。
- curl -i http://localhost/empty.test
応答として、いくつかのHTTP応答ヘッダーが表示されます。
HTTP/1.1 200 OK
Server: nginx/1.6.3
Date: Fri, 05 Aug 2016 22:05:03 GMT
Content-Type: application/octet-stream
Content-Length: 0
Last-Modified: Fri, 05 Aug 2016 22:04:55 GMT
Connection: keep-alive
ETag: "57a50d87-0"
Accept-Ranges: bytes
この応答から、いくつかのことを学ぶことができます。
HTTP/1.1 200 OK
Nginxが次のように応答したことを示しています200 OK
エラーがなかったことを示すステータスコード。Content-Length: 0
返されるドキュメントの長さがゼロであることを意味します。- リクエストはで処理されました
Fri, 05 Aug 2016 22:05:03 GMT
.
これがNginxがアクセスログに保存したものと一致するかどうかを見てみましょう。 ログファイルは管理ユーザーのみが読み取ることができるため、 sudo
それらにアクセスするには使用する必要があります。
- sudo tail /var/log/nginx/access.log
ログには、以前に発行したテスト要求に対応するこのような行が含まれます。
::1 - - [05/Aug/2016:22:05:03 +0000] "GET /empty.test HTTP/1.1" 200 0 "-" "curl/7.29.0" "-"
Nginxは、 Combined Log Format を使用します。これは、相互運用性のためにWebサーバーで一般的に使用されるアクセスログの標準化された形式です。 この形式では、各情報は1つのスペースで区切られます。 ハイフンは、欠落している情報を表します。
左から右へ、カテゴリは次のとおりです。
-
リソースを要求したユーザーのIPアドレス。 使ったから
curl
ローカルでは、アドレスはローカルホストを指します。::1
. -
リモートロギング情報。 Nginxはこの情報をサポートしていないため、ここでは常にハイフンになります。
-
HTTP基本認証に準拠したログインユーザーのユーザー名。 これは、すべての匿名リクエストでは空になります。
-
リクエスト日。 これは、応答ヘッダーの日付と一致していることがわかります。
-
リクエストパス。リクエストメソッド(
GET
)、要求されたファイルへのパス(/empty.text
)および使用されるプロトコル(HTTP/1.1
). -
応答ステータスコード、
200 OK
、成功を意味します。 -
転送されたファイルの長さ、
0
ここでは、ファイルが空だったためです。 -
HTTPリファラーヘッダー。リクエストが発信されたドキュメントのアドレスが含まれています。 この例では空ですが、これが画像ファイルの場合、リファラーは画像が使用されたページを指します。
HTTPリファラーヘッダーは、「リファラー」という単語のスペルミスです。これは、HTTPの起源に戻り、HTTP標準の一部です。
-
ユーザーエージェント、つまり
curl
ここ。 -
X-Forwarded-For ヘッダー、ここでは空。元のリクエストがプロキシ経由で転送された場合の送信元IPアドレスに関する情報が含まれます。
アクセスログの単一のログエントリでさえ、リクエストに関する多くの貴重な情報が含まれています。 ただし、不足している重要な情報が1つあります。 の正確な場所をリクエストしましたが http://localhost/empty.test
、へのパスのみ /empty.test
ファイルはログエントリにあります。 ホスト名に関する情報(ここでは、 localhost
)が失われます。
ステップ3—個別のアクセスログを構成する
次に、デフォルトのログ構成(Nginxがすべてのリクエストに対して1つのアクセスログファイルを保存する)をオーバーライドし、代わりにNginxがクリーンなNginxインストールに付属するデフォルトのサーバーブロック用に個別のログファイルを保存するようにします。 CentOS 7 チュートリアルでNginxサーバーブロック(仮想ホスト)を設定する方法を読むことで、Nginxサーバーブロックに精通することができます。
サーバーブロックごとに個別のログファイルを保存して、さまざまなWebサイトのログを互いに効果的に分離することをお勧めします。 これにより、ログファイルが小さくなるだけでなく、重要なことに、ログを分析してエラーや疑わしいアクティビティを見つけやすくなります。
デフォルトのNginxサーバーブロック構成を変更するには、サーバーブロックNginx構成ファイルを開きます。 vi
(これは、vi’に慣れていない場合に備えて、の簡単な紹介です)またはお気に入りのテキストエディタです。
- sudo vi /etc/nginx/nginx.conf
を見つける server
次のような構成ブロック:
. . .
server {
listen 80 default_server;
listen [::]:80 default_server;
. . .
赤でマークされた2行を構成に追加します。
. . .
server {
listen 80 default_server;
listen [::]:80 default_server;
access_log /var/log/nginx/default-access.log;
error_log /var/log/nginx/default-error.log;
. . .
The access_log
ディレクティブは、アクセスログが保存されるファイルへのパスを設定します。 error_log
エラーログについても同じことを行います。 デフォルトのNginxログと同じディレクトリを使用します(/var/log/nginx
)、ただしファイル名が異なります。 複数のサーバーブロックがある場合は、ファイル名にドメイン名を使用するなど、一貫性のある意味のある方法でログファイルに名前を付けることをお勧めします。
ファイルを保存して閉じ、終了します。
注:サーバーブロックごとに個別のログファイルを維持するには、Nginx構成で新しいサーバーブロックを作成するたびに、前述の構成変更を適用する必要があることに注意してください。
新しい構成を有効にするには、Nginxを再起動します。
- sudo systemctl restart nginx
新しい構成をテストするには、空のテストファイルに対して以前と同じリクエストを実行します。
- curl -i http://localhost/empty.test
前に見たものと同じログ行が、構成したばかりの別のファイルに書き込まれていることを確認します。
- sudo tail /var/log/nginx/default-access.log
次のステップでは、この新しいファイルのログの形式をカスタマイズし、追加情報を含めます。
手順4—カスタムログ形式の構成
ここでは、カスタムログ形式を設定してNginxログに追加情報(リクエストの処理にかかった時間)を作成し、この新しい形式を使用するようにデフォルトのサーバーブロックを構成します。
使用する前に、新しいログ形式を定義する必要があります。 Nginxでは、各ログ形式に一意の名前があり、サーバー全体でグローバルです。 個々のサーバーブロックは、名前を参照するだけで、後でこれらの形式を使用するように構成できます。
新しいログ形式を定義するには、という新しい構成ファイルを作成します。 timed-log-format.conf
Nginxの追加の構成ディレクトリにあります。
- sudo vi /etc/nginx/conf.d/timed-log-format.conf
次の内容を追加します。
log_format timed '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" "$http_x_forwarded_for" $request_time';
ファイルを保存して閉じ、終了します。
The log_format
設定ディレクティブは、新しいログ形式を定義します。 次の要素は、この形式の一意の識別子です。 ここではtimedを使用していますが、任意の名前を選択できます。
次は、読みやすくするために3行に分割されたログ形式自体です。 Nginxは、ドル記号が前に付いた名前付きシステム変数のすべてのリクエストに関する情報を公開します。 これらは、リクエストの詳細をアクセスログに書き込むときに、リクエストに関する実際の情報に置き換えられます(例: $request_addr
訪問者のIPアドレスに置き換えられます)。
上記の形式は、前に説明した共通ログ形式と同じですが、1つの違いがあります。 $request_time
最後にシステム変数。 Nginxはこの変数を使用して、リクエストにかかった時間をミリ秒単位で保存します。この変数をログ形式で使用することにより、Nginxにその情報をログファイルに書き込むように指示します。
これで、 timed という名前のカスタムログ形式がNginx構成で定義されましたが、デフォルトのサーバーブロックはまだこの形式を使用していません。 次に、サーバーブロックのNginx構成ファイルを開きます。
- sudo vi /etc/nginx/nginx.conf
を見つける server
以前に変更して追加した構成ブロック timed
フォーマット名をログに記録します access_log
以下の赤で強調表示されている設定:
. . .
server {
listen 80 default_server;
listen [::]:80 default_server;
access_log /var/log/nginx/default-access.log timed;
error_log /var/log/nginx/default-error.log;
. . .
ファイルを保存して閉じ、終了します。
新しい構成を有効にするには、Nginxを再起動します。
- sudo systemctl restart nginx
すべてがセットアップされたので、それが機能することを確認しましょう。
ステップ5—新しい構成を確認する
Nginxにいくつかのリクエストを呼び出すことで、新しい構成をテストできます。 curl
、ステップ2で行ったように。 今回は、手順1で作成したサンプルファイルを使用します。
- curl -i http://localhost/empty.test
- curl -i http://localhost/1mb.test
- curl -i http://localhost/10mb.test
- curl -i http://localhost/100mb.test
ファイルが大きくなり、転送に時間がかかるため、後続の各コマンドの実行に時間がかかることがわかります。
これらのリクエストを実行した後、アクセスログを表示してみましょう。
- sudo tail /var/log/nginx/default-access.log
ログにはさらに多くの行が含まれますが、最後の4つは実行したばかりのテスト要求に対応します。
::1 - - [05/Aug/2016:22:14:04 +0000] "GET /empty.test HTTP/1.1" 200 0 "-" "curl/7.29.0" "-" 0.000
::1 - - [05/Aug/2016:22:14:04 +0000] "GET /1mb.test HTTP/1.1" 200 1048576 "-" "curl/7.29.0" "-" 0.000
::1 - - [05/Aug/2016:22:14:07 +0000] "GET /10mb.test HTTP/1.1" 200 10485760 "-" "curl/7.29.0" "-" 2.063
::1 - - [05/Aug/2016:22:15:10 +0000] "GET /100mb.test HTTP/1.1" 200 104857600 "-" "curl/7.29.0" "-" 47.318
パスは毎回異なり、正しいファイル名が表示され、リクエストサイズは毎回増加します。 重要な部分は、最後に強調表示された数値です。これは、カスタムログ形式で構成したばかりの要求処理時間(ミリ秒単位)です。 ご想像のとおり、ファイルが大きくなるほど、転送に時間がかかります。
その場合は、Nginxでカスタムログ形式を正常に構成しています。
結論
大きなファイルの転送に時間がかかることを確認することは特に有用ではありませんが、Nginxを使用して動的なWebサイトを提供する場合、リクエストの処理時間は非常に役立ちます。 Webサイトのボトルネックを追跡し、必要以上に時間がかかったリクエストを簡単に見つけるために使用できます。
$request_time
は、カスタムロギング構成で使用できるNginxが公開する多くのシステム変数の1つにすぎません。 その他には、たとえば、クライアントへの応答とともに送信される応答ヘッダーの値が含まれます。 ログ形式に他の変数を追加するのは、私たちが行ったのと同じように、それらをログ形式の文字列に入れるのと同じくらい簡単です。 $request_time
. これは、Webサイトのロギングを構成するときに有利に使用できる強力なツールです。
Nginxログ形式で使用できる変数のリストは、Nginxのログモジュールのドキュメントで説明されています。