Operating Systems: i5/OS
             Personalize the table of contents and search results

 

Tracing and logging configuration

 

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

You can configure the application server to start in a trace-enabled state by setting the appropriate configuration properties. You 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 WebSphere Application Server 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 WebSphere Application Server 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.

You 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, you can 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 are 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 overridden by another part of the logging string. Groups that contain packages that disable traces disable any packages that are enabled previously on the same line. For example: 

*=off : MyGroup1=info : MyGroup2=finest : com.mycompany.mypackage.*=info  : com.mycompany.mypackage.MyClass=finest
This trace string indicates that the only tracing should come from the MyGroup1 group, the MyGroup2 group, and the com.mycompany.mypackage.* package with more specific tracing for MyClass class. If you reverse this string, all tracing is 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 stand-alone applications
Enabling trace at server startup
Enabling trace on a running server

 

Reference topic