4.2.6 Collecting the module trace
The Web server consists of multiple modules#, and these modules consist of multiple functions to be executed at a specific time. Module trace information indicates the trace information collected when functions in modules and CGI programs are executed. The specifications for module trace information collection, such as the destination of the module trace information collection, is changed depending on whether the HWSRequestLog directive is specified.
#: Modules refer to both external modules, which are dynamically embedded and used by using the LoadModule directive in Web server, and internal modules, which are included in the httpsd execution file.
- Organization of this subsection
(1) Trace target
The following table describes the trace target of module trace:
Trace target |
Triggers |
---|---|
Modules |
Modules consist of multiple functions. These functions are classified into functions for initialization processes and functions for request handling processes. The trace information of functions for request handling processes is collected. |
CGI programs |
Collect the trace when the CGI programs are running. |
(2) How to collect module trace information
When the HWSRequestLog directive is not specified, module trace information is collected and placed in the file specified in the ErrorLog directive according to the specification of the LogLevel directive.
When the HWSRequestLog directive is specified, module trace information is collected and placed in the file specified in the HWSRequestLog directive according to the specification of the HWSRequestLogType directive.
- Note
-
When logs are collected and placed in the file specified in the ErrorLog directive, the file can be split by virtual hosts. If logs are collected and placed in the file specified in the HWSRequestLog directive, the file cannot be split by virtual hosts.
(3) Collection level
The level of the module trace information to be collected can be changed according to the LogLevel directive or the HWSRequestLogType directive. The contents of the trace information collected at each level are as described below.
(4) Trace format
The following are output items of module trace:
Note that in the following coding, server-process-ID is used in the format when the prefork MPM is used in the UNIX version. In place of server-process-ID, server-process-ID:server-thread-ID is displayed for the worker MPM in the UNIX version, and server-thread-ID is displayed in the Windows version.
(a) Modules
-
When log is output to the info level
- Call time
[Time]Δ(server-process-ID)Δ[info]ΔhwsΔ:ΔmoduleΔ-->Δ(module-file-name[function-offset])
- Return time
[Time]Δ(server-process-ID)Δ[info]ΔhwsΔ:ΔmoduleΔ<--Δ(module-file-name[function-offset])(result-code)
Legend:
Δ: Space
The following table describes the relationship between the function offset and the functions:
Table 4‒4: Relationship between function offsets and the functions Function offset
Function name
Meaning
[0]
create_request
Executing the request start process.
[1]
post_read_request
Executing the process after reading the request.
[2]
quick_handler
Executing the process before changing the requested URL.
[3]
translate_name
Executing the process to change the actual file name from the requested URL.
[4]
map_to_storage
Executing the request process that does not involve disk access.
[5]
header_parser
Executing the process to analyze the request header.
[6]
access_checker
Checking the access permission by the host name, and the IP address for the URL requested from an authenticated user.
[7]
check_user_id
Checking the user ID.
[8]
auth_checker
Checking the access permission (Require) for the URL requested from an authenticated user.
[9]
type_checker
Checking the MIME type.
[10]
fixups
Executing the process before request execution.
[11]
insert_filter
Executing the filter insertion process.
[12]
handler
Executing handler.
[13]
insert_error_filter
Executing the process before responding to error.
[14]
log_transaction
Executing the log output process.
[15]
error_log
Executing the process after error log output.
[16]
get_suexec_identity
Executing the process to acquire the user information.
[17]
pre_read_request
Executing the process before reading the request.
[18]
access_checker_ex
Checking the additional access permissions.
[Fri Jul 15 17:29:43 2005] (1864) [info] hws : module --> (mod_example.c[1]) [Fri Jul 15 17:29:43 2005] (1864) [info] hws : module <-- (mod_example.c[1])(-1)
-
When log is output to debug level
- Call time
[Time]Δ(server-process-ID)Δ[debug]Δfile-name(line-number):ΔhwsΔ:ΔmoduleΔ-->Δ(module-file-name[function-offset])
- Return time
[Time]Δ(server-process-ID)Δ[debug]Δfile-name(line-number):ΔhwsΔ:ΔmoduleΔ<--Δ(module-file-name[function-offset])(result-code)
- Legend:
-
Δ: Space
- (Output example)
[Fri Jul 15 17:29:43 2005] (1864) [debug] request.c(69): hws : module --> (mod_alias.c[3]) [Fri Jul 15 17:29:43 2005] (1864)[debug] request.c(69): hws : module <-- (mod_alias.c[3])(-1)
(b) CGI program
-
When module trace information is output at the info level
- Call time
[Time]Δ(server-process-ID)Δ[info]ΔhwsΔ:ΔcgiΔ-->Δ(exec=cgi-file-name)(argv0=execution-program-name)(args=arguments#)(cgi-process-ID)
#: The argument from args is displayed only when the specified query is followed by a + (plus) and not by = (is equals to), as in the case of GET. /cgi-bin/isindex?aaa+bbb+ccc HTTP/1.0.
- Return time
[Time]Δ(server-process-ID)Δ[info]ΔhwsΔ:ΔcgiΔ<--Δ(exec=cgi-file-name)(argv0= execution-program-name)(cgi-process-ID)
- Legend:
-
Δ: Space
- (Output example)
[Fri Jul 15 19:48:08 2012] (1784) [info] hws : cgi --> (exec=Application Server-installation-directory/httpsd/cgi-bin/isindex)(argv0=isindex)(args=aaa+bbb+ccc)(1144) [Fri Jul 15 19:48:08 2012] (1784) [info] hws : cgi <-- (exec=Application Server-installation-directory/httpsd/cgi-bin/isindex)(argv0=isindex)(1144)
(5) How to use
(a) Usage example
An example to output info-level module trace information and request trace information to the request log is as follows:
HWSRequestLogType module-info request HWSRequestLog logs/hwsrequest.log