Oracle HTTP Server generates log files containing messages that record all types of events, including startup and shutdown information, errors, warning messages, access information on HTTP requests, and additional information.
This chapter includes the following sections:
You can view Oracle Fusion Middleware log files using either Fusion Middleware Control or a text editor. The log files for Oracle HTTP Server are located in the following directory:
ORACLE_HOME/user_projects/domains/<base_domain>/servers/componentName/logs
Oracle HTTP Server has two types of logs:
Error logs, which record server problems.
Access logs, which record which components and applications are being accessed and by whom.
This section contains the following topics:
Oracle HTTP Server enables you to choose the format in which you want to generate log messages. You can choose to generate log messages in the legacy Apache HTTP Server message format, or use Oracle Diagnostic Logging (ODL) to generate log messages in text or XML-formatted logs, which complies with Oracle standards for generating error log messages.
By default, Oracle HTTP Server error logs use ODL for generating diagnostic messages. It provides a common format for all diagnostic messages and log files, and a mechanism for correlating the diagnostic messages from various components across Oracle Fusion Middleware.
The default name of the error log file is instance_name.log.
Note:
ODL error logging cannot have separate log files for each virtual host. It can only be configured globally for all virtual hosts.
Access logs record all requests processed by the server. The logs contain basic information about every HTTP transaction handled by the server. The access log contains the following information:
Host name
Remote log name
Remote user and time
Request
Response code
Number of transferred bytes
The default name of the access log file is access_log.
Access Log Format
You can specify the information to include in the access log, and the manner in which it is written. The default format is the Common Log Format (CLF).
LogFormat "%h %l %u %t %E \"%r\" %>s %b" common
The CLF format contains the following fields:
host ident remote_logname remote_usre date ECID request authuser status bytes
host
: This is the client domain name or its IP number. Use %h
to specify the host field in the log.
ident
: If IdentityCheck is enabled and the client system runs identd, this is the client identity information. Use %i
to specify the client identity field in the log.
remote_logname
: Remote log name (from identd
, if supplied). Use %l
to specify the remote log name in the log.
remote_user
: Remote user if the request was authenticated. Use %u
to specify the remote user in the log.
date
: This is the date and time of the request in the day/month/year:hour:minute:second format. Use %t
to specify date and time in the log.
ECID
: Capture ECID information. Use %E
to capture ECID in the log. See also Configuring Access Logs for ECID Information.
request
: This is the request line, in double quotes, from the client. Use %r
to specify request in the log.
authuser
: This is the user ID for the authorized user. Use %a
to specify the authorized user field in the log.
status
: This is the three-digit status code returned to the client. Use %s
to specify the status in the log. If the request will be forwarded from another server, use %>s
to specify the last server in the log.
bytes
: This is the number of bytes, excluding headers, returned to the client. Use %b
to specify number of bytes in the log. Use %i
to include the header in the log.
See Also:
"Access Log" in the Apache HTTP Server documentation.
Oracle HTTP Server supports two types of log rotation policies: size-based and time-based. You can configure the Oracle HTTP Server logs to use either of the two rotation polices, by using odl_rotatelogs
in ORACLE_HOME/ohs/bin. By default, Oracle HTTP Server uses odl_rotatelogs
for both error and access logs.
odl_rotatelogs
supports all the features of Apache HTTP Server's rotatelogs
and the additional feature of log retention.
You can find information about the features and options provided by rotatelogs
at the following URL:
http://httpd.apache.org/docs/2.4/programs/rotatelogs.html
The following is the general syntax of odl_rotatelogs
:
odl_rotatelogs [-u:offset] logfile {size-|time-based-rotation-options}
odl_rotatelogs
is meant to be used with the piped logfile feature. This feature allows error and access log files to be written through a pipe to another process, rather than directly to a file. This increases the flexibility of logging, without adding code to the main server. To write logs to a pipe, replace the filename with the pipe character "|
", followed by the name of the executable which should accept log entries on its standard input. For more information on the piped logfile feature, see the following URL:
http://httpd.apache.org/docs/2.4/logs.html#piped
Used with the piped logfile feature, the syntax of odl_rotatelogs
becomes the following:
CustomLog " |${PRODUCT_HOME}/bin/odl_rotatelogs [-u:offset] logfile {size-|time-based-rotation-options}" log_format
Whenever there is an input to odl_rotatelogs
, it checks if the specified condition for rotation has been met. If so, it rotates the file. Otherwise it simply writes the content. If no input is provided, then it will do nothing.
Table 8-1 describes the size- and time-based rotation options:
Table 8-1 Options for odl_rotatelogs
Option | Description |
---|---|
|
The time (in seconds) to offset from UTC. |
|
The path and name of the log file, followed by a hyphen (-) and then the timestamp format. The following are the common timestamp format strings:
It should not include formats that expand to include slashes. |
|
The time (in seconds) between log file rotations. |
|
The maximum time for which the rotated log files are retained. |
|
The time when time-based rotation should start. |
|
The maximum size (in MB) of log files. |
|
The total size (in MB) of files retained. |
With time-based rotation, log rotation of Oracle HTTP Server using the odl_rotatelogs
is calculated by default according to UTC time. For example, setting log rotation to 86400 (24 hours) rotates the logs every 12:00 midnight, UTC. If is running on a server in IST (Indian Standard Time) which is UTC+05:30, then the logs are rotated at 05:30 a.m.
As an alternative to using the -u
option with the UTC offset, you can use the -l
option provided by Apache. This option causes to use local time as the base for the interval. Using the-l
option in an environment which changes the UTC offset (such as British Standard Time (BST) or Daylight Savings Time (DST)) can lead to unpredictable results.
The following examples demonstrate the odl_rotatelogs syntax to set time- and size-based log rotation.
Time-based rotation
Syntax:
odl_rotatelogs u:offset logfile frequency retentionTime startTime
Example:
CustomLog "| odl_rotatelogs u:-18000 /varlog/error.log-%Y-%m-%d 21600 172800 2014-03-10T08:30:00" common
This configures log rotation to be performed for a location UTC-05:00 (18000 seconds, such as New York). The rotation will be performed every 21600 seconds (6 hours) starting from 8:30 a.m. on March 10, 2014, and it specifies that the rotated log files should be retained for 172800 seconds (2 days). The log format is common
.
Syntax:
odl_rotatelogs logfile frequency retentionTime startTime
Example:
CustomLog "| odl_rotatelogs /varlog/error.log-%Y-%m-%d 21600 172800 2014-03-10T08:30:00" common
This configures log rotation to be performed every 21600 seconds (6 hours) starting from 8:30 a.m. on March 10, 2014, and it specifies that the rotated log files should be retained for 172800 seconds (2 days). The log format is common
.
Size-based rotation
Syntax:
odl_rotatelogs logfile maxFileSize allFileSize
Example:
This configures log rotation to be performed when the size of the log file reaches 10 MB, and it specifies the maximum size of all the rotated log files as 70 MB (up to 7 log files (=70/10) will be retained). The log format is common
.
CustomLog "| odl_rotatelogs /var/log/error.log-%Y-%m-%d 10M 70M" common
You can use Fusion Middleware Control to configure error and access logs. The following sections describe logging tasks that can be set from the Log Configuration page:
You configure error logs on the Fusion Middleware Control Log Configuration page. To configure an error log for Oracle HTTP Server using Fusion Middleware Control, do the following:
You can change the error log format and location on the Fusion Middleware Control Log Configuration page. By default, Oracle HTTP Server uses ODL-Text as the error log format and creates the log file with the name component_name
.log
under the DOMAIN_HOME/servers/component_name/logs directory. To use a different format or log location, do the following:
You can configure the amount and type of information written to log files by specifying the message type and level. Error log level for Oracle HTTP Server by default is configured to WARNING:32. To use a different error log level do the following:
Note:
The log levels are different for the Apache HTTP Server log format and ODL-Text format.
For details on ODL log levels, refer to "Setting the Level of Information Written to Log Files" in the Administering Oracle Fusion Middleware.
For details on Apache HTTP Server log levels, refer to the LogLevel Directive in the Apache HTTP Server documentation.
Log rotation policy for error logs can either be time-based, such as once a week, or sized-based, such as 120MB. By default, the error log file is rotated when it reaches 10 MB and a maximum of 7 error log files will be retained. To use a different rotation policy, do the following:
You can configure an access log format and rotation policy for Oracle HTTP Server from the Fusion Middleware Control Log Configuration page.
The following access log configuration tasks can be set from this page:
Log format specifies the information included in the access log file and the manner in which it is written. To add a new access log format or to edit or remove an existing format, do the following:
Set the value of default file mode creation mask (umask
) before starting the Oracle HTTP Server instance. The value that you set for umask determines the file permissions for the files created by Oracle HTTP Server instance such as the error log, access log, and so on. If umask
is not set explicitly, then a value of 0027
is used by default.
This section contains the following information:
To configure the default file mode creation mask in a standalone domain, set the umask
property in the ohs.plugins.nodemanager.properties
file under the staging location:
DOMAIN_HOME
/config/fmwconfig/components/OHS/
instanceName
/ohs.plugins.nodemanager.properties
You can use WLST commands to set the LogLevel directive, which controls the verbosity of the error log.
Note:
For more information on the LogLevel directive, see the Apache documentation: http://httpd.apache.org/docs/current/mod/core.html#loglevel
Follow these steps to set the LogLevel directive using WLST commands.
The following sections describe Oracle HTTP Server error and access log-related directives in the httpd.conf
file.
Oracle HTTP Server by default uses Oracle Diagnostic Logging (ODL) for generating diagnostic messages. The following directives are used to set up logging using ODL:
Enables you to choose the format in which you want to generate log messages. You can choose to generate log messages in the legacy Apache HTTP Server or ODL text format.
OraLogMode Apache | ODL-Text
Default value: ODL-Text
For example: OraLogMode ODL-Text
Note:
The Apache HTTP Server log directives ErrorLog
and LogLevel
are only effective when OraLogMode
is set to Apache
. When OraLogMode
is set to ODL-Text
, the ErrorLog
and LogLevel
directives are ignored.
Specifies the path to the directory that contains all log files. This directory must exist.
This directive is used only when OraLogMode is set to ODL-Text
. When OraLogMode
is set to Apache
, OraLogDir
is ignored and ErrorLog is used instead.
OraLogDir <path>
Default value: ORACLE_INSTANCE/servers/componentName/logs
For example: OraLogDir /tmp/logs
Enables you to set message severity. The message severity specified with this directive is interpreted as the lowest desired message severity, and all messages of that severity level and higher are logged.
This directive is used only when OraLogMode
is set to ODL-Text
. When OraLogMode
is set to Apache
, OraLogSeverity
is ignored and LogLevel is used instead. In the following syntax, short_module_identifierName
is the module name with the trailing _module
omitted.
OraLogSeverity [short_module_identifierName] <msg_type>[:msg_level]
Default value: WARNING:32
For example: OraLogSeverity mime NOTIFICATION:32
msg_type
Message types can be specified in upper or lowercase, but appear in the message output in upper case. This parameter must be of one of the following values:
INCIDENT_ERROR
ERROR
WARNING
NOTIFICATION
TRACE
msg_level
This parameter must be an integer in the range of 1–32, where 1 is the most severe, and 32 is the least severe. Using level 1 will result in fewer messages than using level 32.
Enables you to choose the rotation policy for an error log file. This directive is used only when OraLogMode is set to ODL-Text
. When OraLogMode
is set to Apache
, OraLogRotationParams
is ignored.
OraLogRotationParams <rotation_type> <rotation_policy>
Default value: S 10:70
For example: OraLogRotationParams T 43200:604800 2009-05-08T10:53:29
rotation_type
This parameter can either be S
(for sized-based rotation) or T
(for time-based rotation).
rotation_policy
When rotation_type
is set to S
(sized-based), set the rotation_policy parameter to:
maxFileSize:allFilesSize
(in MB)
For example, when configured as 10:70
, the error log file is rotated whenever it reaches 10MB and a total of 70MB is allowed for all error log files (a maximum of 70/10=7 error log files will be retained).
When rotation_type is set to T
(time-based), set the rotation_policy parameter to:
frequency(in sec) retentionTime(in sec) startTime(in YYYY-MM-DDThh:mm:ss)
For example, when configured as 43200:604800 2009-05-08T10:53:29
, the error log is rotated every 43200 seconds (that is, 12 hours), rotated log files are retained for maximum of 604800 seconds (7 days) starting from May 5, 2009 at 10:53:29.
Although Oracle HTTP Server uses ODL by default for error logs, you can configure the OraLogMode
directive to Apache
to generate error log messages in the legacy Apache HTTP Server message format. The following directives are discussed in this section:
The ErrorLog
directive sets the name of the file where the server logs any errors it encounters. If the filepath is not absolute then it is assumed to be relative to the ServerRoot.
This directive is used only when OraLogMode
is set to Apache
. When OraLogMode
is set to ODL-Text
, ErrorLog is ignored and OraLogDir
is used instead.
See Also:
For information about the Apache ErrorLog directive, see:
The LogLevel
directive adjusts the verbosity of the messages recorded in the error logs.
This directive is used only when OraLogMode
is set to Apache
. When OraLogMode
is set to ODL-Text
, LogLevel is ignored and OraLogSeverity is used instead.
See Also:
For information about the Apache HTTP Server LogLevel directive see:
The LogFormat
directive specifies the format of the access log file. By default, Oracle HTTP Server comes with the following four access log formats defined:
LogFormat "%h %l %u %t %E \"%r\" %>s %b" commonLogFormat "%h %l %u %t %E \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combinedLogFormat "%h %l %u %t %E \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio
See Also:
For information about the Apache HTTP Server LogFormat directive, see:
http://httpd.apache.org/docs/current/mod/mod_log_config.html#logformat
Use the CustomLog
directive to log requests to the server. A log format is specified and the logging can optionally be made conditional on request characteristics using environment variables. By default, the access log file is configured to use the common log format.
See Also:
For information about the Apache CustomLog directive, see:
http://httpd.apache.org/docs/current/mod/mod_log_config.html#customlog
There are mainly two types of log files for Oracle HTTP Server: error logs and access logs. The error log file is an important source of information for maintaining a well-performing server. The error log records all of the information about problem situations so that the system administrator can easily diagnose and fix the problems. The access log file contains basic information about every HTTP transaction that the server handles. You can use this information to generate statistical reports about the server's usage patterns.
See Overview of Server Logs for more information on error logs and access logs.
The methods for viewing Oracle HTTP Server logs are:
To access the log messages for an Oracle HTTP Server instance:
For information about searching and viewing log files, see "Viewing Log Files and Their Messages Using Fusion Middleware Control" in Administering Oracle Fusion Middleware.
To obtain and view server logs from the command line, you need to connect to Node Manager and issue the appropriate WebLogic Scripting Tool (WLST) command. These commands allow you to perform any of these functions:
List server logs.
Display the content of a specific log.
Note:
For more information on using WLST, see Understanding the WebLogic Scripting Tool.
Before attempting this procedure:
Before attempting to access server metrics from the command line, ensure the following:
The domain exists.
The instance you want to start exists.
Node Manager is running on the instance machine.
To use this procedure, the instance and Administration server can be running but do not need to be.
To view metrics using WLST:
Note:
For managed domains, this procedure will work on an Administration server running on either the Administration machine or on a remote machine, whether the instance is in a running state or a shutdown state. For standalone domains, the procedure will work only on a local machine; however the instance can be either in a running or shutdown state.
You can also use a text editor to view Oracle HTTP Server log files directly from the DOMAIN_HOME directory. By default, Oracle HTTP Server log files are located in the DOMAIN_HOME/servers/component_name/logs directory. Download a log file to your local client and view the log files using another tool.
The following sections describe how to configure Oracle HTTP Server to record Execution Context ID (ECID) information in error logs and access logs.
An ECID is a globally unique ID that can be attached to requests between Oracle components. The ECID enables you to track log messages pertaining to the same request when multiple requests are processed in parallel.
The Oracle HTTP Server module mod_context
scans each incoming request for an ECID-Context key in the URI or cookie, or for the ECID-Context header. If found, then the value is used as the execution context if it is valid. If it is not, then mod_context creates a new execution context for the request and adds it as the value of the ECID-Context header.
ECID information is recorded as part of Oracle Diagnostic Logging (ODL). ODL is a method for reporting diagnostic messages which presents a common format for diagnostic messages and log files, and a method for correlating all diagnostic messages from various components.
To configure Oracle HTTP Server error logs to record ECID information, ensure that the OraLogMode
directive in the httpd.conf
file is set to the default value, odl
. The odl
value specifies standard Apache log format and ECID information for log records specifically associated with a request.
For more information on OraLogMode
and other possible values for this directive, see OraLogMode.
Note:
Oracle recommends that you enter the directives before any modules are loaded (LoadModule
directive) in the httpd.conf
file so that module-specific logging severities are in effect before modules have the opportunity to perform any logging.
By default, the LogFormat
directive in the httpd.conf
file is configured to capture ECID information:
LogFormat "%h %l %u %t %E \"%r\" %>s %b" common
If you want to add response time measured in microseconds, then add %D
as follows:
LogFormat "%h %l %u %t %E %D \"%r\" %>s %b" common
If you want to suppress the capture of ECID information, then remove %E
from the LogFormat
directive:
LogFormat "%h %l %u %t \"%r\" %>s %b" common
The following sections describe how to terminate requests using SSL before or within Oracle HTTP Server, where the mod_wl_ohs
module forwards requests to WebLogic Server. Whether you terminate SSL before the request reaches Oracle HTTP Server or when the request is in the server, depends on your topology. A common reason to terminate SSL is for performance considerations when an internal network is otherwise protected with no risk of a third-party intercepting data within the communication. Another reason is when WebLogic Server is not configured to accept HTTPS requests.
If you are using another device such as a load balancer or a reverse proxy which terminates requests using SSL before reaching Oracle HTTP Server, then you must configure the server to treat the requests as if they were received through HTTPS. The server must also be configured to send HTTPS responses back to the client.
Figure 8-1 illustrates an example where the request transmitted from the browser through HTTPS to WebLogic Server. The load balancer terminates SSL and transmits the request as HTTP. Oracle HTTP Server must be configured to treat the request as if it was received through HTTPS.
Figure 8-1 Terminating SSL Before Oracle HTTP Server
To instruct the Oracle HTTP Server to treat requests as if they were received through HTTPS, configure the httpd.conf
file with the SimulateHttps
directive in the mod_certheaders
module.
For more information on mod_certheaders
module, see mod_certheaders Module—Enables Reverse Proxies.
Note:
This procedure is not necessary if SSL is configured on Oracle HTTP Server (that is, if you are directly accessing Oracle HTTP Server using HTTPS).
If SSL is configured in Oracle HTTP Server but not on Oracle WebLogic Server, then you can terminate SSL for requests sent by Oracle HTTP Server.
The following figures illustrate request flows, showing where HTTPS stops. In Figure 8-2, an HTTPS request is sent from the browser. The load balancer transmits the HTTPS request to Oracle HTTP Server. SSL is terminated in Oracle HTTP Server and the HTTP request is sent to WebLogic Server.
Figure 8-2 Terminating SSL at Oracle HTTP Server—With Load Balancer
In Figure 8-3 there is no load balancer and the HTTPS request is sent directly to Oracle HTTP Server. Again, SSL is terminated in Oracle HTTP Server and the HTTP request is sent to WebLogic Server.
Figure 8-3 Terminating SSL at Oracle HTTP Server—Without Load Balancer