HTTP error, FRCA, and NCSA access log settings
Use this page to configure the global HTTP error log, and National Center for Supercomputing Applications (NCSA) access log settings for an HTTP inbound channel. If we are running the product on z/OS, we can also use this page to configure the global Fast Response Cache Accelerator (FRCA) log settings for an HTTP inbound channel. A FRCA log is a specialized form of a NCSA log and can only be created in a z/OS environment.
To view this administrative console page, click Servers > Server Types > WebSphere application servers > server_name. Under Troubleshooting, click NCSA access and HTTP error logging. This console page has separate sections for each type of logging. The FRCA logging section only appears if you are running the product on z/OS.
The HTTP error log contains a record of HTTP processing errors that occur. The level of error logging that occurs is dependent on the value that is selected for the Error log level field.
The NCSA access log contains a record of all inbound client requests that the HTTP transport channel handles. All of the messages contained in a NCSA access log are in NCSA format.
The FRCA log is a specialized NCSA access log that can only be created if you are running the product on z/OS. This log contains a record of all inbound client requests that are handled by the Fast Response Cache Accelerator. All of the messages contained in this log are in NCSA format.
Configure and enabling the logging is a two step process. After you use this page to configure the logging, you must explicitly enable each type of logging for the appropriate HTTP channels. To view the settings page for an HTTP channels, click Servers > Server Types > WebSphere application servers > server > Web Container Settings > Web container transport chains > Chain > HTTP inbound channel.
In a z/OS environment, HTTP error, and NCSA access, and FRCA logging must be configured at the controller level.
The settings for any of these logs can also be modified on the settings page for a specific HTTP inbound channel. Any changes that we make on the HTTP inbound channel settings page only apply to that specific inbound channel and override any global configuration settings specified on this page.gotcha
Avoid trouble: If an HTTP inbound channel is configured to use chain specific logging, the only way to disable this logging service is through the use of the HTTP Transport Channel custom property loggingDisable. Once the custom property is set, or a change is made to its value, the server must be restarted for the changes to take effect. For more information on how to specify this custom property, see HTTP Transport Channel Custom properties. gotcha
Enable logging service at server start-up
Select this option if we want any of the following logging to start when the server starts:
- FRCA logging
- NCSA access logging
- HTTP error logging
FRCA access logging
When this field is selected, a record of inbound client requests that the HTTP transport channel handles is kept in the FRCA log.
This field only displays if you are running the product on z/OS.
Enable access logging
When this field is selected, a record of inbound client requests that the HTTP transport channel handles is kept in the FRCA log.
This field only displays if you are running the product on z/OS.
FRCA log file path
Directory path and name of the FRCA log. You should use a server-specific variable, such as $(SERVER_LOG_ROOT), to prevent log file name collisions.
This field only displays if you are running the product on z/OS.
FRCA log maximum size
Maximum size, in megabytes, of the FRCA access log. When the content of the FRCA access log reaches the specified maximum size limit, a logname.timestamp.log archive file is created. The current content of the FRCA access log is then copied to this archive log.
An example of a file name for this archive log follows:
- frca_access_11_09_20_16.15.04.log
The next time the content in the FRCA access log reaches the specified maximum log size, the content of the FRCA access log is again copied to the logname.timestamp.log archive file. The copy process overwrites the current content of the archive file with the most current content of the FRCA access log. NOTE: When there are multiple archive logs, as determined by the setting of the "Maximum number of historical files", the oldest archive log is the one overwritten.
This field only displays if you are running the product on z/OS.
Maximum number of historical files
Maximum number of historical versions of the FRCA log file that are kept for future reference.
This field only displays if you are running the product on z/OS.
FRCA log format
Specifies which FRCA format is used when logging client access information. If we select Common, the log entries contain the requested resource and a few other pieces of information, but does not contain referral, user agent, and cookie information. If we select Combined, referral, user agent, and cookie information is included.
This field only displays if you are running the product for z/OS.
NCSA access logging
Enable access logging
When selected, a record of inbound client requests that the HTTP transport channel handles is kept in the NCSA access log.
Access log file path
Directory path and name of the NCSA access log. Standard variable substitutions, such as $(SERVER_LOG_ROOT), can be used when specifying the directory path.
On the z/OS platform, you should use a server-specific variable, such as $(SERVER_LOG_ROOT), to prevent log file name collisions.
Access log maximum size
Maximum size, in megabytes, of the NCSA access log. When the content of the NCSA access log reaches the specified maximum size limit, a logname.timestamp.log archive file is created. The current content of the NCSA access log is then copied to this archive log.
An example of a file name for this archive log follows::
- ncsa_access_11_09_20_16.15.04.log
The next time the content in the NCSA access log reaches the specified maximum log size, the content of the NCSA access log is again copied to the logname.timestamp.log archive file. The copy process overwrites the current content of the archive file with the most current content of the NCSA access log. NOTE: When there are multiple archive logs, as determined by the setting of the "Maximum number of historical files", the oldest archive log is the one overwritten.
Maximum number of historical files
Maximum number of historical versions of the NCSA access log file that are kept for future reference.
We can use the EnableBuildBackupList HTTP transport custom property to enable the HTTP channel to scan for the history files in the access and error logs directory, and rolling these files over with any newer log files created. See the topic HTTP Transport channel custom properties for a description of how to specify this custom property.
NCSA access log format
Specifies which NCSA format is used when logging client access information. If we select Common, the log entries contain the requested resource and a few other pieces of information, but does not contain referral, user agent, and cookie information. If we select Combined, referral, user agent, and cookie information is included.
Entries in the NCSA access log contain a local time stamp.
We can use the HTTP transport channel custom property accessLogFormat to customize the format of the NCSA access log for a specific HTTP transport channel. See the topic HTTP transport channel custom properties for a description of how to use this custom property.
HTTP error logging
Enable error logging
When selected, HTTP errors that occur while the HTTP channel processes client requests are recorded in the HTTP error log.
Log file path
Directory path and the name of the HTTP error log. Standard variable substitutions, such as $(SERVER_LOG_ROOT), can be used when specifying the directory path.
On the z/OS platform, you should use a server-specific variable, such as $(SERVER_LOG_ROOT), to prevent log file name collisions.
Error log maximum size
Maximum size, in megabytes, of the HTTP error log. When the content of the HTTP error log reaches the specified maximum size limit, a logname.timestamp.log archive file is created. The current content of the HTTP error log is then copied to this archive log.
An example of a file name for this archive log follows::
- http_access_11_09_20_16.15.04.log
The next time the content in the HTTP error log reaches the specified maximum log size, the content of the HTTP error log is again copied to the logname.timestamp.log archive file. The copy process overwrites the current content of the archive file with the most current content of the HTTP error log. NOTE: When there are multiple archive logs, as determined by the setting of the "Maximum number of historical files", the oldest archive log is the one overwritten.
Maximum number of historical files
Maximum number of historical versions of the Error log file that are kept for future reference.
We can use the EnableBuildBackupList HTTP transport custom property to enable the HTTP channel to scan for the history files in the access and error logs directory, and rolling these files over with any newer log files created. See the topic HTTP Transport channel custom properties for a description of how to specify this custom property.
Error log format
Entries in the HTTP error log contain a Greenwich Mean Time (GMT
+ 0) time stamp.
Error log level
Type of error messages that are included in the HTTP error log.
We can select:
- Critical
- Only critical failures that stop the Application Server from functioning properly are logged.
- Error
- The errors that occur in response to clients are logged. These errors require Application Server administrator intervention if they result from server configuration settings.
- Warning
- Information on general errors, such as socket exceptions that occur while handling client requests, are logged. These errors do not typically require Application Server administrator intervention.
- Information
- The status of the various tasks that are performed while handling client requests is logged.
- Debug
- More verbose task status information is logged. This level of logging is not intended to replace RAS logging for debugging problems, but does provide a steady status report on the progress of individual client requests. If this level of logging is selected, specify a large enough log file size in the Error log maximum size field to contain all of the information that is logged.
Related tasks
Reference topic