前書き

サーバー管理は、サービスの初期構成だけではありません。 また、これらのサービスを監視し、可能な限りスムーズに実行されるようにすることも必要です。 管理者にとって最も重要な知識源の1つは、システムイベントに関する情報を含むログファイルです。

NginxのようなWebサーバーの場合、ログにはWebサーバーを介してリソースにアクセスしようとする各試行に関する貴重な情報が含まれています。 各Webサイトの訪問者と見た画像またはダウンロードしたファイルは、ログに細心の注意を払って登録されます。 エラーが発生すると、エラーもログに保存されます。 適切に構造化されたログファイルを使用する方がはるかに簡単です。

このガイドでは、Nginxのログモジュールの利用方法について説明します。 サーバーブロックごとに個別のログファイルを設定し、ログ出力をカスタマイズします。 また、リクエストに関する追加情報(このチュートリアルの例ではリクエストの処理にかかる時間)をNginxにデフォルトで含まれているものを超えてアクセスログに追加します。

前提条件

このチュートリアルを実行するには、次のものが必要です。

ステップ1-テストファイルの作成

このステップでは、デフォルトのNginx Webサイトディレクトリにいくつかのテストファイルを作成します。 これらを使用して、ロギング構成をテストします。

Nginx(または他のWebサーバー)がファイルのHTTPリクエストを受信すると、そのファイルを開き、そのコンテンツをネットワーク経由で転送することでユーザーに提供します。 ファイルが小さいほど、高速で転送できます。 ファイルが完全に転送されると、要求は完了したと見なされ、その後のみ転送がログに記録されます。

このチュートリアルの後半では、ロギング構成を変更して、各リクエストにかかった時間に関する有用な情報を含めます。 変更された構成をテストし、さまざまな要求の違いに気付く最も簡単な方法は、さまざまな時間で送信されるさまざまなサイズの複数のテストファイルを作成することです。

`+ truncate `を使用して、デフォルトのNginxディレクトリに ` 1mb.test +`という名前の1メガバイトのファイルを作成しましょう。

sudo truncate -s 1M /usr/share/nginx/html/1mb.test

同様に、最初に10メガバイト、次に100メガバイトのサイズの異なる2つのファイルを作成し、それに応じて名前を付けます。

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応答ヘッダーが表示されるはずです。

Nginx応答ヘッダー

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サーバーで一般的に使用されるアクセスログの標準形式です。 この形式では、各情報は単一のスペースで区切られます。ハイフンは情報の欠落部分を表します。

左から順に、カテゴリは次のとおりです。

  • リソースを要求したユーザーの* IPアドレス*。 `+ curl `をローカルで使用したため、アドレスはローカルホストの ` :: 1 +`を指します。

  • *リモートロギング*情報。 Nginxはこの情報をサポートしていないため、これは常にハイフンになります。

  • HTTP基本認証に基づくログインユーザーの*ユーザー名*。 これはすべての匿名リクエストに対して空になります。

  • リクエスト日。 これは、応答ヘッダーの日付と一致することがわかります。

  • リクエストメソッド( + GET +)、リクエストされたファイルへのパス( + / empty.text +)、使用されたプロトコル( + HTTP / 1.1 +)を含む*リクエストパス*。

  • 応答ステータスコード。これは成功を意味する「+200 OK +」でした。

  • 転送されたファイルの長さ。ファイルが空だったため、ここでは「0」です。

  • * HTTP Refererヘッダー*。リクエストの発信元のドキュメントのアドレスが含まれます。 この例では空ですが、これが画像ファイルである場合、リファラーは画像が使用されたページを指します。
    + HTTP Refererヘッダーは、「referrer」という単語のスペルミスです。これは、HTTPの起源にまで遡り、HTTP標準の一部です。

  • ユーザーエージェント。ここでは、 `+ curl +`です。

  • ここで空の* X-Forwarded-For *ヘッダー。元のリクエストがプロキシを介して転送された場合のソースIPアドレスに関する情報が含まれます。

アクセスログの1つのログエントリにも、リクエストに関する多くの貴重な情報が含まれています。 ただし、1つの重要な情報が欠落しています。 `+ http:// localhost / empty.test `の正確な場所をリクエストしましたが、 ` / empty.test `ファイルへのパスのみがログエントリにあります。ホスト名に関する情報(ここでは、「 localhost +」)は失われます。

手順3-別のアクセスログの構成

次に、デフォルトのロギング設定(Nginxはすべてのリクエストに対して1つのアクセスログファイルを保存する)をオーバーライドし、代わりにNginxをクリーンNginxインストールに付属するデフォルトサーバーブロック用に個別のログファイルを保存します。 Nginxサーバーブロックについて詳しく知るには、https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-server-blocks-on-centos-7 [Nginxのセットアップ方法]を読んでください。 CentOS 7上のサーバーブロック(仮想ホスト)]チュートリアル。

サーバーブロックごとに個別のログファイルを保存し、異なるWebサイトのログを互いに効果的に分離することをお勧めします。 これにより、ログファイルが小さくなるだけでなく、ログを分析しやすくなり、エラーや疑わしいアクティビティを見つけやすくなります。

デフォルトのNginxサーバーブロック設定を変更するには、 + vi +`でサーバーブロックNginx設定ファイルを開きます(https://www.digitalocean.com/community/tutorials/installing-and-using-the-vim-text -editor-on-a-cloud-server#modal-editing [よく知らない場合のために、 `+ vi + ‘の簡単な紹介]またはお気に入りのテキストエディター。

sudo vi /etc/nginx/nginx.conf

次のような `+ server +`設定ブロックを見つけます。

