Return-Path: Delivered-To: apmail-httpd-cvs-archive@httpd.apache.org Received: (qmail 62920 invoked by uid 500); 12 Jul 2002 11:21:30 -0000 Mailing-List: contact cvs-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list cvs@httpd.apache.org Received: (qmail 62908 invoked by uid 500); 12 Jul 2002 11:21:30 -0000 Delivered-To: apmail-httpd-2.0-cvs@apache.org Date: 12 Jul 2002 11:21:30 -0000 Message-ID: <20020712112130.21635.qmail@icarus.apache.org> From: yoshiki@apache.org To: httpd-2.0-cvs@apache.org Subject: cvs commit: httpd-2.0/docs/manual dso.html.ja.jis logs.html.ja.jis dso.html logs.html X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N yoshiki 2002/07/12 04:21:30 Added: docs/manual dso.html.ja.jis logs.html.ja.jis Removed: docs/manual dso.html logs.html Log: New Japanese translations. Revision Changes Path 1.1 httpd-2.0/docs/manual/dso.html.ja.jis Index: dso.html.ja.jis =================================================================== Dynamic Shared Object (DSO) support

動的共有オブジェクト (DSO) サポート

Apache HTTP サーバはモジュール化されたプログラムで、管理者がモジュールを選択することでサーバに組み込む機能を選ぶことができます。モジュールはサーバがビルドされるときに httpd バイナリに静的に組み込むことができます。もしくは、httpd バイナリとは別に存在する動的共有オブジェクト (訳注: Dynamic Shared Object) (DSO) としてコンパイルすることもできます。DSO モジュールはサーバがビルドされるときにコンパイルしたり、 Apache 拡張ツール (apxs) を使って後でコンパイルして追加したりできます。

この文書は DSO モジュールの使い方と、その論理について説明します。

実装
使用法の概要
背景
利点と欠点

関連モジュール

mod_so

関連ディレクティブ

LoadModule

実装

個々の Apache モジュールをロードするための DSO サポートは mod_so.c というモジュールの機能に基づいています。このモジュールは Apache のコアに静的に組み込まれている必要があります。それは core.c 以外では DSO にできない唯一のモジュールです。事実上、他のすべての Apache のモジュールは、インストールの文書で説明されているように、 configure の --enable-module=shared オプションでそれぞれを DSO ビルドにすることにより、DSO モジュールにすることができます。 mod_foo.so のような DSO にモジュールがコンパイルされれば、 httpd.conf ファイル中で mod_so の LoadModule ディレクティブを使うことでサーバの起動や再起動時にこのモジュールをロードするようにできます。

Apache モジュール用の (特にサードパーティモジュールの) DSO ファイルの作成を簡単にするために、apxs (APache eXtenSion) という新しいサポートプログラムがあります。 Apache のソースツリーの外で DSO モジュールをビルドするために使うことができます。発想は単純です: Apache のインストール時の configure、make install のときに Apache の C ヘッダをインストールし、DSO ビルド用のプラットフォーム依存のコンパイラとリンカのフラグを apxs プログラムに追加します。これにより、ユーザが Apache の配布ソースツリーなしで、さらに DSO サポートのためのプラットフォーム依存のコンパイラやリンカのフラグをいじることなく Apache のモジュールのソースをコンパイルできるようになります。

使用法の概要

Apache 2.0 の DSO 機能の概略を知ることができるための、短く簡潔な概要です:

配布されている Apache モジュール、仮に mod_foo.c として、それを DSO mod_foo.so にビルド、インストール:
$ ./configure --prefix=/path/to/install --enable-foo=shared $ make install
サードパーティ Apache モジュール、仮に mod_foo.c として、それを DSO mod_foo.so にビルド、インストール:
$ ./configure --add-module=module_type:/path/to/3rdparty/mod_foo.c --enable-foo=shared $ make install
共有モジュールの 後々のインストール のために Apache を設定:
$ ./configure --enable-so $ make install
サードパーティ Apache モジュール、仮に mod_foo.c として、それを apxs を使って Apache ソースツリーの外で DSO にビルド、インストール:
$ cd /path/to/3rdparty $ apxs -c mod_foo.c $ apxs -i -a -n foo mod_foo.so

