mirror of
https://github.com/apache/httpd.git
synced 2026-01-06 09:01:14 +03:00
Replace log example with one that matches 2.4 logging.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1173098 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
@@ -107,27 +107,23 @@
|
||||
<code>syslog</code> or <a href="#piped">pipe them to a
|
||||
program</a>.</p>
|
||||
|
||||
<p>The default 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.</p>
|
||||
<p>The format of the error log is defined by the <code class="directive"><a href="./mod/core.html#errorlogformat">ErrorLogFormat</a></code> directive, with which you
|
||||
can customize what values are logged. A default is format defined
|
||||
if you don't specify one. A typical log message follows:</p>
|
||||
|
||||
<div class="example"><p><code>
|
||||
[Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1]
|
||||
client denied by server configuration:
|
||||
/export/home/live/ap/htdocs/test
|
||||
[Fri Sep 09 10:42:29.902022 2011] [core:error] [pid 35708:tid 4328636416]
|
||||
[client 72.15.99.187] File does not exist: /usr/local/apache2/htdocs/favicon.ico
|
||||
</code></p></div>
|
||||
|
||||
<p>The first item in the log entry is the date and time of the
|
||||
message. The second item lists the severity of the error being
|
||||
reported. The <code class="directive"><a href="./mod/core.html#loglevel">LogLevel</a></code>
|
||||
directive is used to control the types of errors that are sent
|
||||
to the error log by restricting the severity level. The third
|
||||
item 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.</p>
|
||||
message. The next is the module producing the message (core, in this
|
||||
case) and the severity level of that message. This is followed by
|
||||
the process ID and, if appropriate, the thread ID, of the process
|
||||
that experienced the condition. Next, we have the client address
|
||||
that made the request. And finally is the detailed error message,
|
||||
which in this case indicates a request for a file that did not
|
||||
exist.</p>
|
||||
|
||||
<p>A very wide variety of different messages can appear in the
|
||||
error log. Most look similar to the example above. The error
|
||||
@@ -135,9 +131,7 @@
|
||||
information written to <code>stderr</code> by a CGI script will
|
||||
be copied directly to the error log.</p>
|
||||
|
||||
<p>Using the <code class="directive"><a href="./mod/core.html#errorlogformat">ErrorLogFormat</a></code>
|
||||
directive, you can customize the format of the error log, and what
|
||||
values are logged. If you have <code class="module"><a href="./mod/mod_unique_id.html">mod_unique_id</a></code>, you
|
||||
<p>If <code class="module"><a href="./mod/mod_unique_id.html">mod_unique_id</a></code> is loaded, you
|
||||
can put a <code>%L</code> token in both the error log and the access
|
||||
log, producing a log entry ID with which you can correlate the entry
|
||||
in the error log with the entry in the access log.</p>
|
||||
|
||||
@@ -112,27 +112,24 @@
|
||||
<code>syslog</code> or <a href="#piped">pipe them to a
|
||||
program</a>.</p>
|
||||
|
||||
<p>The default 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.</p>
|
||||
<p>The format of the error log is defined by the <directive
|
||||
module="core">ErrorLogFormat</directive> directive, with which you
|
||||
can customize what values are logged. A default is format defined
|
||||
if you don't specify one. A typical log message follows:</p>
|
||||
|
||||
<example>
|
||||
[Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1]
|
||||
client denied by server configuration:
|
||||
/export/home/live/ap/htdocs/test
|
||||
[Fri Sep 09 10:42:29.902022 2011] [core:error] [pid 35708:tid 4328636416]
|
||||
[client 72.15.99.187] File does not exist: /usr/local/apache2/htdocs/favicon.ico
|
||||
</example>
|
||||
|
||||
<p>The first item in the log entry is the date and time of the
|
||||
message. The second item lists the severity of the error being
|
||||
reported. The <directive module="core">LogLevel</directive>
|
||||
directive is used to control the types of errors that are sent
|
||||
to the error log by restricting the severity level. The third
|
||||
item 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.</p>
|
||||
message. The next is the module producing the message (core, in this
|
||||
case) and the severity level of that message. This is followed by
|
||||
the process ID and, if appropriate, the thread ID, of the process
|
||||
that experienced the condition. Next, we have the client address
|
||||
that made the request. And finally is the detailed error message,
|
||||
which in this case indicates a request for a file that did not
|
||||
exist.</p>
|
||||
|
||||
<p>A very wide variety of different messages can appear in the
|
||||
error log. Most look similar to the example above. The error
|
||||
@@ -140,9 +137,7 @@
|
||||
information written to <code>stderr</code> by a CGI script will
|
||||
be copied directly to the error log.</p>
|
||||
|
||||
<p>Using the <directive module="core">ErrorLogFormat</directive>
|
||||
directive, you can customize the format of the error log, and what
|
||||
values are logged. If you have <module>mod_unique_id</module>, you
|
||||
<p>If <module>mod_unique_id</module> is loaded, you
|
||||
can put a <code>%L</code> token in both the error log and the access
|
||||
log, producing a log entry ID with which you can correlate the entry
|
||||
in the error log with the entry in the access log.</p>
|
||||
|
||||
Reference in New Issue
Block a user