Log level settings

Use this topic to configure and manage log level settings.

To view this administrative console page, click Troubleshooting > Logs and trace > server_name > Change log detail levels

Using log levels you can control which events are processed by Java logging. When you change the level for a logger, the change is propagated to the children of the logger.

Note: This topic references one or more of the application server log files. As a recommended alternative, you can configure the server to use the High Performance Extensible Logging (HPEL) log and trace infrastructure instead of using SystemOut.log , SystemErr.log, trace.log, and activity.log files on distributed and IBM® i systems. You can also use HPEL in conjunction with your native z/OS® logging facilities. If you are using HPEL, you can access all of your log and trace information using the LogViewer command-line tool from your server profile bin directory. See the information about using HPEL to troubleshoot applications for more information on using HPEL.

Disable logging and tracing of potentially sensitive data

The application server has a list of loggers which are known to potentially write sensitive information to the log and trace when enabled. For example, enabling certain HTTP related loggers at FINEST level may result in confidential user-specified information from HTTP requests being stored in the trace files. If you want the server to avoid enabling these loggers at levels which are known to be used for potentially sensitive information, check the Disable logging and tracing of potentially sensitive data check box. When the server is started, or when the log detail level specification is modified at run time, the server will compare the list of loggers and levels specified in the log detail level specification to the list of loggers and levels in the sensitive logger list, and will update the log detail level specification as needed.

Change Log Detail Levels

Enter a log detail level that specifies the components, packages, or groups to trace. The log detail level string must conform to the specific grammar described in this topic. You can enter the log detail level string directly, or generate it using the graphical trace interface.

If you select the Configuration tab, and expand Components and Groups, a static list of well-known components, packages, and groups is displayed. This list might not be exhaustive.

If you select the Runtime tab, and expand Components and Groups, the list of components, packages, and groups are displayed with all the components that are registered on the running application server and in the static list.

The format of the log detail level specification is:

<component> = <level>

where <component> is the component for which to set a log detail level, and <level> is one of the valid logger levels (off, fatal, severe, warning, audit, info, config, detail, fine, finer, finest, all). Separate multiple log detail level specifications with colons (:).

Avoid trouble: The clauses included in a trace specification are read in the order they appear in the string. Therefore, if multiple variations of the *=info clause are included in a trace specification, the last value specified is the value that determines the trace level that the system logs. If you specify *=info as the last clause, tracing occurs at the info level regardless of other clauses that are specified in the trace string. For example, if you specified the following trace string:

*=info:PMGR=all:*=info:com.ibm.ws.sm.*=all

is equivalent to simply specifying:

*=all

Because the final clause overrides all clauses that were specified ahead of it in the string.gotcha

Components correspond to Java packages and classes, or to collections of Java packages. Use an asterisk (*) as a wildcard to indicate components that include all the classes in all the packages that are contained by the specified component. For example:

*: Specifies all traceable code running in the application server, including the product system code and customer code.
com.ibm.ws.*: Specifies all classes with the package name beginning with com.ibm.ws.
com.ibm.ws.classloader.JarClassLoader: Specifies the JarClassLoader class only.

An error can occur when setting a log detail level specification from the administrative console if selections are made from both the Groups and Components lists. In some cases, the selection made from one list is lost when adding a selection from the other list. To work around this problem, enter the log detail level specification directly into the log detail level entry field.

Select a component or group to set a log detail level. The table following lists the valid levels for application servers at WebSphere® Application Server Version 6 and later.

Avoid trouble: Logging level values are case-sensitive and begin with a lowercase letter.gotcha

Table 1. Valid logging levels. The following table lists the valid levels for application servers at WebSphere Application Server Version 6 and later.
Version 6 and later logging level	Content / Significance
off	Logging is turned off.
fatal	Task cannot continue and component, application, and server cannot function.
severe	Task cannot continue but component, application, and server can still function. This level can also indicate an impending unrecoverable error.
warning	Potential error or impending error. This level can also indicate a progressive failure (for example, the potential leaking of resources).
audit	Significant event affecting server state or resources
info	General information outlining overall task progress
config	Configuration change or status
detail	General information detailing subtask progress
fine	Trace information - General trace + method entry, exit, and return values
finer	Trace information - Detailed trace
finest	Trace information - A more detailed trace that includes all the detail that is needed to debug problems
all	All events are logged. If you create custom levels, All includes those levels, and can provide a more detailed trace than finest.

When you enable a logging level in Version 6.0 and later, you are also enabling all of the levels with higher severity. For example, if you set the logging level to warning on your Version 6.x application server, then warning, severe and fatal events are processed.

[Basic mode logging] Trace information, which are events at the Fine, Finer and Finest levels, can be written only to the trace log. Therefore, if you do not enable diagnostic trace, setting the log detail level to Fine, Finer, or Finest will not have an effect on the data that is logged.

Correlation: Specify correlation settings that you would like to enable. Select the Enable log and trace correlation check box to enable correlation for the application server. Clear the Enable log and trace correlation check box to disable correlation for the application server. Select Include request IDs in log and trace records, Include request IDs in log and trace records and correlation log records, or Include request IDs in log and trace records, create correlation log records, and capture data snapshots, as appropriate.
Best practice: Enable XCT to include request IDs in log and trace files when you want to see which log and trace entries, in all threads and application server processes, are related to the same request. Request IDs are only recorded when using HPEL log and trace mode and can be seen or used for filtering using the logViewer command. bprac

Best practice: Enable XCT to create correlation log records when you want to log how requests branch between threads and processes, and see extra information about each request. Enabling XCT to create correlation log records might have a significant performance impact on your system, so is best suited to test and development environments.bprac

Best practice: Enable XCT to capture data snapshots when you want to store entire request and response bodies to the file system. Enabling XCT to capture data snapshots might have a significant performance impact on your system, so is best suited to test and development environments. XCT captures data snapshots for message requests and responses handled by the SIBus.bprac

Avoid trouble: Data snapshots are captured and written to the $SERVER_LOG_ROOT/snapdata directory. The application server does not automatically clean up files from this directory. You will need to delete the files from this directory periodically when data snapshot capturing is enabled. Data snapshots store entire request and response contents and may include sensitive information. This option might not be appropriate for use in production environments.gotcha

Save runtime changes to configuration as well: Specifies that changes are made to both the dynamic state of the running server, and the server configuration, which takes effect on the next restart. If this check box is not selected, the server does not copy the settings into the server configuration.

File name: utrb_loglevel.html