Tracing and logging configuration

Configure tracing and logging settings to help diagnose problems or evaluate system performance.

We can configure the application server to start in a trace-enabled state by setting the appropriate configuration properties. We can only enable trace for an application client or standalone process at process startup.

In WebSphere Application Server, V6 and later, a logging infrastructure, extending Java Logging, is used. This results in the following changes to the configuration of the logging infrastructure in WebSphere Application Server:

Java Logging does not distinguish between tracing and message logging. However, previous versions of WAS have made a clear distinction between those kind of messages. In WebSphere Application Server, V6 and later, the differences between tracing and message logging are as follows:

 

Trace and logging strings

In WebSphere Application Server, V5.1.1 and earlier, trace strings were used for configuring tracing only. Starting in WebSphere Application Server, V6 and later, the "trace string" becomes a "logging string"; it is used to configure both tracing and message logging.

In WebSphere Application Server, V5.1.1 and earlier, the trace service for all WAS components is disabled by default. To request a change to the current state of the trace service, a trace string is passed to the trace service. This trace string encodes the information detailing which level of trace to enable or disable and for which components.

In all versions of WebSphere Application Server, the tracing for all components is disabled by default. To change to the current state of the tracing and message logging, a logging string must be constructed and passed to the server. This logging string specifies what level of trace or logging to enable or disable for specific components.

We can type in trace strings (or logging strings), or construct them using the administrative console. Trace and logging strings must conform to a specific grammar.

For WebSphere Application Server, V5.1.1 and earlier, the specification of this grammar is as follows

TRACESTRING=COMPONENT_TRACE_STRING[:COMPONENT_TRACE_STRING]* 

 COMPONENT_TRACE_STRING=COMPONENT_NAME=LEVEL=STATE[,LEVEL=STATE]* 

LEVEL = all | entryExit | debug | event 

STATE = enabled | disabled 

COMPONENT_NAME = COMPONENT | GROUP

For WebSphere Application Server, V6 and later, the previous grammar is supported. However a new grammar has been added to better represent the underlying infrastructure

LOGGINGSTRING=COMPONENT_LOGGING_STRING[:COMPONENT_LOGGING_STRING]* 

 COMPONENT_TRACE_STRING=COMPONENT_NAME=LEVEL

LEVEL = all | (finest | debug) | (finer | entryExit) | (fine | event ) 
| detail | config | info | audit | warning | (severe | error) | fatal | off

COMPONENT_NAME = COMPONENT | GROUP

The COMPONENT_NAME is the name of a component or group registered with the trace service logging infrastructure. Typically, WebSphere Application Server components register using a fully qualified Java class name, for example com.ibm.servlet.engine.ServletEngine. In addition, use a wildcard character of asterisk (*) to terminate a component name and indicate multiple classes or packages. For example, use a component name of com.ibm.servlet.* to specify all components whose names begin with com.ibm.servlet. Use a wildcard character of asterisk (*) at the end of the component or group name to make the logging string applicable to all components or groups whose names start with specified string. For example, a logging string specifying "com.ibm.servlet.*" as a component name will be applied to all components whose names begin with com.ibm.servlet. When an asterisk (*) is used by itself in place of the component name, the level the string specifies, will be applied to all components.

The following are examples of using an asterisk (*) in logging strings. Note that the asterisk (*) in the logging string does not need to have a period (.) in front of it. The period (.) can be used anywhere in the logging string.

Note:

 

Proceed from broad to specific trace specifications in the trace string

Best practice: Start the trace string from the most broad component groups and then select more specific traces. The advantage to this approach is that the trace settings for classes or packages that are contained in a larger group will be specified correctly by including them later in the trace string.bprac

The logging string is processed from left to right. During the processing, part of the logging string might be modified or removed if the levels they configure are being overridden by another part of the logging string.

Groups that contain packages that disable traces will disable any packages that were enabled previously on the same line. For example

*=off : MyGroup1=info : MyGroup2=finest : com.mycompany.mypackage.*=info  : com.mycompany.mypackage.MyClass=finest  
This indicates that the only tracing should come from MyGroup1, MyGroup2, and com.mycompany.mypackage.* (with more specific tracing for MyClass). If you reversed this string, all tracing would be disabled.

 

Examples

Examples of legal trace strings include:

V5 syntax V6 syntax
com.ibm.ejs.ras.ManagerAdmin=debug=enabled
com.ibm.ejs.ras.ManagerAdmin=finest
com.ibm.ejs.ras.ManagerAdmin=all=enabled,event=disabled
com.ibm.ejs.ras.ManagerAdmin=detail
com.ibm.ejs.ras.*=all=enabled
com.ibm.ejs.ras.*=all
com.ibm.ejs.ras.*=all=enabled:com.ibm.ws.ras=debug=
enabled,entryexit=enabled
com.ibm.ejs.ras.*=all:com.ibm.ws.ras=finer


Related tasks
Enabling trace on client and standalone applications Enabling trace at server startup Enabling trace on a running server Manage the application server trace service