どの場合においても、共有モジュールをコンパイルした後で、 httpd.conf で LoadModule ディレクティブを使って Apache がモジュールを使用するようにしなければなりません。

背景

最近の Unix 系の OS には 動的共有オブジェクト (DSO) の動的リンク/ロードという気のきいた機構が存在します。これは、実行時にプログラムのアドレス空間にロードできるような特別な形式でプログラムをビルドすることを可能にします。

このロードは二つの方法で行なうことができます: 実行プログラムが起動されたときに lod.so というシステムプログラムにより自動的に行なわれる方法と、実行プログラム中から、システムコール dlopen()/dlsym() による Unix ローダへのプログラムシステムのインタフェースを使って手動で行なう方法とがあります。

最初の方法では DSO は普通は共有ライブラリや DSO ライブラリ と呼ばれていて、DSO の名前は libfoo.so や libfoo.so.1.2 のようになっています。これらはシステムディレクトリ (通常 /usr/lib) に存在し、実行プログラムへのリンクはビルド時に -lfoo をリンカに指定することで確立されます。これによりライブラリへの参照が実行プログラムのファイルに書き込まれて、起動時に Unix のローダが /usr/lib や、リンカの -R のようなオプションによりハードコードされたパス、環境変数 LD_LIBRARY_PATH により設定されたパス、の中から libfoo.so の場所を見つけることができます。それから、実行プログラム中の (まだ未解決の) シンボルを DSO にあるシンボルで解決します。

普通は実行プログラム中のシンボルは DSO からは参照されません (DSO は一般的なコードによる再利用可能なライブラリですので)。ですから、さらなるシンボルの解決は必要ありません。シンボルは Unix ローダにより完全な解決が行なわれますので、実行ファイル自身は何もする必要がありません。(実際のところ、静的でない方法でリンクされているすべての実行プログラムに組み込まれている開始用のコードの一部に ld.so を起動するコードが含まれています)。よく使われるライブラリの動的ロードの利点は明らかです。ライブラリのコードはシステムライブラリに libc.so のようにして一度保存するだけでよく、プログラムのために必要なディスクの領域を節約することができます。

二つめの方法では DSO は普通は共有オブジェクトや DSO ファイルと呼ばれていて、任意の拡張子を付けることができます (ただし、標準的な名前は foo.so です)。これらのファイルは通常はプログラム専用のディレクトリに置かれ、これらを使う実行プログラムへのリンクは自動的にはされません。ですので、実行プログラムは dlopen() を使って実行時に手動で DSO をプログラムのアドレス空間にロードする必要があります。この時点では実行プログラムに対して DSO のシンボルの解決は行なわれません。しかし、その代わりに Unix のローダが DSO の (まだ未解決の) シンボルを実行プログラムによりエクスポートされたシンボルと既にロードされた DSO ライブラリによりエクスポートされたシンボル (特に、どこにでもある libc.so のすべてのシンボル) で自動的に解決します。こうすることで、DSO は最初から静的にリンクされていたかのように、実行プログラムのシンボルを知ることができます。

最後に、DSO の API を利点を生かすために、プログラムは後でディスパッチテーブルなどでシンボルを使うことができるように、 dlsym() を使っていくつかのシンボルを解決します。すなわち: 実行プログラムは必要なすべてのシンボルを手動で解決しなければなりません。この機構の利点はプログラムのオプショナルな部分は必要になるまでロードする必要がない (だからメモリも消費しない) ことです。必要ならば、基本プログラムの機能を拡張するためにこれらの部分を動的にロードすることができます。

この DSO 機構は簡単なように見えますが、少なくとも一つ難しい点があります: プログラムを拡張するために DSO を使っているときに、 DSO が実行プログラムからシンボルを解決する点です (二番目の方法)。これはなぜでしょうか。それは、DSO のシンボルを実行プログラムのシンボルから「逆解決」するというのはライブラリの設計 (ライブラリはそれを使用するプログラムのことは何も知らない) に反していて、この機能はすべてのプラットフォームにあるわけではなく、標準化もされていないからです。実際には実行プログラムのグローバルなシンボルは再エクスポートされることはあまりなく、DSO から使うことができません。リンカにグローバルシンボルすべてをエクスポートするようにさせる方法を見つけることが、実行時にプログラムを拡張するために DSO を使うときの一番の問題です。

