From: Yoshiki Hayashi Date: Fri, 12 Jul 2002 11:21:30 +0000 (+0000) Subject: New Japanese translations. X-Git-Tag: 2.0.40~258 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=114513bb42ccc0b0cdad045b9527f6ea1f7b4a83;p=apache New Japanese translations. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@96026 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/dso.html b/docs/manual/dso.html deleted file mode 100644 index 41d965d671..0000000000 --- a/docs/manual/dso.html +++ /dev/null @@ -1,344 +0,0 @@ - - - - - - - Dynamic Shared Object (DSO) support - - - - - - -

Dynamic Shared Object (DSO) Support

- -

The Apache HTTP Server is a modular program where the - administrator can choose the functionality to include in the - server by selecting a set of modules. The modules can be - statically compiled into the httpd binary when the - server is built. Alternatively, modules can be compiled as - Dynamic Shared Objects (DSOs) that exist separately from the - main httpd binary file. DSO modules may be - compiled at the time the server is built, or they may be - compiled and added at a later time using the Apache Extension - Tool (apxs).

- -

This document describes how to use DSO modules as well as - the theory behind their use.

- - -
- - - - - - - -
Related Modules
-
- mod_so
- 		Related Directives
-
- LoadModule
-
- -

Implementation

- -

The DSO support for loading individual Apache modules is - based on a module named mod_so.c which must be - statically compiled into the Apache core. It is the only module - besides core.c which cannot be put into a DSO - itself. Practically all other distributed Apache modules - can then be placed into a DSO by individually enabling the DSO - build for them via configure's - --enable-module=shared option as disucussed - in the install documentation. After - a module is compiled into a DSO named mod_foo.so - you can use mod_so's - LoadModule - command in your httpd.conf file to load this - module at server startup or restart.

- -

To simplify this creation of DSO files for Apache modules - (especially for third-party modules) a new support program - named apxs (APache - eXtenSion) is available. It can be used to build DSO based - modules outside of the Apache source tree. The idea is - simple: When installing Apache the configure's - make install procedure installs the Apache C - header files and puts the platform-dependent compiler and - linker flags for building DSO files into the apxs - program. This way the user can use apxs to compile - his Apache module sources without the Apache distribution - source tree and without having to fiddle with the - platform-dependent compiler and linker flags for DSO - support.

- -

Usage Summary

- -

To give you an overview of the DSO features of Apache 2.0, - here is a short and concise summary:

- -
    -
  1. - Build and install a distributed Apache module, say - mod_foo.c, into its own DSO - mod_foo.so: - - - - - -
    -
    -$ ./configure --prefix=/path/to/install
-        --enable-foo=shared
-$ make install
-
    -
    -
    2. - -
  2. - Build and install a third-party Apache module, say - mod_foo.c, into its own DSO - mod_foo.so: - - - - - -
    -
    -$ ./configure --add-module=module_type:/path/to/3rdparty/mod_foo.c 
-        --enable-foo=shared
-$ make install
-
    -
    -
    3. - -
  3. - Configure Apache for later installation of shared - modules: - - - - - -
    -
    -$ ./configure --enable-so
-$ make install
-
    -
    -
    4. - -
  4. - Build and install a third-party Apache module, say - mod_foo.c, into its own DSO - mod_foo.so outside of the Apache - source tree using apxs: - - - - - -
    -
    -$ cd /path/to/3rdparty
-$ apxs -c mod_foo.c
-$ apxs -i -a -n foo mod_foo.so
-
    -
    -
    5. -
- -

In all cases, once the shared module is compiled, you must - use a LoadModule - directive in httpd.conf to tell Apache to activate - the module.

- -

Background

- -

On modern Unix derivatives there exists a nifty mechanism - usually called dynamic linking/loading of Dynamic Shared - Objects (DSO) which provides a way to build a piece of - program code in a special format for loading it at run-time - into the address space of an executable program.

- -

This loading can usually be done in two ways: Automatically - by a system program called ld.so when an - executable program is started or manually from within the - executing program via a programmatic system interface to the - Unix loader through the system calls - dlopen()/dlsym().

