ステータス:非推奨

この記事では、サポートされなくなったバージョンのUbuntuについて説明します。 現在Ubuntu12.04を実行しているサーバーを運用している場合は、サポートされているバージョンのUbuntuにアップグレードまたは移行することを強くお勧めします。

理由:
Ubuntu 12.04は2017年4月28日に保守終了(EOL)に達しました and no longer receives security patches or updates. This guide is no longer maintained.

代わりに参照してください:
このガイドは参照として役立つ場合がありますが、他のUbuntuリリースでは機能しない場合があります。 可能な場合は、使用しているUbuntuのバージョン用に作成されたガイドを使用することを強くお勧めします。 ページ上部の検索機能を使用して、より新しいバージョンを見つけることができます。

序章

Apache Webサーバーは、サーバー管理者に、サーバーの機能と、対処する必要のある問題(ある場合)に関する重要な情報を提供するように構成できます。

管理者にフィードバックを提供する主な方法は、ログファイルを使用することです。 Apacheには、指示に基づいてさまざまな場所にメッセージを出力するために使用できる、非常に構成可能なロギングメカニズムがあります。

このガイドでは、Apacheのロギング機能を利用して、構造化された、解析しやすいログを設定する方法について説明します。 Ubuntu12.04VPSではデフォルトのApache2インストールを使用します。 他のディストリビューションも同様に動作するはずです。

Apacheログレベル

Apacheは、情報を考慮する重要性に応じて、すべての情報メッセージをカテゴリに分類します。

たとえば、緊急事態と見なされる最も重要なメッセージの場合、Apacheはログレベルを「emerg」として指定します。 一方、「info」タグは、たまに見るのに役立つ情報を表示するだけです。

Apacheが認識するログレベルは、最も重要なものから最も重要でないものまで、次のとおりです。

  • emerg :システムが使用できない状態にある緊急事態。
  • alert :迅速に対応が必要な深刻な状況。
  • crit :対処する必要のある重要な問題。
  • エラー:エラーが発生しました。 何かが失敗しました。
  • 警告:通常とは異なる何かが発生しましたが、心配する必要はありません。
  • 注意:何か正常ですが、注目に値することが起こりました。
  • info :知っておくと便利な情報メッセージ。
  • debug :問題が発生している場所を特定するのに役立つデバッグ情報。
  • trace [1-8] :大量の情報を生成するさまざまなレベルの冗長性の情報をトレースします。

ログレベルを指定する場合、そのカテゴリでラベル付けされたメッセージをログに記録することを選択するのではなく、ログに記録する最も重要度の低いレベルを選択することになります。

これは、選択したレベルより上のレベルもログに記録されることを意味します。 たとえば、「警告」ログレベルを選択すると、警告、エラー、クリティカル、アラート、および緊急のタグが付けられたメッセージがすべてログに記録されます。

「LogLevel」ディレクティブを使用して、必要なロギングのレベルを指定します。 デフォルトのログレベルは、デフォルトの構成ファイルで確認できます。

sudo nano /etc/apache2/apache2.conf
. . .
LogLevel warn
. . .

ご覧のとおり、デフォルトでは、「警告」以上の優先度でメッセージをログに記録するようにApacheが構成されています。 次のセクションでは、Apacheがメッセージをログに記録する場所について学習します。

Apacheはログをどこに保持しますか?

Apacheは、サーバー全体のログ仕様を使用して、ログを配置する場所を知ることができます。 個別の仮想ホストごとに個別にロギングを構成することもできます。

サーバー全体のロギング

サーバーがデフォルトで情報をログに記録する場所を見つけるために、デフォルトの構成ファイルを開くことができます。 Ubuntuでは、これは「/etc/apache2/apache2.conf」です。

sudo nano /etc/apache2/apache2.conf

ファイルを検索すると、次のような行が見つかります。

ErrorLog ${APACHE_LOG_DIR}/error.log

このディレクティブは、Apacheがエラーメッセージを保持するファイルに名前を付けます。 ご覧のとおり、「APACHE_LOG_DIR」という環境変数を使用して、ディレクトリパスのプレフィックスを取得します。

「APACHE_LOG_DIR」が何に設定されているかは、別のファイル、適切な名前の「envvars」ファイルを調べることでわかります。

sudo nano /etc/apache2/envvars
. . .
export APACHE_LOG_DIR=/var/log/apache2$SUFFIX
. . .

この行から、「APACHE_LOG_DIR」変数がディレクトリ「/ var / log/apache2」に設定されていることがわかります。 これは、「apache2.conf」ファイルのディレクティブと組み合わせると、Apacheが「/var/log/apache2/error.log」というファイルにログインすることを意味します。

sudo ls /var/log/apache2
access.log  error.log  other_vhosts_access.log

error.logファイルと他のいくつかのログファイルも見ることができます。

仮想ホストロギング

前のセクションの最後にある「access.log」ファイルは、「apache2.conf」ファイルでは構成されていません。 代わりに、パッケージメンテナは、仮想ホスト定義内での使用を指定するディレクティブを配置することを決定しました。

デフォルトの仮想ホスト定義を調べて、アクセスログ宣言を確認します。

sudo nano /etc/apache2/sites-available/default

ファイルをスクロールすると、ロギングに関する3つの個別の値が表示されます。

. . .
ErrorLog ${APACHE_LOG_DIR}/error.log

LogLevel warn

CustomLog ${APACHE_LOG_DIR}/access.log combined
. . .