共有ライブラリのアプローチが普通の方法です。DSO 機構はそのために設計されたものですから。したがって、その方法はオペレーティングシステムが提供するほとんどすべての種類のライブラリで使われています。一方、プログラムの拡張のために共有オブジェクトを使用する、という方はあまり使われていません。

1998 年の時点で、実行時に実際に機能拡張のために DSO 機構を使っているソフトウェアパッケージは少しだけでした: Perl 5 (XS 機構と DnaLoader モジュールによるもの)、Netscape サーバなどです。Apache はすでにモジュールの概念を使って機能拡張をしていて、内部的にディスパッチリストに基づいた外部モジュールの Apache コア機能へのリンクを行なっていましたので、バージョン 1.3 から、Apache も DSO 機構を使う仲間になりました。 Apache は実行時に DSO を使ってモジュールをロードするようにすでに運命付けられていたのです。

利点と欠点

上記の DSO に基づいた機能は以下の利点があります:

実際のサーバプロセスを組み立てるために、ビルド時に configure のオプションを使う代わりに実行時に httpd.conf の設定用コマンド LoadModule を使うことができますので、サーバパッケージの柔軟性が高まりました。たとえば、一つの Apache のインストールから違う構成のサーバ (標準版と SSL 版、最小構成と拡張版 [mod_perl, PHP3] など) を実行することができます。
インストールの後であっても、サーバのパッケージをサードパーティモジュールで簡単に拡張できるようになりました。これは、Apache コアパッケージと、PHP3, mod_perl, mod_fastcgi などの追加のパッケージを作成できるので、少なくともベンダのパッケージ管理者にとって大きな利点があります。
Apache モジュールの開発が簡単になります。これは DSO/apxs の組み合わせにより、Apache ソースツリーの外で作業でき、開発中のモジュールの新しいバージョンを実行中の Apache サーバに組み込むために apxs -i と apachectl restart を行なうだけで良くなるからです。

DSO には以下の欠点があります:

すべてのオペレーティングシステムがプログラムのアドレス空間にコードを動的ロードすることをサポートしているわではないので、プラットフォームによっては DSO 機構は使えません。
Unix のローダがシンボルの解決をする必要ができたので、そのオーバヘッドによりサーバの起動時間が約 20% 遅くなっています。
位置非依存コード (PIC) (訳注 position independent code) は相対アドレスのために複雑なアセンブラのトリックが必要なことがあり、それは必ずしも絶対アドレスと同じくらいの速度がでるわけではありませんので、プラットフォームによってはサーバの実行速度が約 5% 遅くなります。
DSO モジュールはすべてのプラットフォームで他の DSO に基づいたライブラリに対してリンクできる (ld -lfoo) というわけではありませんので (たとえば、a.out のプラットフォームではこの機能はありませんが、ELF のプラットフォームにはあります)、すべての種類のモジュールに DSO 機構を使えるわけではありません。言い換えると、DSO ファイルとしてコンパイルされたモジュールの使えるシンボルは、 Apache のコアのシンボル、C ライブラリ (libc) と Apache コアが使っている他のすべての静的なライブラリと動的ライブラリのシンボル、PIC による静的なライブラリ (libfoo.a) のシンボルのみに制限されます。その他のコードを使う方法は、 Apache コア自身がすでにそのコードへの参照があるようにするか、 dlopen () を使ってコードを自分自身でロードするかのどちらかしかありません。

1.1 httpd-2.0/docs/manual/logs.html.ja.jis Index: logs.html.ja.jis =================================================================== Log Files - Apache HTTP Server

ログファイル

ウェブサーバを効果的に管理するためには、サーバの活動やパフォーマンス、今発生しているかもしれない問題に関するフィードバックを得ることが必要です。 Apache HTTP サーバには非常に包括的で柔軟なロギング機能があります。この文書はロギング機能の設定の仕方と、ログに何が書かれているかを理解するための方法を説明します。

セキュリティに関する警告
エラーログ
アクセスログ
ログの交替
パイプ経由のログ
バーチャルホスト
他のログファイル

セキュリティに関する警告

