Nginxにログインする
Webサーバーのトラブルを回避する最も簡単な方法の1つは、適切なログを今日構成することです。 サーバーに情報を記録すると、発生した状況のトラブルシューティングと評価に役立つデータにアクセスできます。
この記事では、Nginxのログ機能を調べ、ニーズに最適なツールを構成する方法を説明します。 このガイドでは、例としてUbuntu 12.04 VPSを使用しますが、最新のディストリビューションも同様に機能するはずです。
Error_logディレクティブ
Nginxは、いくつかの異なるディレクティブを使用してシステムロギングを制御します。 コアモジュールに含まれているものは「error_log」と呼ばれます。
Error_log構文
「error_log」ディレクティブは、一般的なエラーメッセージのログ記録を処理するために使用されます。 Apacheを使用している場合、これはApacheの「ErrorLog」ディレクティブと非常によく似ています。
error_logディレクティブは、次の構文を取ります。
error_log log_file [ log_level ]
この例の「log_file」は、ログが書き込まれるファイルを指定します。 「log_level」は、記録するロギングの最低レベルを指定します。
ロギングレベル
error_logディレクティブは、必要に応じて多かれ少なかれ情報をログに記録するように構成できます。 ロギングのレベルは、次のいずれかになります。
- emerg ：システムが使用できない状態にある緊急事態。
- alert ：迅速に対応が必要な深刻な状況。
- crit ：対処する必要のある重要な問題。
- エラー：エラーが発生しました。 何かが失敗しました。
- 警告：通常とは異なる何かが発生しましたが、心配する必要はありません。
- 注意：何か正常ですが、注目に値することが起こりました。
- info ：知っておくと便利な情報メッセージ。
- debug ：問題が発生している場所を特定するのに役立つデバッグ情報。
リストの上位レベルは、優先度が高いと見なされます。 レベルを指定すると、ログはそのレベルと、指定されたレベルよりも高いレベルをキャプチャします。
たとえば、「error」を指定すると、ログには「error」、「crit」、「alert」、および「emerg」というラベルの付いたメッセージがキャプチャされます。
メインの構成ファイルを見ると、このディレクティブが使用されていることがわかります。
sudo nano /etc/nginx/nginx.conf
. . . access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; . . .
error_logに何も記録させたくない場合は、出力を「/ dev/null」に送信する必要があります。
error_log /dev/null crit;
上記の他のロギングディレクティブである「access_log」ディレクティブについては、次のセクションで説明します。
HttpLogModuleロギングディレクティブ
error_logディレクティブはコアモジュールの一部ですが、access_logディレクティブはHttpLogModuleの一部です。 ログをカスタマイズする機能を提供します。
このモジュールには、カスタムログの構成を支援する他のいくつかのディレクティブが含まれています。
Log_formatディレクティブ
log_formatディレクティブは、プレーンテキストと変数を使用してログエントリの形式を記述するために使用されます。
Nginxで事前定義されている「combined」という形式が1つあります。 これは、多くのサーバーで使用される一般的な形式です。
これは、内部で定義されておらず、log_formatディレクティブで指定する必要がある場合に、結合された形式がどのようになるかを示しています。
log_format combined '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent"';
この定義は、セミコロン（;）が見つかるまで複数行にまたがっています。
ドル記号（$）で始まる部分は変数を示し、「-」、「[」、「]」などの文字は文字どおりに解釈されます。
コマンドの一般的な構文は次のとおりです。
log_format format_name string_describing_formatting;
コアモジュールでサポートされている変数を使用して、ロギング文字列を作成できます。
Access_logディレクティブ
access_logディレクティブは、error_logディレクティブと同様の構文を使用しますが、より柔軟性があります。 カスタムロギングを構成するために使用されます。
access_logディレクティブは、次の構文を使用します。
access_log /path/to/log/location [ format_of_log buffer_size ];
access_logのデフォルト値は、log_formatセクションで見た「結合」形式です。 log_format定義で定義された任意のフォーマットを使用できます。
バッファサイズは、すべてをログに書き込む前にNginxが保持するデータの最大サイズです。 定義に「gzip」を追加して、ログファイルの圧縮を指定することもできます。
access_log location format gzip;
error_logディレクティブとは異なり、ロギングが必要ない場合は、次のように指定してオフにすることができます。
access_log off;
この場合、「/ dev/null」に書き込む必要はありません。
ログローテーション
ログファイルが大きくなるにつれて、ディスク領域がいっぱいにならないようにログメカニズムを管理する必要があります。 ログローテーションは、ログファイルを切り替え、場合によっては古いファイルを一定時間アーカイブするプロセスです。
Nginxはログファイルを管理するためのツールを提供していませんが、ログローテーションを簡単にするメカニズムが含まれています。
手動ログローテーション
ログを手動でローテーションする（または、より可能性が高いのは、ログをローテーションするスクリプトを作成する）場合は、Nginxwikiの例に従ってください。
mv /path/to/access.log /path/to/access.log.0
kill -USR1 `cat /var/run/nginx.pid`
sleep 1
[ post-rotation processing of old log file ]
まず、現在のログをアーカイブ用の新しいファイルに移動します。 一般的なスキームは、最新のログファイルに「.0」のサフィックスを付けてから、古いファイルに「.1」などの名前を付けることです。
実際にログをローテーションするコマンドは「kill-USR1/var/run/nginx.pid」です。 これはNginxプロセスを強制終了しませんが、代わりにログファイルをリロードするシグナルを送信します。 これにより、新しいリクエストが更新されたログファイルに記録されます。
「/var/run/nginx.pid」ファイルは、Nginxがマスタープロセスのpidを保存する場所です。 これは、構成ファイルで「pid」で始まる行で指定されます。
sudo nano /etc/nginx/nginx.conf
. . . pid /path/to/pid/file; . . .
ローテーション後、「sleep 1」を実行して、プロセスが転送を完了できるようにします。 その後、古いファイルを圧縮するか、ローテーション後のプロセスを実行できます。
logrotateによるログローテーション
logrotateアプリケーションは、ログをローテーションするためのシンプルなプログラムです。 デフォルトでUbuntuにインストールされ、UbuntuのNginxにはカスタムlogrotateスクリプトが付属しています。
次のように入力すると、ログローテーションスクリプトが表示されます。
sudo nano /etc/logrotate.d/nginx
ファイルの最初の行は、後続の行が適用される場所を指定します。 Nginx構成ファイルにログインする場所を切り替える場合は、このことに注意してください。
ファイルの残りの部分では、ログが毎日ローテーションされ、52個の古いコピーが保持されることを指定しています。 logrotateの一般的な構成は、この記事の範囲外です。
「postrotate」セクションには、使用していた手動回転メカニズムと同様のコマンドが含まれていることがわかります。
postrotate [ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid` endscript
このセクションでは、ローテーションが完了したらログファイルをリロードするようにNginxに指示します。
結論
適切なログ構成と管理により、サーバーに問題が発生した場合の時間とエネルギーを節約できます。 問題の診断に役立つ情報に簡単にアクセスできることは、些細な修正と持続的な頭痛の違いになる可能性があります。
機能的なサイトを維持し、機密情報を公開しないようにするために、サーバーログを監視することが重要です。 このガイドは、ロギングの経験の紹介としてのみ役立つはずです。