ErrorLog定義は、デフォルトの構成ファイルの定義と一致します。 両方の場所にその線を引く必要はありませんが、ある場所または別の場所で場所を変更する場合に備えて、特定することは問題ありません。

カスタムログの定義

前のセクションで、「access.log」ファイルを説明する行は、前のログ行とは異なるディレクティブを使用しています。 「CustomLog」を使用して、access.logの場所を指定します。

CustomLog ${APACHE_LOG_DIR}/access.log combined

このディレクティブは次の構文を取ります。

CustomLog log_location log_format

この例のログ形式は「結合」です。 これはApacheの内部仕様ではありません。 代わりに、これはデフォルトの構成ファイルで定義されているカスタム形式のラベルです。

デフォルトの構成ファイルを再度開くと、「結合された」ログ形式を定義する行が表示されます。

sudo nano /etc/apache2/apache2.conf
. . .
LogFormat "%h %l %u %t \"%r\" %>s %O \"{Referer}i\" \"%{User-Agent}i\"" combined
. . .

「LogFormat」コマンドは、仮想ホスト定義で見たように、「CustomLog」ディレクティブを使用して呼び出すことができるログのカスタム形式を定義します。

このログ形式は、「結合」形式と呼ばれる形式を指定します。 使用可能なフォーマット文字列変数の詳細については、こちらをご覧ください。

ご覧のとおり、仮想ホスト定義内で使用するために作成された他のいくつかの一般的な形式があります。 以前のCustomLog宣言とまったく同じように使用できます。 独自のカスタムログ形式を作成することもできます。

Apacheログファイルのローテーション

Apacheは、クライアントからのリクエストを処理する過程で大量の情報をログに記録できるため、ログをローテーションするシステムを設定する必要があります。

ログのローテーションは、ログが大きくなりすぎたときにログを切り替えるだけの簡単なものにすることも、古いコピーをアーカイブして保存し、後日参照できるようにするシステムにすることもできます。 これは構成によって異なります。

以下では、これを実現するためのいくつかの異なる方法について説明します。

ログを手動でローテーションする

Apacheの実行中はログファイルを移動できないため、代わりに、古いログを新しいログと交換するためにサーバーを再起動する必要があります。

これは、ファイルを移動してからApacheをソフトリスタートして、新しい接続に新しいログの使用を開始できるようにすることで、手動で実行できます。

Apacheのドキュメントで使用されている例はここにあります。 適切な特権を取得するには、これらのコマンドの前に「sudo」を付ける必要がある場合があります。

mv access_log access_log.old
mv error_log error_log.old
apachectl graceful
sleep 600
[post-processing of log files]

これにより、ファイルが移動され、サーバーがリロードされ、600秒待機します。 これにより、Apacheは引き続き古いログファイルを使用して、古いリクエストからのログ記録を完了できます。 この間、新しいリクエストは新しく更新されたファイルに記録されます。

これを手動で行う方法を知っておくのは良いことですが、これは大規模なサーバー環境では持続不可能です。

Logrotateを使用したログローテーションの管理

デフォルトでは、Ubuntuはlogrotateを使用して独自のログローテーションプランを設定します。

このプログラムは、特定の基準が満たされたときにパラメーターを受け取り、ログをローテーションできます。 「/etc/logrotate.d/apache2」を調べると、logrotateがApacheログをスワップする原因となるイベントを確認できます。

sudo nano /etc/logrotate.d/apache2

ここでは、logrotateに与えられたパラメーターのいくつかを見ることができます。 まず、最初の行が次のとおりであることに注意してください。

/var/log/apache2/*.log {

これは、logrotateが「/ var / log/apache2」内のログに対してのみ動作することを意味します。 Apache構成でログに別のディレクトリを選択した場合は、このことに注意してください。

ログは毎週ローテーションされ、デフォルトで1年分のログが保存されていることがわかります。 また、ローテーション後にApacheをリロードするセクションがあることもわかります。

postrotate
	/etc/init.d/apache2 reload > /dev/null
endscript

これらの行は、回転が完了するたびにapacheが自動的に再ロードされることを確認します。 このファイル内のパラメーターは自由に変更できますが、構成はこの記事の範囲外です。

パイプを使用したロギング

ファイルの代わりにパイプを使用すると、別のロギングプログラムで出力を処理できるようになります。 これにより、ログローテーションの問題も解決されます。これは、Apache自体ではなくバックエンドロギングプログラムで処理できるためです。

アクセスログを標準入力を受け入れるロギングプログラムで処理する場合は、行を次のように変更できます。

CustomLog "| logging_program logging_program_parameters" combined

Apacheは、開始時にロギングプログラムを開始し、何らかの理由でロギングプロセスが失敗した場合は再起動します。

ログをローテーションするように複数のプログラムを構成できますが、Apacheにはデフォルトで「rotatelogs」と呼ばれるプログラムが含まれています。 次のように構成できます。

CustomLog "| /path/to/rotatelog /path/of/log/to/rotate number_of_seconds_between_rotations" log_level

同様の構成は、他のロギングユーティリティでも実現できます。

結論

サーバーを正しく管理するために必要なすべてのログを記録していること、およびファイルが大きくなりすぎないようにするための適切なログローテーションメカニズムを備えていることが重要です。

これで、Apacheのロギングを作成および構成する方法を理解する必要があります。 ログに記録した情報を使用して、問題のトラブルシューティングを行い、いつアクションを実行する必要があるかを予測できます。

ジャスティン・エリングウッド