Apache がログファイルを書いているディレクトリに書き込める人は、ほぼ確実にサーバが起動された uid へのアクセスを手に入れることができます。そして、それは通常は root ユーザです。ちゃんと結果を考えることなく、そのディレクトリへの書き込み権限を与えないでください。詳しくはセキュリティのこつの文書を読んでください。

加えて、ログファイルにはクライアントからの情報がそのまま、エスケープされることなく書かれています。ですから、悪意のあるクライアントがログファイルに制御文字を挿入することができます。生のログを扱うときは注意してください。

エラーログ

関連ディレクティブ

ErrorLog
LogLevel

ErrorLog ディレクティブにより名前と場所が決まるサーバのエラーログは、一番重要なログファイルです。 Apache の診断情報はここに送られ、リクエストを処理しているときに発生したエラーはすべてここに記録されます。サーバを起動したときや、サーバの動作に問題が起こったときは、一番最初に調べるべきところです。間違いの詳細や修正方法がそこに書かれていることがよくあります。

エラーログは普通はファイルに書かれます (通常 unix システムでは error_log、Windows と OS/2 では error.log)。 Unix システムではエラーを syslog やパイプでプログラムに送ることができます。

エラーログの書式は比較的自由度の高いもので、説明的に書かれています。ただし、いくつかの情報はほとんどのエラーログのエントリにあります。例えば、代表的なものに次のようなメッセージがあります。

[Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1] client denied by server configuration: /export/home/live/ap/htdocs/test

ログエントリの最初の項目はメッセージの日付と時刻です。二つめの項目は報告されているエラーの重要度です。 LogLevel で重要度のレベルを制限することによりエラーログに送られるエラーの種類を制御することができます。三つ目の項目はエラーを発生させたクライアントの IP アドレスです。残りはメッセージで、この場合はサーバがクライアントのアクセスを拒否するように設定されている、ということを示しています。サーバはリクエストされた文書の (ウェブのパスではなく) ファイルシステムのパスを報告します。

非常に広範囲のメッセージがエラーログに現れます。たいていのものは上の例のような感じです。エラーログには CGI スクリプトのデバッグ出力も書かれます。CGI スクリプトが stderr に書いたすべての情報は直接エラーログにコピーされます。

情報を追加したり削除したりしてエラーログをカスタマイズすることはできません。しかし、リクエストに対するエラーログのエントリは、対応するエントリがアクセスログにあります。例えば、上の例のエントリはアクセスログのステータスコード 403 のエントリに対応します。アクセスログはカスタマイズ可能ですので、そちらを使うことによりエラーの状況に関する情報をより多く手に入れることができます。

テストの最中は、問題が発生しているかどうかを見るために、常にエラーログを監視するのが役に立つ場合がよくあります。 Unix システムでは、次のものを使うことができます。

tail -f error_log

アクセスログ

関連モジュール

mod_log_config

関連ディレクティブ

CustomLog
LogFormat
SetEnvIf

サーバアクセスログはサーバが処理をしたすべてのリクエストを記録します。アクセスログの場所と内容は CustomLog ディレクティブにより決まります。ログの内容の選択を簡潔にするために LogFormat ディレクティブを使用することができます。このセクションはアクセスログに情報を記録するためのサーバの設定方法を説明します。

もちろん、アクセスログに情報を蓄積することはログ管理の始まりに過ぎません。次の段階は有用な統計を取るためにこの情報を解析することです。一般的なログ解析はこの文書の範囲外で、ウェブサーバ自身の仕事というわけでもありません。この話や、ログ解析を行なうアプリケーションの情報を得るには、 Open Directory や Yahoo を調べてください。

いろんなバージョンの Apache httpd が mod_log_config, mod_log_agent, TransferLog ディレクティブといった、他のモジュールやディレクティブを使ってアクセスのロギングを制御してきました。今では、CustomLog がすべての古いディレクティブの機能を含むようになっています。

アクセスログの書式は非常に柔軟な設定が可能です。書式は C の printf(1) フォーマット文字列に非常に似たフォーマット文字列により指定されます。いくつか次の節で例を示します。フォーマット文字列に使用できる内容の一覧は mod_log_config の文書を見てください。

Common Log Format

アクセスログのよくある設定に以下のものがあります。