- -

In the first way the DSO's are usually called shared - libraries or DSO libraries and named - libfoo.so or libfoo.so.1.2. They - reside in a system directory (usually /usr/lib) - and the link to the executable program is established at - build-time by specifying -lfoo to the linker - command. This hard-codes library references into the executable - program file so that at start-time the Unix loader is able to - locate libfoo.so in /usr/lib, in - paths hard-coded via linker-options like -R or in - paths configured via the environment variable - LD_LIBRARY_PATH. It then resolves any (yet - unresolved) symbols in the executable program which are - available in the DSO.

- -

Symbols in the executable program are usually not referenced - by the DSO (because it's a reusable library of general code) - and hence no further resolving has to be done. The executable - program has no need to do anything on its own to use the - symbols from the DSO because the complete resolving is done by - the Unix loader. (In fact, the code to invoke - ld.so is part of the run-time startup code which - is linked into every executable program which has been bound - non-static). The advantage of dynamic loading of common library - code is obvious: the library code needs to be stored only once, - in a system library like libc.so, saving disk - space for every program.

- -

In the second way the DSO's are usually called shared - objects or DSO files and can be named with an - arbitrary extension (although the canonical name is - foo.so). These files usually stay inside a - program-specific directory and there is no automatically - established link to the executable program where they are used. - Instead the executable program manually loads the DSO at - run-time into its address space via dlopen(). At - this time no resolving of symbols from the DSO for the - executable program is done. But instead the Unix loader - automatically resolves any (yet unresolved) symbols in the DSO - from the set of symbols exported by the executable program and - its already loaded DSO libraries (especially all symbols from - the ubiquitous libc.so). This way the DSO gets - knowledge of the executable program's symbol set as if it had - been statically linked with it in the first place.

- -

Finally, to take advantage of the DSO's API the executable - program has to resolve particular symbols from the DSO via - dlsym() for later use inside dispatch tables - etc. In other words: The executable program has to - manually resolve every symbol it needs to be able to use it. - The advantage of such a mechanism is that optional program - parts need not be loaded (and thus do not spend memory) until - they are needed by the program in question. When required, - these program parts can be loaded dynamically to extend the - base program's functionality.

- -

Although this DSO mechanism sounds straightforward there is - at least one difficult step here: The resolving of symbols from - the executable program for the DSO when using a DSO to extend a - program (the second way). Why? Because "reverse resolving" DSO - symbols from the executable program's symbol set is against the - library design (where the library has no knowledge about the - programs it is used by) and is neither available under all - platforms nor standardized. In practice the executable - program's global symbols are often not re-exported and thus not - available for use in a DSO. Finding a way to force the linker - to export all global symbols is the main problem one has to - solve when using DSO for extending a program at run-time.

- -

The shared library approach is the typical one, because it - is what the DSO mechanism was designed for, hence it is used - for nearly all types of libraries the operating system - provides. On the other hand using shared objects for extending - a program is not used by a lot of programs.

- -

As of 1998 there are only a few software packages available - which use the DSO mechanism to actually extend their - functionality at run-time: Perl 5 (via its XS mechanism and the - DynaLoader module), Netscape Server, etc. Starting - with version 1.3, Apache joined the crew, because Apache - already uses a module concept to extend its functionality and - internally uses a dispatch-list-based approach to link external - modules into the Apache core functionality. So, Apache is - really predestined for using DSO to load its modules at - run-time.

- -

Advantages and - Disadvantages

- -

The above DSO based features have the following - advantages:

- - - -

DSO has the following disadvantages:

- - - - - - diff --git a/docs/manual/dso.html.ja.jis b/docs/manual/dso.html.ja.jis new file mode 100644 index 0000000000..39d5113fd9 --- /dev/null +++ b/docs/manual/dso.html.ja.jis @@ -0,0 +1,321 @@ + + + + + + + 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 機能の概略を知ることができるための、 + 短く簡潔な概要です:

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

どの場合においても、共有モジュールをコンパイルした後で、 + 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 に基づいた機能は以下の利点があります:

+ + + +

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

+ + + + + + diff --git a/docs/manual/logs.html b/docs/manual/logs.html deleted file mode 100644 index 49ccee903a..0000000000 --- a/docs/manual/logs.html +++ /dev/null @@ -1,666 +0,0 @@ - - - - - - - Log Files - Apache HTTP Server - - - - - - -

Log Files

- -

In order to effectively manage a web server, it is necessary - to get feedback about the activity and performance of the - server as well as any problems that may be occuring. The Apache - HTTP Server provides very comprehensive and flexible logging - capabilities. This document describes how to configure its - logging capabilities, and how to understand what the logs - contain.

- - -
- -

Security Warning

- -

Anyone who can write to the directory where Apache is - writing a log file can almost certainly gain access to the uid - that the server is started as, which is normally root. Do - NOT give people write access to the directory the logs - are stored in without being aware of the consequences; see the - security tips document - for details.

- -

In addition, log files may contain information supplied - directly by the client, without escaping. Therefore, it is - possible for malicious clients to insert control-characters in - the log files, so care must be taken in dealing with raw - logs.

-
- -

Error Log

- - - - - -
Related Directives
-
- ErrorLog
- LogLevel
- -

The server error log, whose name and location is set by the - ErrorLog directive, is the - most important log file. This is the place where Apache httpd - will send diagnostic information and record any errors that it - encounters in processing requests. It is the first place to - look when a problem occurs with starting the server or with the - operation of the server, since it will often contain details of - what went wrong and how to fix it.

- -

The error log is usually written to a file (typically - error_log on unix systems and - error.log on Windows and OS/2). On unix systems it - is also possible to have the server send errors to - syslog or pipe them to a - program.

- -

The format of the error log is relatively free-form and - descriptive. But there is certain information that is contained - in most error log entries. For example, here is a typical - message.

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

The first item in the log entry is the date and time of the - message. The second entry lists the severity of the error being - reported. The LogLevel - directive is used to control the types of errors that are sent - to the error log by restricting the severity level. The third - entry gives the IP address of the client that generated the - error. Beyond that is the message itself, which in this case - indicates that the server has been configured to deny the - client access. The server reports the file-system path (as - opposed to the web path) of the requested document.

- -

A very wide variety of different messages can appear in the - error log. Most look similar to the example above. The error - log will also contain debugging output from CGI scripts. Any - information written to stderr by a CGI script will - be copied directly to the error log.

- -

It is not possible to customize the error log by adding or - removing information. However, error log entries dealing with - particular requests have corresponding entries in the access log. For example, the above example - entry corresponds to an access log entry with status code 403. - Since it is possible to customize the access log, you can - obtain more information about error conditions using that log - file.

- -

During testing, it is often useful to continuously monitor - the error log for any problems. On unix systems, you can - accomplish this using:

- -
- tail -f error_log -
-
- -

Access Log

- - - - - - - -
Related Modules
-
- mod_log_config
- 		Related Directives
-
- CustomLog
- LogFormat
- SetEnvIf -
- -

The server access log records all requests processed by the - server. The location and content of the access log are - controlled by the CustomLog - directive. The LogFormat - directive can be used to simplify the selection of the contents - of the logs. This section describes how to configure the server - to record information in the access log.

- -

Of course, storing the information in the access log is only - the start of log management. The next step is to analyze this - information to produce useful statistics. Log analysis in - general is beyond the scope of this document, and not really - part of the job of the web server itself. For more information - about this topic, and for applications which perform log - analysis, check the - Open Directory or - Yahoo.

- -

Various versions of Apache httpd have used other modules and - directives to control access logging, including - mod_log_referer, mod_log_agent, and the - TransferLog directive. The CustomLog - directive now subsumes the functionality of all the older - directives.

- -

The format of the access log is highly configurable. The - format is specified using a format string that - looks much like a C-style printf(1) format string. Some - examples are presented in the next sections. For a complete - list of the possible contents of the format string, see the mod_log_config - documentation.

- -

Common Log Format

- -

A typical configuration for the access log might look as - follows.

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

This defines the nickname common and - associates it with a particular log format string. The format - string consists of percent directives, each of which tell the - server to log a particular piece of information. Literal - characters may also be placed in the format string and will be - copied directly into the log output. The quote character - (") must be escaped by placing a back-slash before - it to prevent it from being interpreted as the end of the - format string. The format string may also contain the special - control characters "\n" for new-line and - "\t" for tab.

- -

The CustomLog directive sets up a new log file - using the defined nickname. The filename for the - access log is relative to the ServerRoot unless it begins - with a slash.

- -

The above configuration will write log entries in a format - known as the Common Log Format (CLF). This standard format can - be produced by many different web servers and read by many log - analysis programs. The log file entries produced in CLF will - look something like this:

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

Each part of this log entry is described below.

- -
-
127.0.0.1 (%h)
- -
This is the IP address of the client (remote host) which - made the request to the server. If HostnameLookups is - set to On, then the server will try to determine - the hostname and log it in place of the IP address. However, - this configuration is not recommended since it can - significantly slow the server. Instead, it is best to use a - log post-processor such as logresolve to determine - the hostnames. The IP address reported here is not - necessarily the address of the machine at which the user is - sitting. If a proxy server exists between the user and the - server, this address will be the address of the proxy, rather - than the originating machine.
- -
- (%l)
- -
The "hyphen" in the output indicates that the requested - piece of information is not available. In this case, the - information that is not available is the RFC 1413 identity of - the client determined by identd on the clients - machine. This information is highly unreliable and should - almost never be used except on tightly controlled internal - networks. Apache httpd will not even attempt to determine - this information unless IdentityCheck is set - to On.
- -
frank (%u)
- -
This is the userid of the person requesting the document - as determined by HTTP authentication. The same value is - typically provided to CGI scripts in the - REMOTE_USER environment variable. If the status - code for the request (see below) is 401, then this value - should not be trusted because the user is not yet - authenticated. If the document is not password protected, - this entry will be "-" just like the previous - one.
- -
[10/Oct/2000:13:55:36 -0700] - (%t)
- -
- The time that the server finished processing the request. - The format is: - -
- [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 -
- It is possible to have the time displayed in another format - by specifying %{format}t in the log format - string, where format is as in - strftime(3) from the C standard library. -
- -
"GET /apache_pb.gif HTTP/1.0" - (\"%r\")
- -
The request line from the client is given in double - quotes. The request line contains a great deal of useful - information. First, the method used by the client is - GET. Second, the client requested the resource - /apache_pb.gif, and third, the client used the - protocol HTTP/1.0. It is also possible to log - one or more parts of the request line independently. For - example, the format string "%m %U%q %H" will log - the method, path, query-string, and protocol, resulting in - exactly the same output as "%r".
- -
200 (%>s)
- -
This is the status code that the server sends back to the - client. This information is very valuable, because it reveals - whether the request resulted in a successful response (codes - beginning in 2), a redirection (codes beginning in 3), an - error caused by the client (codes beginning in 4), or an - error in the server (codes beginning in 5). The full list of - possible status codes can be found in the HTTP - specification (RFC2616 section 10).
- -
2326 (%b)
- -
The last entry indicates the size of the object returned - to the client, not including the response headers. If no - content was returned to the client, this value will be - "-". To log "0" for no content, use - %B instead.
-
- -

Combined Log - Format

- -

Another commonly used format string is called the Combined - Log Format. It can be used as follows.

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

This format is exactly the same as the Common Log Format, - with the addition of two more fields. Each of the additional - fields uses the percent-directive - %{header}i, where header can be - any HTTP request header. The access log under this format will - look like:

- -
- 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)" -
- -

The additional fields are:

- -
-
"http://www.example.com/start.html" - (\"%{Referer}i\")
- -
The "Referer" (sic) HTTP request header. This gives the - site that the client reports having been referred from. (This - should be the page that links to or includes - /apache_pb.gif).
- -
"Mozilla/4.08 [en] (Win98; I ;Nav)" - (\"%{User-agent}i\")
- -
The User-Agent HTTP request header. This is the - identifying information that the client browser reports about - itself.
-
- -

Multiple Access - Logs

- -

Multiple access logs can be created simply by specifying - multiple CustomLog directives in the configuration - file. For example, the following directives will create three - access logs. The first contains the basic CLF information, - while the second and third contain referer and browser - information. The last two CustomLog lines show how - to mimic the effects of the ReferLog and - AgentLog directives.

- -
- 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" -
- -

This example also shows that it is not necessary to define a - nickname with the LogFormat directive. Instead, - the log format can be specified directly in the - CustomLog directive.

- -

Conditional - Logging

- -

There are times when it is convenient to exclude certain - entries from the access logs based on characteristics of the - client request. This is easily accomplished with the help of environment variables. First, an - environment variable must be set to indicate that the request - meets certain conditions. This is usually accomplished with SetEnvIf. Then the - env= clause of the CustomLog - directive is used to include or exclude requests where the - environment variable is set. Some examples:

- -
- # 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 -
- -

As another example, consider logging requests from - english-speakers to one log file, and non-english speakers to a - different log file.

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

Although we have just shown that conditional logging is very - powerful and flexibly, it is not the only way to control the - contents of the logs. Log files are more useful when they - contain a complete record of server activity. It is often - easier to simply post-process the log files to remove requests - that you do not want to consider.

-
- -

Log Rotation

- -

On even a moderately busy server, the quantity of - information stored in the log files is very large. The access - log file typically grows 1 MB or more per 10,000 requests. It - will consequently be necessary to periodically rotate the log - files by moving or deleting the existing logs. This cannot be - done while the server is running, because Apache will continue - writing to the old log file as long as it holds the file open. - Instead, the server must be restarted after the log files are - moved or deleted so that it will open new log files.

- -

By using a graceful restart, the server can be - instructed to open new log files without losing any existing or - pending connections from clients. However, in order to - accomplish this, the server must continue to write to the old - log files while it finishes serving old requests. It is - therefore necessary to wait for some time after the restart - before doing any processing on the log files. A typical - scenario that simply rotates the logs and compresses the old - logs to save space is:

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

Another way to perform log rotation is using piped logs as discussed in the next - section.

-
- -

Piped Logs

- -

Apache httpd is capable of writing error and access log - files through a pipe to another process, rather than directly - to a file. This capability dramatically increases the - flexibility of logging, without adding code to the main server. - In order to write logs to a pipe, simply replace the filename - with the pipe character "|", followed by the name - of the executable which should accept log entries on its - standard input. Apache will start the piped-log process when - the server starts, and will restart it if it crashes while the - server is running. (This last feature is why we can refer to - this technique as "reliable piped logging".)

- -

Piped log processes are spawned by the parent Apache httpd - process, and inherit the userid of that process. This means - that piped log programs usually run as root. It is therefore - very important to keep the programs simple and secure.

- -

Some simple examples using piped logs:

- -
- # 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 -
- -

Notice that quotes are used to enclose the entire command - that will be called for the pipe. Although these examples are - for the access log, the same technique can be used for the - error log.

- -

One important use of piped logs is to allow log rotation - without having to restart the server. The Apache HTTP Server - includes a simple program called rotatelogs for this - purpose. For example, to rotate the logs every 24 hours, you - can use:

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

A similar, but much more flexible log rotation program - called cronolog - is available at an external site.

- -

As with conditional logging, piped logs are a very powerful - tool, but they should not be used where a simpler solution like - off-line post-processing is available.

-
- -

Virtual - Hosts

- -

When running a server with many virtual - hosts, there are several options for dealing with log - files. First, it is possible to use logs exactly as in a - single-host server. Simply by placing the logging directives - outside the <VirtualHost> sections in the - main server context, it is possible to log all requests in the - same access log and error log. This technique does not allow - for easy collection of statistics on individual virtual - hosts.

- -

If CustomLog or ErrorLog - directives are placed inside a <VirtualHost> - section, all requests or errors for that virtual host will be - logged only to the specified file. Any virtual host which does - not have logging directives will still have its requests sent - to the main server logs. This technique is very useful for a - small number of virtual hosts, but if the number of hosts is - very large, it can be complicated to manage. In addition, it - can often create problems with insufficient file - descriptors.

- -

For the access log, there is a very good compromise. By - adding information on the virtual host to the log format - string, it is possible to log all hosts to the same log, and - later split the log into individual files. For example, - consider the following directives.

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

The %v is used to log the name of the virtual - host that is serving the request. Then a program like split-logfile can be used to - post-process the access log in order to split it into one file - per virtual host.

- -

Unfortunately, no similar technique is available for the - error log, so you must choose between mixing all virtual hosts - in the same error log and using one error log per virtual - host.

-
- -

Other Log Files

- - - - - - - -
Related Modules
-
- mod_cgi
- mod_rewrite 		Related Directives
-
- PidFile
- RewriteLog
- RewriteLogLevel
- ScriptLog
- ScriptLogLength
- ScriptLogBuffer -
- -

PID File

- -

On startup, Apache httpd saves the process id of the parent - httpd process to the file logs/httpd.pid. This - filename can be changed with the PidFile directive. The - process-id is for use by the administrator in restarting and - terminating the daemon by sending signals to the parent - process; on Windows, use the -k command line option instead. - For more information see the Stopping - and Restarting page.

- -

Script Log

- -

In order to aid in debugging, the ScriptLog directive - allows you to record the input to and output from CGI scripts. - This should only be used in testing - not for live servers. - More information is available in the mod_cgi documentation.

- -

Rewrite Log

- -

When using the powerful and complex features of mod_rewrite, it is almost - always necessary to use the RewriteLog to help - in debugging. This log file produces a detailed analysis of how - the rewriting engine transforms requests. The level of detail - is controlled by the RewriteLogLevel - directive.

- - - - diff --git a/docs/manual/logs.html.ja.jis b/docs/manual/logs.html.ja.jis new file mode 100644 index 0000000000..6afe4d74c4 --- /dev/null +++ b/docs/manual/logs.html.ja.jis @@ -0,0 +1,615 @@ + + + + + + + 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 のようなプログラムを + 使ってアクセスログを後処理することで、 + バーチャルホスト毎のファイルにログを分割することができます。

+ +

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

+
+ +

他のログファイル

+ + + + + + + +
関連モジュール
+
+ mod_cgi
+ mod_rewrite 		関連ディレクティブ
+
+ PidFile
+ RewriteLog
+ RewriteLogLevel
+ ScriptLog
+ ScriptLogLength
+ ScriptLogBuffer +
+ +

PID ファイル

+ +

起動時に、Apache は親 httpd プロセスのプロセス ID を + logs/httpd.pid に保存します。この + ファイル名は PidFile ディレクティブを使って + 変更することができます。プロセス ID は管理者が親プロセスに + シグナルを送ることでデーモンを再起動したり終了させたりするときに + 使用します。Windows では、代わりに -k コマンドオプションを + 使ってください。詳しい情報は 終了と + 再起動 のページを見てください。

+ +

スクリプトログ

+ +

デバッグの補助のために、ScriptLog ディレクティブは + CGI スクリプトの入力と出力を記録するようにできます。 + これはテスト用にのみ使用して、通常のサーバでは使用しないでください。 + 詳しい情報は mod_cgi の文書 にあります。

+ +

リライトログ

+ +

mod_rewrite の強力で複雑な機能を + 使っているときは、ほぼいつもデバッグを簡単にするために + RewriteLog の使用が + 必要でしょう。このログファイルにはリライトエンジンがリクエストを + 書き換える方法の詳細な解析が出力されます。詳しさの度合は RewriteLogLevel + で制御できます。

+ + + +