/etc/nginx/nginx.conf

. . .
server {
   listen       80 default_server;
   listen       [::]:80 default_server;
. . .

赤でマークされた2行を構成に追加します。

/etc/nginx/nginx.conf

. . .
server {
   listen 80 default_server;
   listen [::]:80 default_server;



. . .

+ access log`ディレクティブはアクセスログが保存されるファイルへのパスを設定し、 + error_log`はエラーログに対して同じことを行います。 デフォルトのNginxログ( + / var / log / nginx +)と同じディレクトリを使用しますが、ファイル名は異なります。 複数のサーバーブロックがある場合は、ファイル名にドメイン名を使用するなど、一貫性のある意味のある方法でログファイルに名前を付けることをお勧めします。

ファイルを保存して閉じ、終了します。

新しい構成を有効にするには、Nginxを再起動します。

sudo systemctl restart nginx

新しい構成をテストするには、空のテストファイルに対して以前と同じリクエストを実行します。

curl -i http://localhost/empty.test

前に見たものと同じログ行が、今設定した別のファイルに書き込まれていることを確認します。

sudo tail /var/log/nginx/default-access.log

次のステップでは、この新しいファイルのログの形式をカスタマイズし、追加情報を含めます。

手順4-カスタムログ形式の構成

ここでは、カスタムロギングフォーマットを設定して、Nginxに追加情報(リクエストの処理にかかった時間)を追加し、この新しいフォーマットを使用するようにデフォルトのサーバーブロックを構成します。

新しいログ形式を使用する前に定義する必要があります。 Nginxでは、各ログ形式には一意の名前があり、サーバー全体でグローバルです。 個々のサーバーブロックは、名前を参照するだけで、後でこれらの形式を使用するように構成できます。

新しいログ形式を定義するには、Nginxの追加の設定ディレクトリに「+ timed-log-format.conf +」という新しい設定ファイルを作成します。

sudo vi /etc/nginx/conf.d/timed-log-format.conf

次の内容を追加します。

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

ファイルを保存して閉じ、終了します。

`+ log_format +`設定ディレクティブは、新しいログ形式を定義します。 次の要素は、この形式の一意の識別子です。ここでは* timed *を使用していますが、任意の名前を選択できます。

次はログ形式そのもので、読みやすいように3行に分割されています。 Nginxは、ドル記号で始まる名前付きシステム変数のすべてのリクエストに関する情報を公開します。 これらは、リクエストの詳細をアクセスログに書き込むときに、リクエストに関する実際の情報に置き換えられます(たとえば、「+ $ request_addr +」は訪問者のIPアドレスに置き換えられます)。

上記の形式は、前述のCommon Log Formatと同じですが、違いは1つだけです。最後にシステム変数 `+ $ request_time +`を追加します。 Nginxはこの変数を使用してリクエストにミリ秒単位でかかった時間を保存し、この変数をログ形式で使用することにより、その情報をログファイルに書き込むようにNginxに指示します。

Nginx構成で* timed *という名前のカスタムログ形式が定義されましたが、デフォルトのサーバーブロックはまだこの形式を使用していません。 次に、サーバーブロックNginx構成ファイルを開きます。

sudo vi /etc/nginx/nginx.conf

先に修正した「+ server 」設定ブロックを見つけ、以下の赤で強調表示されているように、「 timed 」ログ形式名を「 access_log +」設定に追加します。

/etc/nginx/nginx.conf

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

ファイルを保存して閉じ、終了します。

新しい構成を有効にするには、Nginxを再起動します。

sudo systemctl restart nginx

すべての設定が完了したので、動作することを確認しましょう。

手順5-新しい構成の確認

手順2で行ったように、 `+ curl +`でNginxにいくつかのリクエストを呼び出すことで、新しい構成をテストできます。 今回は、手順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" "-"
::1 - - [05/Aug/2016:22:14:04 +0000] "GET /1mb.test HTTP/1.1" 200 1048576 "-" "curl/7.29.0" "-"
::1 - - [05/Aug/2016:22:14:07 +0000] "GET /10mb.test HTTP/1.1" 200 10485760 "-" "curl/7.29.0" "-"
::1 - - [05/Aug/2016:22:15:10 +0000] "GET /100mb.test HTTP/1.1" 200 104857600 "-" "curl/7.29.0" "-"

パスが毎回異なり、正しいファイル名が表示され、リクエストのサイズが毎回増加することがわかります。 重要な部分は、最後に強調表示された数値です。これは、カスタムログ形式で構成したミリ秒単位のリクエスト処理時間です。 ご想像のとおり、ファイルが大きくなるほど、転送に時間がかかります。

その場合、Nginxでカスタムログ形式を正常に設定しました!

結論

大きなファイルの転送に時間がかかることは特に有用ではありませんが、リクエストの処理時間は、Nginxを使用して動的なWebサイトを提供する場合に非常に役立ちます。 Webサイトのボトルネックをトレースし、必要以上に時間がかかったリクエストを簡単に見つけるために使用できます。

`+ $ request_time `は、カスタムロギング設定で使用できるNginxが公開する多くのシステム変数の1つにすぎません。 その他には、たとえば、クライアントへの応答とともに送信される応答ヘッダーの値が含まれます。 他の変数をログ形式に追加するのは、 ` $ request_time +`で行ったように、それらをログ形式の文字列に入れるのと同じくらい簡単です。 これは、Webサイトのロギングを設定する際に有利に使用できる強力なツールです。

Nginxログ形式で使用できる変数のリストについては、http://nginx.org/en/docs/http/ngx_http_log_module.html [Nginxのログモジュールドキュメント]で説明されています。