LogFormat "%h %l %u %t \"%r\" %>s %b" common CustomLog logs/access_log common

これは、ニックネーム common を定義し、ログのフォーマット文字列の一つと関連付けます。フォーマット文字列はパーセントディレクティブからなり、それぞれのパーセントディレクティブはサーバにどの情報をロギングするかを指示します。フォーマット文字列に文字をそのまま入れることもでき、それらはログの出力に直接コピーされます。そこに引用文字 (") を書くときは、フォーマット文字列の最後として解釈されることを防ぐためにバックスラッシュでエスケープする必要があります。フォーマット文字列には改行用の "\n"、タブ用の "\t" という特別な制御文字も含めることができます。

CustomLog ディレクティブは既に定義された ニックネーム を使って新しいログファイルを設定します。アクセスログのファイル名はスラッシュで始まらない限り、 ServerRoot からの相対パスとして扱われます。

上の設定は Common Log Format (CLF) と呼ばれる形式でログエントリを書きます。この標準の形式は異なるウェブサーバの多くが生成することができ、多くのログ解析プログラムが読みこむことができます。 CLF により生成されたログファイルのエントリは以下のようになります:

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326

このログエントリのそれぞれの部分の意味は以下で説明します。

127.0.0.1 (%h): これはサーバへリクエストをしたクライアント (リモートホスト) の IP アドレスです。HostnameLookups が On の場合は、サーバはホスト名を調べて、 IP アドレスが書かれているところに記録します。しかし、この設定はサーバをかなり遅くするので、あまりお勧めできません。そうではなく、logresolve のようなログの後処理を行なうプログラムでホスト名を調べるのが良いでしょう。ここに報告される IP アドレスは必ずしもユーザが使っているマシンのものであるとは限りません。ユーザとサーバの間にプロキシサーバがあれば、このアドレスは元のマシンのものではなく、プロキシのアドレスになります。
- (%l): 出力中の「ハイフン」は要求された情報が手に入らなかったということを意味します。この場合、取得できなかった情報はクライアントのマシンの identd により決まる RFC 1413 のクライアントのアイデンティティです。この情報はあまり信用することができず、しっかりと管理された内部ネットワークを除いては使うべきではありません。 Apache は IdentityCheck が On になっていない限り、この情報を得ようとすらしません。
frank (%u): これは HTTP 認証による、ドキュメントをリクエストした人のユーザ ID です。CGI スクリプトには通常同じ値が REMOTE_USER 環境変数として与えられます。リクエストのステータスコード (以下を参照) が 401 であった場合は、ユーザは認証に失敗しているので、この値は信用できません。ドキュメントがパスワードで保護されていない場合は、このエントリは前のものと同じように "-" になります。
[10/Oct/2000:13:55:36 -0700] (%t): サーバがリクエストの処理を終えた時刻です。書式は:
[day/month/year:hour:minute:second zone] day = 2*digit month = 3*letter year = 4*digit hour = 2*digit minute = 2*digit second = 2*digit zone = (`+' | `-') 4*digit
ログのフォーマット文字列に %{format}t を指定することで、別の形式で時刻を表示させることもできます。このとき、format は C の標準ライブラリの strftime(3) の形式になります。
"GET /apache_pb.gif HTTP/1.0" (\"%r\"): クライアントからのリクエストが二重引用符の中に示されています。リクエストには多くの有用な情報があります。まず、この場合クライアントが使ったメソッドは GET です。次に、クライアントはリソース /apache_pb.gif を要求しました。そして、クライアントはプロトコル HTTP/1.0 を使用しました。リクエストの各部分を独立にログ収集することもできます。例えば、フォーマット文字列 "%m %U%q %H" はメソッド、パス、クエリ文字列、プロトコルをログ収集し、結局 "%r" とまったく同じ出力になります。
200 (%>s): サーバがクライアントに送り返すステータスコードです。この情報は、リクエストが成功応答 (2 で始まるコード) であったか、リダイレクション (3 で始まるコード) であったか、クライアントによるエラー (4 で始まるコード) であったか、サーバのエラー (5 で始まるコード) であったか、を現すので、非常に大切です。ステータスコードの完全なリストは HTTP 規格 (RFC2616 第 10 節) にあります。
2326 (%b): この最後のエントリはクライアントに送信されたオブジェクトの、応答ヘッダを除いたサイズを現します。コンテントがクライアントに送られなかった場合は、この値は "-" になります。コンテントが無い場合に "0" をログ収集するには、%b ではなく %B を使ってください。

Combined Log Format

もう一つのよく使われる書式は Combined Log Format と呼ばれています。以下のようにして使うことができます。

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined CustomLog log/acces_log combined

この書式の最初の方は Common Log Format とまったく同じで、最後に二つ追加のエントリがあります。追加のエントリはパーセントディレクティブ %{header}i を使っています。ここで header は HTTP のリクエストヘッダのどれかです。この書式によるアクセスログは以下のような感じになります:

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 "http://www.example.com/start.html" "Mozilla/4.08 [en] (Win98; I ;Nav)"

追加のエントリは:

"http://www.example.com/start.html" (\"%{Referer}i\"): "Referer" (意図的な綴り間違い) HTTP リクエストヘッダです。これはクライアントが報告してくる参照元のサイトを表します。 (この場合は、/apache_pb.gif にリンクしているか、それを含んでいるページです)。
"Mozilla/4.08 [en] (Win98; I ;Nav)" (\"%{User-agent}i\"): User-Agent HTTP リクエストヘッダです。これはクライアントのブラウザが自分自身のことを報告してくる情報です。

複数のアクセスログ

複数のアクセスログは単に設定ファイルに複数の CustomLog ディレクティブを書くことで作成されます。例えば、以下のディレクティブは三つのアクセスログを作ります。最初のものは基本的な CLF の情報で、二つ目と三つ目は referer とブラウザの情報です。最後二つの CustomLog は ReferLog ディレクティブと AgentLog ディレクティブの効果をまねる方法を示しています。

LogFormat "%h %l %u %t \"%r\" %>s %b" common CustomLog logs/access_log common CustomLog logs/referer_log "%{Referer}i -> %U" CustomLog logs/agent_log "%{User-agent}i"

この例は LogFormat でニックネームを定義する必要がない、ということも示しています。ニックネームの代わりに、 CustomLog ディレクティブに直接ログの書式を指定することができます。

条件付きロギング

クライアントのリクエストの特徴に基づいてアクセスログにエントリの一部をロギングしない方が便利なことがあります。これは環境変数の補助により簡単に実現できます。まず、リクエストが何らかの条件に合うということを現すために環境変数が設定される必要があります。これは通常は SetEnvIf により行なわれます。そして、CustomLog ディレクティブの env= 節を使って環境変数が設定されているリクエストを含めたり排除したりすることができます。いくつか例を挙げます:

# Mark requests from the loop-back interface SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog # Mark requests for the robots.txt file SetEnvIf Request_URI "^/robots\.txt$" dontlog # Log what remains CustomLog logs/access_log common env=!dontlog

他の例として、英語を話す人からのリクエストとそれ以外の人からのリクエストを分けたい、という場合を考えてみてください。

SetEnvIf Accept-Language "en" english CustomLog logs/english_log common env=english CustomLog logs/non_english_log common env=!english

ここまででは条件付きロギングが非常に強力で柔軟であることを示してきましたが、それがログの内容を制御する唯一の方法というわけではありません。ログファイルはサーバの活動の完全な記録である方がより役に立ちます。単純にログファイルを後処理して、考慮したくないログを削除する方が簡単であることがよくあります。

ログの交替

普通の負荷のサーバでさえ、ログファイルに保存される情報の量は膨大になります。アクセスログのファイルは普通 10,000 リクエスト毎に 1 MB 以上増えます。ですから、既存のログを移動したり、削除したりして、定期的にログを交替させることが必要になります。これはサーバの実行中には行なえません。というのは、Apache はファイルが open されている間はずっと古いログファイルに書き続けるからです。新しいログファイルを open できるように、ログファイルが移動されたり削除された後に、サーバを再起動する必要があります。

優雅な 再起動を行なうことで、サーバは既存のコネクションや処理待ちのコネクションを失うことなく新しいログファイルを open させることができます。しかし、これを実現するために、サーバは古いリクエストを扱っている間は古いログファイルに書き続ける必要があります。ですから、再起動の後ではログファイルの処理を始める前に、しばらく待たなければなりません。単にログを交替させて、ディスクの節約のために古いログを圧縮する普通のシナリオは:

mv access_log access_log.old mv error_log error_log.old apachectl graceful sleep 600 gzip access_log.old error_log.old

ログの交替をするもう一つの方法はパイプ経由のログを使うもので、次の節で説明されています。

パイプ経由のログ

Apache httpd はエラーログとアクセスログをファイルに直接書く代わりに、パイプを通して別のプログラムに書き出すことができます。この機能により、主サーバにコードを追加することなくロギングの柔軟性が非常に高まっています。パイプにログを書くためには、単にファイル名をパイプ文字 "|" に置き換え、その続きに標準入力からログのエントリを受けとる実行プログラムの名前を書くだけです。 Apache はパイプ経由のログ用のプロセスをサーバの起動時に実行し、サーバの実行中にそのプログラムがクラッシュしたときはそれを再び実行します。(この最後の機能がこの技術が「信頼性のあるパイプ経由のロギング」と呼ばれている理由です。)

パイプ経由のログ用のプロセスは Apache httpd の親プロセスから起動され、そのプロセスのユーザ ID を継承します。これは、これは、パイプ経由のログ用のプログラムは普通 root として実行されることを意味します。ですから、プログラムを簡単で安全に保つことが非常に重要です。

パイプ経由のログを使う簡単な例は:

# compressed logs CustomLog "|/usr/bin/gzip -c >> /var/log/access_log.gz" common # almost-real-time name resolution CustomLog "|/usr/local/apache/bin/logresolve >> /var/log/access_log" common

パイプの先で呼ばれるコマンド全体が引用符で囲まれていることに注目してください。この例はアクセスログを使っていますが、エラーログにも同じ技術を使うことができます。

パイプ経由のログの重要な利用法は、ログの交替をサーバの再起動なしでするものです。Apache HTTP サーバにはこのための rotatelogs と呼ばれる簡単なプログラムが付属しています。たとえば、24 時間毎にログを交替させるには、以下のものを使うことができます:

CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/access_log 86400" common

似ているけれど、よりずっと柔軟な cronolog というログ交替用のプログラムが外部のサイトにあります。

条件付きロギングと同様、パイプ経由のログは非常に強力な道具ですが、オフラインの後処理のような、より簡単な解決方法があるときは使わない方が良いでしょう。

バーチャルホスト

多くのバーチャルホストのあるサーバを実行しているときは、ログファイルの扱い方にいくつかの方法があります。まず、単独のホストのみのサーバとまったく同じようにログを使うことができます。ロギングディレクティブを主サーバのコンテキストの <VirtualHost> セクションの外に置くことで、すべてのログを同じアクセスログとエラーログにログ収集することができます。この手法では個々のバーチャルホストの統計を簡単にとることはできません。

CustomLog や ErrorLog ディレクティブが <VirtualHost> の中に置かれた場合は、そのバーチャルホストへのすべてのリクエストやエラーがそこで指定されたファイルにのみログ収集されます。ロギングディレクティブのないバーチャルホストは依然としてリクエストが主サーバのログに送られます。この手法は少ないバーチャルホストに対しては非常に有用ですが、ホストの数が非常に多くなると管理が大変になります。さらに、ファイル記述子の限界の問題を起こすことがあります。

アクセスログには、非常に良い妥協案があります。バーチャルホストの情報をログのフォーマット文字列に加えることで、すべてのホストへのリクエストを同じログにログ収集して、後でログを個々のファイルに分割することができます。たとえば、以下のディレクティブを見てください。

LogFormat "%v %l %u %t \"%r\" %>s %b" comonvhost CustomLog logs/access_log comonvhost

%v がリクエストを扱っているバーチャルホストの名前をログ収集するために使われています。そして、split-logfile のようなプログラムを使ってアクセスログを後処理することで、バーチャルホスト毎のファイルにログを分割することができます。

残念ながら、エラーログには同様の手法はありません。ですから、すべてのバーチャルホストを同じエラーログの中に混ぜるか、バーチャルホスト毎にエラーログを使うかを選ばなければなりません。