Use this topic to configure and manage log level settings.
To view this administrative console page, click
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.