1 <?xml version="1.0" encoding="UTF-8" ?>
2 <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
3 <?xml-stylesheet type="text/xsl" href="./style/manual.ja.xsl"?>
4 <!-- English Revision: 659902:1174747 (outdated) -->
7 Licensed to the Apache Software Foundation (ASF) under one or more
8 contributor license agreements. See the NOTICE file distributed with
9 this work for additional information regarding copyright ownership.
10 The ASF licenses this file to You under the Apache License, Version 2.0
11 (the "License"); you may not use this file except in compliance with
12 the License. You may obtain a copy of the License at
14 http://www.apache.org/licenses/LICENSE-2.0
16 Unless required by applicable law or agreed to in writing, software
17 distributed under the License is distributed on an "AS IS" BASIS,
18 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
19 See the License for the specific language governing permissions and
20 limitations under the License.
23 <manualpage metafile="logs.xml.meta">
28 <p>ウェブサーバを効果的に管理するためには、サーバの活動やパフォーマンス、
29 今発生しているかもしれない問題に関するフィードバックを得ることが必要です。
30 Apache HTTP サーバには非常に包括的で柔軟なロギング機能があります。
31 この文書はロギング機能の設定の仕方と、ログに何が書かれているかを
35 <section id="security"><title>
38 <p>Apache がログファイルを書いているディレクトリに書き込める人は、
39 ほぼ確実にサーバが起動された uid へのアクセスを手に入れることができます。
40 そして、それは通常は root ユーザです。
41 ちゃんと結果を考えることなく、そのディレクトリへの
42 書き込み権限を与え<em>ない</em>でください。詳しくは
43 <a href="misc/security_tips.html">セキュリティのこつ</a>の文書を
46 <p>加えて、ログファイルにはクライアントからの情報がそのまま、
47 エスケープされることなく書かれています。ですから、悪意のある
48 クライアントがログファイルに制御文字を挿入することができます。
49 生のログを扱うときは注意してください。</p>
52 <section id="errorlog">
56 <directive module="core">ErrorLog</directive>
57 <directive module="core">LogLevel</directive>
61 <p><directive module="core">ErrorLog</directive> ディレクティブにより
62 名前と場所が決まるサーバのエラーログは、一番重要なログファイルです。
63 Apache の診断情報はここに送られ、リクエストを処理しているときに
64 発生したエラーはすべてここに記録されます。サーバを起動したときや、
65 サーバの動作に問題が起こったときは、一番最初に調べるべき
66 ところです。間違いの詳細や修正方法がそこに書かれていることが
69 <p>エラーログは普通はファイルに書かれます (通常 Unix システムでは
70 <code>error_log</code>、Windows と OS/2 では <code>error.log</code>)。
71 Unix システムではエラーを <code>syslog</code> や
72 <a href="#piped">パイプでプログラムに送る</a> ことができます。</p>
74 <p>エラーログの書式は比較的自由度の高いもので、説明的に書かれています。
75 ただし、いくつかの情報はほとんどのエラーログのエントリにあります。
76 例えば、代表的なものに次のようなメッセージがあります。</p>
79 [Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1]
80 client denied by server configuration:
81 /export/home/live/ap/htdocs/test
84 <p>ログエントリの最初の項目はメッセージの日付と時刻です。
85 二つめの項目は報告されているエラーの重要度です。
86 <directive module="core">LogLevel</directive> で重要度のレベルを
87 制限することによりエラーログに送られるエラーの種類を制御することが
88 できます。三つ目の項目はエラーを発生させたクライアントの IP アドレス
89 です。残りはメッセージで、この場合はサーバがクライアントのアクセスを
90 拒否するように設定されている、ということを示しています。
91 サーバはリクエストされた文書の (ウェブのパスではなく) ファイルシステムの
94 <p>非常に広範囲のメッセージがエラーログに現れます。たいていのものは
95 上の例のような感じです。エラーログには CGI スクリプトのデバッグ
96 出力も書かれます。CGI スクリプトが <code>stderr</code> に書いた
97 すべての情報は直接エラーログにコピーされます。</p>
99 <p>情報を追加したり削除したりしてエラーログをカスタマイズすることは
100 できません。しかし、リクエストに対するエラーログのエントリは、
101 対応するエントリが<a href="#accesslog">アクセスログ</a>にあります。
102 例えば、上の例のエントリはアクセスログのステータスコード 403 の
103 エントリに対応します。アクセスログはカスタマイズ可能ですので、
104 そちらを使うことによりエラーの状況に関する情報をより多く
107 <p>テストの最中は、問題が発生しているかどうかを見るために、
108 常にエラーログを監視するのが役に立つ場合がよくあります。
109 Unix システムでは、次のものを使うことができます。</p>
116 <section id="accesslog">
117 <title>アクセスログ</title>
121 <module>mod_log_config</module>
122 <module>mod_setenvif</module>
125 <directive module="mod_log_config">CustomLog</directive>
126 <directive module="mod_log_config">LogFormat</directive>
127 <directive module="mod_setenvif">SetEnvIf</directive>
131 <p>サーバアクセスログはサーバが処理をしたすべてのリクエストを
132 記録します。アクセスログの場所と内容は <directive
133 module="mod_log_config">CustomLog</directive>
134 ディレクティブにより決まります。ログの内容の選択を簡潔にするために
135 <directive module="mod_log_config">LogFormat</directive>
136 ディレクティブを使用することができます。このセクションはアクセスログに
137 情報を記録するためのサーバの設定方法を説明します。</p>
139 <p>もちろん、アクセスログに情報を蓄積することはログ管理の
140 始まりに過ぎません。次の段階は有用な統計を取るためにこの情報を
141 解析することです。一般的なログ解析はこの文書の範囲外で、
142 ウェブサーバ自身の仕事というわけでもありません。この話や、
143 ログ解析を行なうアプリケーションの情報を得るには、<a
144 href="http://dmoz.org/Computers/Software/Internet/Site_Management/Log_analysis/">
145 Open Directory</a> や <a
146 href="http://dir.yahoo.com/Computers_and_Internet/Software/Internet/World_Wide_Web/Servers/Log_Analysis_Tools/">
147 Yahoo</a> を調べてください。</p>
149 <p>いろんなバージョンの Apache httpd が mod_log_config,
150 mod_log_agent, <code>TransferLog</code> ディレクティブといった、
151 他のモジュールやディレクティブを使ってアクセスのロギングを
152 制御してきました。今では、<directive
153 module="mod_log_config">CustomLog</directive> がすべての古い
154 ディレクティブの機能を含むようになっています。</p>
156 <p>アクセスログの書式は非常に柔軟な設定が可能です。
157 書式は C の printf(1) フォーマット文字列に非常に似た
158 <directive module="mod_log_config">フォーマット文字列</directive>
159 により指定されます。いくつか次の節で例を示します。
160 フォーマット文字列に使用できる内容の一覧は <a
161 href="mod/mod_log_config.html">mod_log_config の文書</a>
164 <section id="common">
165 <title>Common Log Format</title>
167 <p>アクセスログのよくある設定に以下のものがあります。</p>
170 LogFormat "%h %l %u %t \"%r\" %>s %b" common<br />
171 CustomLog logs/access_log common
174 <p>これは、<em>ニックネーム</em> <code>common</code> を定義し、
175 ログのフォーマット文字列の一つと関連付けます。フォーマット文字列は
176 パーセントディレクティブからなり、それぞれのパーセントディレクティブは
177 サーバにどの情報をロギングするかを指示します。フォーマット文字列に
178 文字をそのまま入れることもでき、それらはログの出力に直接コピーされます。
179 そこに引用文字 (<code>"</code>) を書くときは、
181 されることを防ぐためにバックスラッシュでエスケープする必要があります。
182 フォーマット文字列には改行用の "<code>\n</code>"、タブ用の
183 "<code>\t</code>" という特別な制御文字も含めることができます。</p>
185 <p><directive module="mod_log_config">CustomLog</directive> ディレクティブは
187 <em>ニックネーム</em> を使って新しいログファイルを設定します。
188 アクセスログのファイル名はスラッシュで始まらない限り、
189 <directive module="core">ServerRoot</directive> からの相対パスとして
192 <p>上の設定は Common Log Format (CLF) と呼ばれる形式で
193 ログエントリを書きます。この標準の形式は異なるウェブサーバの多くが
194 生成することができ、多くのログ解析プログラムが読みこむことができます。
195 CLF により生成されたログファイルのエントリは以下のようになります:</p>
198 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
199 /apache_pb.gif HTTP/1.0" 200 2326
202 <p>このログエントリのそれぞれの部分の意味は以下で説明します。</p>
205 <dt><code>127.0.0.1</code> (<code>%h</code>)</dt>
207 <dd>これはサーバへリクエストをしたクライアント (リモートホスト)
208 の IP アドレスです。<directive
209 module="core">HostnameLookups</directive> が
210 <code>On</code> の場合は、サーバはホスト名を調べて、
211 IP アドレスが書かれているところに記録します。しかし、この設定は
212 サーバをかなり遅くするので、あまりお勧めできません。
213 そうではなく、<program>logresolve</program> の
214 ようなログの後処理を行なうプログラムでホスト名を調べるのが良いでしょう。
215 ここに報告される IP アドレスは必ずしもユーザが使っているマシンの
216 ものであるとは限りません。ユーザとサーバの間にプロキシサーバが
217 あれば、このアドレスは元のマシンのものではなく、プロキシの
220 <dt><code>-</code> (<code>%l</code>)</dt>
222 <dd>出力中の「ハイフン」は要求された情報が手に入らなかったということを
223 意味します。この場合、取得できなかった情報はクライアントのマシンの
224 <code>identd</code> により決まる RFC 1413 のクライアントの
225 アイデンティティです。この情報はあまり信用することができず、
226 しっかりと管理された内部ネットワークを除いては使うべきではありません。
228 module="core">IdentityCheck</directive> が
229 <code>On</code> になっていない限り、この情報を得ようとすらしません。</dd>
231 <dt><code>frank</code> (<code>%u</code>)</dt>
233 <dd>これは HTTP 認証による、ドキュメントをリクエストした人の
234 ユーザ ID です。CGI スクリプトには通常同じ値が <code>REMOTE_USER</code>
235 環境変数として与えられます。リクエストのステータスコード
236 (以下を参照) が 401 であった場合は、ユーザは認証に失敗しているので、
237 この値は信用できません。ドキュメントがパスワードで保護されていない
238 場合は、この部分は前のものと同じように "<code>-</code>" に
241 <dt><code>[10/Oct/2000:13:55:36 -0700]</code>
242 (<code>%t</code>)</dt>
245 サーバがリクエストを受け取った時刻です。書式は:
248 <code>[day/month/year:hour:minute:second zone]<br />
250 month = 3*letter<br />
253 minute = 2*digit<br />
254 second = 2*digit<br />
255 zone = (`+' | `-') 4*digit</code>
257 ログのフォーマット文字列に <code>%{format}t</code> を
258 指定することで、別の形式で時刻を表示させることもできます。
259 このとき、<code>format</code> は C の標準ライブラリの
260 <code>strftime(3)</code> の形式になります。
263 <dt><code>"GET /apache_pb.gif HTTP/1.0"</code>
264 (<code>\"%r\"</code>)</dt>
266 <dd>クライアントからのリクエストが二重引用符の中に示されています。
267 リクエストには多くの有用な情報があります。まず、この場合クライアントが
268 使ったメソッドは <code>GET</code> です。次に、クライアントは
269 リソース <code>/apache_pb.gif</code> を要求しました。そして、
270 クライアントはプロトコル <code>HTTP/1.0</code> を使用しました。
271 リクエストの各部分を独立にログ収集することもできます。例えば、
272 フォーマット文字列 "<code>%m %U%q %H</code>" は
273 メソッド、パス、クエリ文字列、プロトコルをログ収集し、
274 結局 "<code>%r</code>" とまったく同じ出力になります。</dd>
276 <dt><code>200</code> (<code>%>s</code>)</dt>
278 <dd>サーバがクライアントに送り返すステータスコードです。
279 この情報は、リクエストが成功応答 (2 で始まるコード) であったか、
280 リダイレクション (3 で始まるコード) であったか、クライアントによる
281 エラー (4 で始まるコード) であったか、サーバのエラー (5 で始まるコード)
282 であったか、を表すので、非常に大切です。ステータスコードの
284 href="http://www.w3.org/Protocols/rfc2616/rfc2616.txt">HTTP
285 規格</a> (RFC2616 第 10 節) にあります。</dd>
287 <dt><code>2326</code> (<code>%b</code>)</dt>
289 <dd>この最後の部分はクライアントに送信されたオブジェクトの、
290 応答ヘッダを除いたサイズを表します。コンテントがクライアントに送られなかった
291 場合は、この値は "<code>-</code>" になります。コンテントが無い場合に
292 "<code>0</code>" をログ収集するには、<code>%b</code> ではなく
293 <code>%B</code> を使ってください。</dd>
298 <section id="combined">
299 <title>Combined Log Format</title>
301 <p>もう一つのよく使われる書式は Combined Log Format と呼ばれています。
302 以下のようにして使うことができます。</p>
305 LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
306 \"%{User-agent}i\"" combined<br />
307 CustomLog log/access_log combined
310 <p>この書式の最初の方は Common Log Format とまったく同じで、最後に
311 二つ追加のエントリがあります。追加のエントリはパーセントディレクティブ
312 <code>%{<em>header</em>}i</code> を使っています。ここで
313 <em>header</em> は HTTP のリクエストヘッダのどれかです。この書式による
314 アクセスログは以下のような感じになります:</p>
317 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
318 /apache_pb.gif HTTP/1.0" 200 2326
319 "http://www.example.com/start.html" "Mozilla/4.08 [en]
326 <dt><code>"http://www.example.com/start.html"</code>
327 (<code>\"%{Referer}i\"</code>)</dt>
329 <dd>"Referer" (意図的な綴り間違い) HTTP リクエストヘッダです。
330 これはクライアントが報告してくる参照元のサイトを表します。
331 (この場合は、<code>/apache_pb.gif</code> にリンクしているか、
334 <dt><code>"Mozilla/4.08 [en] (Win98; I ;Nav)"</code>
335 (<code>\"%{User-agent}i\"</code>)</dt>
337 <dd>User-Agent HTTP リクエストヘッダです。これはクライアントのブラウザが
338 自分自身のことを報告してくる情報です。</dd>
342 <section id="multiple">
343 <title>複数のアクセスログ</title>
345 <p>複数のアクセスログは単に設定ファイルに複数の <directive
346 module="mod_log_config">CustomLog</directive>
347 ディレクティブを書くことで作成されます。例えば、以下のディレクティブは
348 三つのアクセスログを作ります。最初のものは基本的な CLF の情報で、
349 二つ目と三つ目は referer とブラウザの情報です。最後二つの
350 <directive module="mod_log_config">CustomLog</directive> は
351 <code>ReferLog</code> ディレクティブと
352 <code>AgentLog</code> ディレクティブの効果をまねる方法を示しています。</p>
355 LogFormat "%h %l %u %t \"%r\" %>s %b" common<br />
356 CustomLog logs/access_log common<br />
357 CustomLog logs/referer_log "%{Referer}i -> %U"<br />
358 CustomLog logs/agent_log "%{User-agent}i"
361 <p>この例は <directive module="mod_log_config">LogFormat</directive> で
363 ということも示しています。ニックネームの代わりに、
364 <directive module="mod_log_config">CustomLog</directive> ディレクティブに
365 直接ログの書式を指定することができます。</p>
368 <section id="conditional">
369 <title>条件付きログ</title>
371 <p>クライアントのリクエストの特徴に基づいてアクセスログにエントリの
372 一部をロギングしない方が便利なことがあります。これは <a
373 href="env.html">環境変数</a> の補助により簡単に実現できます。まず、
374 リクエストが何らかの条件に合うということを表すために環境変数が
375 設定される必要があります。これは通常は <directive
376 module="mod_setenvif">SetEnvIf</directive> により
377 行なわれます。そして、<directive
378 module="mod_log_config">CustomLog</directive> ディレクティブの
379 <code>env=</code> 節を使って環境変数が設定されているリクエストを
380 含めたり排除したりすることができます。いくつか例を挙げます:</p>
383 # Mark requests from the loop-back interface<br />
384 SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog<br />
385 # Mark requests for the robots.txt file<br />
386 SetEnvIf Request_URI "^/robots\.txt$" dontlog<br />
387 # Log what remains<br />
388 CustomLog logs/access_log common env=!dontlog
391 <p>他の例として、英語を話す人からのリクエストとそれ以外の人からのリクエストを
392 分けたい、という場合を考えてみてください。</p>
395 SetEnvIf Accept-Language "en" english<br />
396 CustomLog logs/english_log common env=english<br />
397 CustomLog logs/non_english_log common env=!english
400 <p>ここまででは条件付きロギングが非常に強力で柔軟であることを示してきましたが、
401 それがログの内容を制御する唯一の方法というわけではありません。ログファイルは
402 サーバの活動の完全な記録である方がより役に立ちます。単純にログファイルを
403 後処理して、考慮したくないログを削除する方が簡単であることがよくあります。</p>
407 <section id="rotation">
410 <p>普通の負荷のサーバでさえ、ログファイルに保存される情報の量は
411 膨大になります。アクセスログのファイルは普通 10,000 リクエスト毎に
412 1 MB 以上増えます。ですから、既存のログを移動したり、削除したりして、
413 定期的にログを交替させることが必要になります。これはサーバの実行中には
414 行なえません。というのは、Apache はファイルが open されている間は
415 ずっと古いログファイルに書き続けるからです。
416 新しいログファイルを open できるように、ログファイルが移動されたり
417 削除された後に、サーバを<a href="stopping.html">再起動</a>する
420 <p><em>優雅な</em> 再起動を行なうことで、サーバは既存のコネクションや
421 処理待ちのコネクションを失うことなく新しいログファイルを open させる
422 ことができます。しかし、これを実現するために、サーバは古いリクエストを
423 扱っている間は古いログファイルに書き続ける必要があります。
424 ですから、再起動の後ではログファイルの処理を始める前に、しばらく待たなければ
425 なりません。単にログを交替させて、ディスクの節約のために古いログを
429 mv access_log access_log.old<br />
430 mv error_log error_log.old<br />
431 apachectl graceful<br />
433 gzip access_log.old error_log.old
436 <p>ログの交替をするもう一つの方法は<a
437 href="#piped">パイプ経由のログ</a>を使うもので、次の節で説明されています。</p>
441 <title>パイプ経由のログ</title>
443 <p>Apache httpd はエラーログとアクセスログをファイルに直接書く代わりに、
444 パイプを通して別のプログラムに書き出すことができます。
445 この機能により、主サーバにコードを追加することなく
446 ロギングの柔軟性が非常に高まっています。パイプにログを書くためには、
447 単にファイル名をパイプ文字 "<code>|</code>" に置き換え、その続きに
448 標準入力からログのエントリを受けとる実行プログラムの名前を書くだけです。
449 Apache はパイプ経由のログ用のプロセスをサーバの起動時に実行し、
450 サーバの実行中にそのプログラムがクラッシュしたときはそれを再び
451 実行します。(この最後の機能がこの技術が「信頼性のあるパイプ経由のロギング」
454 <p>パイプ経由のログ用のプロセスは Apache httpd の親プロセスから起動され、
455 そのプロセスのユーザ ID を継承します。これは、パイプ経由のログ用の
456 プログラムは普通 root として実行されることを意味します。
457 ですから、プログラムを簡単で安全に保つことが非常に重要です。</p>
459 <p>パイプ経由のログの重要な利用法は、サーバの再起動なしでログの交替を
460 することです。Apache HTTP サーバにはこのための <program
461 >rotatelogs</program> と呼ばれる簡単な
462 プログラムが付属しています。たとえば、24 時間毎にログを交替させるには、
466 CustomLog "|/usr/local/apache/bin/rotatelogs
467 /var/log/access_log 86400" common
470 <p>パイプの先で呼ばれるコマンド全体が引用符で囲まれていることに注目して
471 ください。この例はアクセスログを使っていますが、エラーログにも同じ技術を
475 <a href="http://www.cronolog.org/">cronolog</a> というログ交替用の
476 プログラムが外部のサイトにあります。</p>
478 <p>条件付きロギングと同様、パイプ経由のログは非常に強力な
479 道具ですが、オフラインの後処理のような、より簡単な解決方法があるときは
483 <section id="virtualhosts">
484 <title>バーチャルホスト</title>
486 <p>多くの <a href="vhosts/">バーチャルホスト</a> のあるサーバを実行している
487 ときは、ログファイルの扱い方にいくつかの方法があります。
488 まず、単独のホストのみのサーバとまったく同じようにログを使うことができます。
489 ロギングディレクティブを主サーバのコンテキストの
490 <directive module="core"
491 type="section">VirtualHost</directive> セクションの外に置くことで、
492 すべてのログを同じアクセスログとエラーログにログ収集することができます。
493 この手法では個々のバーチャルホストの統計を簡単にとることはできません。</p>
495 <p><directive module="mod_log_config">CustomLog</directive> や
496 <directive module="mod_log_config">ErrorLog</directive> ディレクティブが
497 <directive module="core" type="section">VirtualHost</directive> の中に
499 ホストへのすべてのリクエストやエラーがそこで指定されたファイルにのみ
500 ログ収集されます。ロギングディレクティブのないバーチャルホストは
501 依然としてリクエストが主サーバのログに送られます。この手法は少ない
502 バーチャルホストに対しては非常に有用ですが、ホストの数が非常に多くなると
504 href="vhosts/fd-limits.html">ファイル記述子の限界</a>の問題を起こすことが
507 <p>アクセスログには、非常に良い妥協案があります。バーチャルホストの
508 情報をログのフォーマット文字列に加えることで、すべてのホストへの
509 リクエストを同じログにログ収集して、後でログを個々のファイルに分割することが
510 できます。たとえば、以下のディレクティブを見てください。</p>
513 LogFormat "%v %l %u %t \"%r\" %>s %b"
515 CustomLog logs/access_log comonvhost
518 <p><code>%v</code> がリクエストを扱っているバーチャルホストの名前を
519 ログ収集するために使われています。そして、<a
520 href="programs/other.html">split-logfile</a> のようなプログラムを
522 バーチャルホスト毎のファイルにログを分割することができます。</p>
524 <p>残念ながら、エラーログには同様の手法はありません。ですから、
525 すべてのバーチャルホストを同じエラーログの中に混ぜるか、
526 バーチャルホスト毎にエラーログを使うかを選ばなければなりません。</p>
530 <title>他のログファイル</title>
534 <module>mod_logio</module>
535 <module>mod_log_forensic</module>
536 <module>mod_cgi</module>
537 <module>mod_rewrite</module>
540 <directive module="mod_log_config">LogFormat</directive>
541 <directive module="mod_log_forensic">ForensicLog</directive>
542 <directive module="mpm_common">PidFile</directive>
543 <directive module="mod_rewrite">RewriteLog</directive>
544 <directive module="mod_rewrite">RewriteLogLevel</directive>
545 <directive module="mod_cgi">ScriptLog</directive>
546 <directive module="mod_cgi">ScriptLogBuffer</directive>
547 <directive module="mod_cgi">ScriptLogLength</directive>
552 <title>実際に送受信したバイト数のログ</title>
554 <p><module>mod_logio</module> は、
555 ネットワーク上で実際に送受信した数をログする
557 <directive module="mod_log_config">LogFormat</directive>
562 <title>Forensic ログ</title>
564 <p><module>mod_log_forensic</module> はクライアントリクエストの
565 forensic ログを取ります。ログはリクエスト処理前と処理後に
566 行われますので、1 リクエストに対して 2 行のログが出力されます。
567 forensic ロガーはとても厳密でカスタマイズできません。
568 デバッグやセキュリティ用のツールとして有効かもしれません。</p>
571 <section id="pidfile">
572 <title>PID ファイル</title>
574 <p>起動時に、Apache は親 httpd プロセスのプロセス ID を
575 <code>logs/httpd.pid</code> に保存します。この
577 module="mpm_common">PidFile</directive> ディレクティブを使って
578 変更することができます。プロセス ID は管理者が親プロセスに
579 シグナルを送ることでデーモンを再起動したり終了させたりするときに
580 使用します。Windows では、代わりに -k コマンドオプションを
581 使ってください。詳しい情報は <a href="stopping.html">終了と
582 再起動</a> のページを見てください。</p>
585 <section id="scriptlog">
586 <title>スクリプトログ</title>
588 <p>デバッグの補助のために、<directive
589 module="mod_cgi">ScriptLog</directive> ディレクティブは
590 CGI スクリプトの入力と出力を記録するようにできます。
591 これはテスト用にのみ使用して、通常のサーバでは使用しないでください。
593 href="mod/mod_cgi.html">mod_cgi の文書</a> にあります。</p>
596 <section id="rewritelog">
597 <title>リライトログ</title>
599 <p><directive module="mod_rewrite">mod_rewrite</directive> の強力で
601 使っているときは、ほぼいつもデバッグを簡単にするために
602 <directive module="mod_rewrite">RewriteLog</directive> の使用が
603 必要でしょう。このログファイルにはリライトエンジンがリクエストを
604 書き換える方法の詳細な解析が出力されます。詳しさの度合は <directive
605 module="mod_rewrite">RewriteLogLevel</directive>