Log level settings
From the admin console, click...
-
Troubleshooting > Logs and trace > server > Change log detail levels
Using log levels we can control which events are processed by Java logging. When we change the level for a logger, the change is propagated to the children of the logger.
IBM recommends using the High Performance Extensible Logging (HPEL) log and trace infrastructure. We view HPEL log and trace information using the logViewer.
- 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 we 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 we 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 we 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 (:).
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 the system logs. If we specify *=info as the last clause, tracing occurs at the info level regardless of other clauses specified in the trace string. For example, if we 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.
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 contained by the specified component. For example:
* All traceable code running in the application server, including the product system code and customer code. com.ibm.ws.* All classes with the package name beginning with com.ibm.ws. com.ibm.ws.classloader.JarClassLoader 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 v6 and later.
Logging level values are case-sensitive and begin with a lowercase letter.
| 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 we create custom levels, All includes those levels, and can provide a more detailed trace than finest. |
When we enable a logging level in v6.0 and later, we are also enabling all of the levels with higher severity. For example, if we set the logging level to warning on our 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. Therefore, 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 we would like to enable. To enable correlation for the application server, select the checkbox...
-
Enable log and trace correlation
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.
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. bprac
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 the system, so is best suited to test and development environments.bprac
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 the system, so is best suited to test and development environments. XCT captures data snapshots for message requests and responses handled by the SIBus.bprac
Data snapshots are captured and written to...
-
$SERVER_LOG_ROOT/snapdata
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
- 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.