WAS v8.5 > Reference > Log and trace file descriptions

Log level settings page

To view this dmgr console page, click...

Using log levels we 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.

IBM recommends using the HPEL log and trace infrastructure. With HPEL, one views logs using the LogViewer command-line tool in PROFILE/bin.

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. We 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 (:).

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 dmgr 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 v6 and later.

Logging level values are case-sensitive and begin with a lowercase letter.

Valid logging levels. The following table lists the valid levels for application servers at WAS v6 and later.

v6 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 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 v6.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 v6.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. If we 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 we 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..

Best practice: Enable XCT to create correlation log records when we 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.

Best practice: Enable XCT to capture data snapshots when we 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.

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.

Save runtime changes to configuration as well

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.


Related


Configure Java logging


Reference:

LogViewer command-line tool


+

Search Tips   |   Advanced Search