サーバー管理は、サービスの初期構成だけではありません。また、これらのサービスを監視し、可能な限りスムーズに実行されるようにすることも含まれます。管理者にとって最も重要な知識源の1つは、システムイベントに関する情報を含むログファイルです。
Webサーバー（Nginxなど）の場合、ログには、Webサーバーを介してリソースにアクセスする各試行に関する貴重な情報が含まれます。すべてのWebサイト訪問者と、表示またはダウンロードされたファイルの画像は、ログに慎重に登録されます。エラーが発生すると、それらもログに保存されます。適切に構造化されたログファイルを使用する方がはるかに簡単です。
このガイドでは、Nginxのロギングモジュールの使用方法を学習します。サーバーブロックごとに個別のログファイルを設定してから、ログ出力をカスタマイズします。また、リクエストに関する追加情報をアクセスログに追加します（このチュートリアルの例では、追加情報はリクエストの処理に必要な時間です）。これは、Nginxにデフォルトで含まれているものを超えています。
このチュートリアルに従うには、次のものが必要です。
このステップでは、デフォルトのNginxWebサイトディレクトリに複数のテストファイルを作成します。それらを使用して、ログ構成をテストします。
Nginx（またはその他のWebサーバー）がファイルのHTTP要求を受信すると、ファイルを開き、そのコンテンツをネットワーク経由で送信してユーザーに提供します。ファイルが小さいほど、転送速度は速くなります。ファイルが完全に転送されると、リクエストは完了したと見なされ、レコードが転送されます。
このチュートリアルの後半で、ロギング構成を変更して、各リクエストにかかる時間に関する有用な情報を含めます。変更された構成をテストし、異なる要求間の違いに注意を払う最も簡単な方法は、異なるサイズの複数のテストファイルを作成することです。これらは、異なる時間に転送されます。
truncateを使用して、デフォルトのNginxディレクトリに 1mb.testという名前の1メガバイトのファイルを作成しましょう。
sudo truncate -s 1M /var/www/html/1mb.test
同様に、サイズの異なる2つのファイルを、最初に10メガバイト、次に100メガバイト作成し、それに応じて名前を付けます。
sudo truncate -s 10M /var/www/html/10mb.test
sudo truncate -s 100M /var/www/html/100mb.test
最後になりましたが、空のファイルを作成しましょう。
sudo touch /var/www/html/empty.test
次のステップでは、これらのファイルを使用してログファイルにデフォルト構成を入力し、このチュートリアルの後半でカスタマイズされた構成を示します。
ロギングモジュールはコア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.1200 OK
Server: nginx/1.10.0(Ubuntu)
Date: Thu,30 Jun 201618:10:15 GMT
Content-Type: application/octet-stream
Content-Length:0
Last-Modified: Thu,30 Jun 201618:10:07 GMT
Connection: keep-alive
ETag:"5775607f-0"
Accept-Ranges: bytes
この応答を通じて、次のことを理解できます。
HTTP / 1.1 200 OKは、Nginxが 200 OKステータスコードで応答すると、エラーがないことを示します。 Content-Length：0は、返されるドキュメントの長さがゼロであることを意味します。これがNginxがアクセスログに保存するものと一致するかどうかを見てみましょう。ログファイルは管理ユーザーのみが読み取ることができるため、ログファイルにアクセスするにはsudoを使用する必要があります。
sudo tail /var/log/nginx/access.log
ログには、以前に投稿したテストリクエストに対応するこのような行が含まれます。
127.0.0.1- - [30 /Jun/2016:14:10:15-0400]"GET /empty.test HTTP/1.1"2000"-""curl/7.47.0"
Nginxは、結合ログ形式を使用します。これは、Webサーバーが相互運用性のために頻繁に使用するアクセスログの標準形式です。この形式では、各情報はスペースで区切られます。ハイフンは欠落している情報を表します。
左から右へ、カテゴリは次のとおりです。
curlを使用するため、アドレスはローカルホスト（ 127.0.0.1）を指します。GET）、パスによってリクエストされたファイル（ / empty.text）、および使用されたプロトコル（ HTTP / 1.1）が含まれます。200 OKで、成功を意味します。curlです。アクセスログの1つのログエントリでさえ、リクエストに関する多くの貴重な情報が含まれています。ただし、重要な情報が欠落している場合は、 http：// localhost / empty.testの正確な場所を要求しましたが、ログエントリには / empty.testファイルのパスのみが含まれています。ここの localhostの情報も失われます。
次に、デフォルトのログ構成を上書きし（Nginxはすべての要求のアクセスログファイルを保存します）、クリーンなNginxインストールに付属するデフォルトのサーバーブロック用に別のログファイルをNginxに保存させます。 [Tencent Cloud + Community]（https://cloud.tencent.com/developer?from=10680）の関連記事を読むことで、Nginxサーバーブロックに慣れることができます。
サーバーブロックごとに個別のログファイルを保存することをお勧めします。これにより、さまざまなWebサイトのログを互いに効果的に分離できます。これにより、ログファイルが小さくなるだけでなく、重要なことに、ログを分析してエラーや疑わしいアクティビティを見つけやすくなります。
デフォルトのNginxサーバーブロック構成を変更するには、サーバーブロックNginx構成ファイルを nanoまたはその他の任意のテキストエディターで開きます。
sudo nano /etc/nginx/sites-available/default
以下に示すように、 server構成ブロックを見つけます。
...
# Default server configuration
#
server {
listen 80 default_server;
listen [::]:80 default_server;
...
そして、最後の2行を構成に追加します。
...
# Default server configuration
#
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;...
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
次のステップでは、この新しいファイルのログ形式をカスタマイズし、その他の情報を含めます。
ここでは、Nginxが他の情報（要求の処理にかかる時間）をログに記録するようにカスタムログ形式を設定し、この新しい形式を使用するようにデフォルトのサーバーブロックを構成します。
使用する前に、新しいログ形式を定義する必要があります。 Nginxでは、各ログ形式に一意の名前があり、サーバー全体に対してグローバルです。個々のサーバーブロックは、後で名前を引用するだけでこれらの形式を使用するように構成できます。
新しいロギング形式を定義するには、Nginx追加構成ディレクトリに timed-log-format.confという名前の新しい構成ファイルを作成します。
sudo nano /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" $request_time';
ファイルを保存して閉じ、終了します。
log_format設定命令は、新しいログ形式を定義します。次の要素は、この形式の一意の識別子です。ここではタイミングを使用しますが、任意の名前を選択できます。
次は、読みやすくするために3行に分割されたログ形式自体です。 Nginxは、ドル記号で始まる名前付きシステム変数のすべての要求に関する情報を開示します。リクエストの詳細をアクセスログに書き込むと、これらはリクエストに関する実際の情報に置き換えられます（たとえば、 $ request_addrは訪問者のIPアドレスに置き換えられます）。
上記の形式は、前に説明した一般的なログ形式と同じですが、1つだけ違いがあります。最後に、 $ request_timeシステム変数が追加されます。 Nginxはこの変数を使用して、要求にかかった時間（ミリ秒単位）を格納します。この変数をログ形式で使用することにより、この情報をログファイルに書き込むようにNginxに指示します。
これで、Nginx構成で** timed **というカスタムログ形式を定義しましたが、デフォルトのサーバーブロックではまだこの形式を使用していません。次に、サーバーブロックのNginx構成ファイルを開きます。
sudo nano /etc/nginx/sites-available/default
以前に変更した構成ブロック serverを見つけ、 timedログ形式の名前を access_log設定に追加します。
...
# Default server configuration
#
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
すべてがセットアップされたので、それが機能するかどうかを確認しましょう。
手順2で行ったように、Nginxにいくつかのリクエストを呼び出すことで、新しい構成 curlをテストできます。今回は、手順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行は実行したばかりのテスト要求に対応します。
127.0.0.1- - [04 /Jul/2016:14:57:02-0400]"GET /empty.test HTTP/1.1"2000"-""curl/7.47.0"0.000127.0.0.1--[04/Jul/2016:14:57:51-0400]"GET /1mb.test HTTP/1.1"2001048576"-""curl/7.47.0"0.000127.0.0.1--[04/Jul/2016:14:57:57-0400]"GET /10mb.test HTTP/1.1"20010485760"-""curl/7.47.0"1.901127.0.0.1--[04/Jul/2016:14:58:52-0400]"GET /100mb.test HTTP/1.1"200104857600"-""curl/7.47.0"49.232
パスは毎回異なり、正しいファイル名が表示され、各リクエストのサイズが大きくなることがわかります。重要な部分は、最後に強調表示されている数値です。これは、カスタムログ形式で構成したばかりの要求処理時間（ミリ秒単位）です。ご想像のとおり、ファイルが大きいほど、転送に時間がかかります。
この場合、Nginxでカスタムログ形式を正常に構成できています。
ファイルが大きいほど送信時間が長くなることを確認することは特に有用ではありませんが、Nginxを使用して動的なWebサイトを提供する場合、要求の処理時間は非常に役立ちます。 Webサイトのボトルネックを追跡し、必要以上に時間がかかるリクエストを簡単に見つけるために使用できます。
$ request_timeは、Nginxによって公開される多くのシステム変数の1つにすぎず、カスタムロギング構成で使用できます。その他には、たとえば、応答としてクライアントに送信される応答ヘッダーの値が含まれます。ログ形式に他の変数を追加するのは、 $ request_timeを追加するのと同じように、それらをログ形式の文字列に入れるのと同じくらい簡単です。これは、Webサイトのロギングを構成するときに使用できる強力なツールです。
[ Nginxログモジュールのドキュメント]（http://nginx.org/en/docs/http/ngx_http_log_module.html）には、Nginxログ形式で使用できる変数のリストが記載されています。
その他のUbuntuチュートリアルについては、[Tencent Cloud + Community]（https://cloud.tencent.com/developer?from=10680）にアクセスして詳細を確認してください。
参照：「Ubuntu16.04でログモジュールをNginxに追加する方法
Recommended Posts