Log levels

WebSphere application server lets you define what all logging messages should be logged to the trace.log file.

These are the log levels defined by WAS

• Off: No events are logged.


• Fatal: Task cannot continue and component cannot function.


• Severe: Task cannot continue, but component can still function


• Warning: Potential error or impending error


• 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 / return values


• Finer: Trace information - Detailed trace


• Finest: Trace information - A more detailed trace - Includes all the detail that is needed to debug problems


• All: All events are logged. If you create custom levels, All includes your custom levels, and can provide a more detailed trace than Finest.

Enabling trace using WSAdmin Script

You can use the following WSAdmin script to enable Runtime and Server startup time trace

Runtime trace


def enableRunTimeTrace(serverName, traceString):
ts = AdminControl.queryNames("type=TraceService,process="+serverName+",*")
AdminControl.setAttribute(ts,"traceSpecification",traceString)

enableRunTimeTrace("server1","com.ibm.websphere.*=finest")


Configuration/ Server Startup Time trace



def enableConfigurationTimeTrace(serverId, traceString):
server = AdminConfig.getid('/Cell:sunpatil-wxp02Node01Cell/Node:sunpatil-wxp02Node01/Server:server1/')
print server
ts = AdminConfig.list("TraceService",server)
print ts
AdminConfig.modify(ts,[['startupTraceSpecification',traceString]])
AdminConfig.save()

enableConfigurationTimeTrace("server1","com.ibm.websphere.*=finest")


Startup time vs. Run time trace

After enabling trace, you will have to decide the java packages for which you want to turn the trace on. You can do that from WAS Admin Console by going to TroubleShooting -< Logging and Tracing -< servername. Then on the Logging and Tracing page click on Change Log Details Level



For changing Log Detail level, you can change them either on the COnfiguration tab or on the Runtime tab

• Configuration: The log details level that you set here will be persisted in the server.xml file and the changes that you make wont take effect until you restart the server. Also since the changes are persisted in server.xml they will be effective across server restart unless you change them


• Runtime: The Changes that you make on the Runtime tab take effect immediately but these changes wont be saved to server.xml configuration file instead they will be kept in memory, as a result your changes would be lost when you restart the server

Trace Output Format

On the Diagnostic Trace Services page there is Trace Format select box that lets you decide what format should be used for generating trace.



As you can see you have three options for what format you want to choose

1. Basic: The events displayed in the basic format use the following format
   
<timestamp><threadId><shortName><eventType>[className][methodName]<textmessage>
[parameter 1]
[parameter 2]

   This is sample output generated for basic format
   
[7/5/09 21:04:13:984 PDT] 00000025 HttpRequestMe 3 setMethod(v): GET
[7/5/09 21:04:13:984 PDT] 00000025 HttpRequestMe 3 setRequestURL input [/ibm/console/configSpecDetail.do?EditAction=true&perspective=tab.runtime]
[7/5/09 21:04:13:984 PDT] 00000025 HttpRequestMe 3 setQueryString(byte[]): set query to [EditAction=true&perspective=tab.runtime]
[7/5/09 21:04:13:984 PDT] 00000025 HttpRequestMe 3 setRequestURL: set URI to /ibm/console/configSpecDetail.do
[7/5/09 21:04:13:984 PDT] 00000025 HttpBaseMessa 3 Called setVersion(b): HTTP/1.1
values

   The Basic format is recommended format that makes it easier to read the trace message. When your submitting trace to IBM Support team you should use Basic format.
   


2. Advanced: The Advanced format trace uses little more complex format than the basic format. This is the format used for Advanced format
   
<timestamp><threadId><eventType><UOW><source=longName>[className][methodName]
<Organization><Product><Component>[thread=threadName]
<textMessage>[parameter 1=parameterValue][parameter 2=parameterValue]

   These are couple of sample trace messages generated for the advanced format
   
[7/5/09 21:50:49:031 PDT] 00000029 I UOW=null source=com.ibm.ws.webcontainer.servlet.ServletWrapper org=IBM prod=WebSphere component=Application Server thread=[WebContainer : 1]
SRVE0242I: [ConnectionLeakEAR] [/connleak] [FormPostServlet]: Initialization successful.
[7/5/09 21:50:49:046 PDT] 00000029 O UOW= source=SystemOut org=IBM prod=WebSphere component=Application Server thread=[WebContainer : 1]
Inside FormPostServlet.doPost() Exit

   


3. Log Analyzer: If you select the Log Analyzer format then it will generate the trace in the same form as that generated by showlog tool, when it converts the binary activity.log file to text format.
   
   
---------------------------------------------------------------
ComponentId: Application Server
ProcessId: 5368
ThreadId: 00000029
ThreadName: WebContainer : 3
SourceId: com.ibm.ws.http.channel.impl.HttpResponseMessageImpl
ClassName:
MethodName:
Manufacturer: IBM
Product: WebSphere
Version: Platform 6.1 [BASE 6.1.0.25 cf250922.06]
ServerName: sunpatil-wxp02Node01Cell\sunpatil-wxp02Node01\server1
TimeStamp: 2009-07-05 21:11:24.062000005
UnitOfWork:
Severity: 3
Category: FINEST
PrimaryMessage: setReasonPhrase(byte[]): set to [OK]
ExtendedMessage:
---------------------------------------------------------------
ComponentId: Application Server
ProcessId: 5368
ThreadId: 00000029
ThreadName: WebContainer : 3
SourceId: com.ibm.ws.webcontainer.servlet.ServletWrapper
ClassName:
MethodName:
Manufacturer: IBM
Product: WebSphere
Version: Platform 6.1 [BASE 6.1.0.25 cf250922.06]
ServerName: sunpatil-wxp02Node01Cell\sunpatil-wxp02Node01\server1
TimeStamp: 2009-07-05 21:11:24.078000000
UnitOfWork:
Severity: 3
Category: INFO
PrimaryMessage: SRVE0242I: [ConnectionLeakEAR] [/connleak] [FormPostServlet]: Initialization successful.
ExtendedMessage:
---------------------------------------------------------------

   

Please note that you can read trace in any of these formats using Log ANalyzer tool.

Basic and Advanced Formats use many of the same fields and formatting techniques. The fields that can be used in these formats include:

• TimeStamp: The timestamp is formatted using the locale of the process where it is formatted. It includes a fully qualified date (YYMMDD), 24 hour time with millisecond precision and the time zone.


• ThreadId: An 8 character hexadecimal value generated from the hash code of the thread that issued the trace event.


• ThreadName: The name of the Java thread that issued the message or trace event.


• ShortName :The abbreviated name of the logging component that issued the trace event. This is typically the class name for WebSphere Application Server internal components, but may be some other identifier for user applications.


• LongName: The full name of the logging component that issued the trace event. This is typically the fully qualified class name for WebSphere Application Server internal components, but may be some other identifier for user applications.


• EventType: A one character field that indicates the type of the trace event. Trace types are in lower case. Possible values include:
  
  >
  a trace entry of type method entry.
  <
  a trace entry of type method exit.
  1
  a trace entry of type fine or event.
  2
  a trace entry of type finer.
  3
  a trace entry of type finest, debug or dump.
  Z
  a placeholder to indicate that the trace type was not recognized.
  


• ClassName: The class that issued the message or trace event.


• MethodName:The method that issued the message or trace event.


• Organization:The organization that owns the application that issued the message or trace event.


• Product:The product that issued the message or trace event.


• Component: The component within the product that issued the message or trace event.

What is diagnostic trace

WebSphere Application server components as well as most of the enterprise level applications use Logging framework to generate detailed trace for execution. By default this trace is disabled because it causes performance overhead but you can turn the trace on for either your application or the particular websphere component when you want to debug issue.

When you open a support request with IBM support, most of the time they will ask you to enable the trace for particular area and send the generated trace to them for further analysis of the problem.

You can turn the trace on using the WAS Admin Console GUI by going to TroubleShooting -> Logs and Trace -< Servrname. On the Logging and Tracing screen, select the Diagnostic trace.



On the Diagnostic Trace Services screen you can enable the trace by checking Enable Log checkbox.



On this screen you can also define where the output of the trace should go, you have following two options

• Memory Buffer: If you select the Memory buffer option then your messages wont be written to any file instead they will be kept in memory. But in order for you to view the messages you will have to dump the memory in file and then view it. This is not recommended option


• File: Once you decide to send the log messages to the file system it allows you to configure following properties
  
  
  
  • Maximum File Size: What should be maximum size of the trace file. Once the trace file size reaches this limit, the trace.log file would be renamed to trace+timestamp.log file and a new trace.log file would be created
  
  
  • Maximum Number of Historical Files: What is the maximum no. of historical files that should be preserved. When the trace.log reaches maximum first the WAS server would check if no. of historical files is reached if yes delete the oldest trace file.
  
  
  • File Name: Fully qualified path name where the trace file should be generated
  
  
  
  

Whatever changes you make on Configuration tab are persisted in server.xml and they require server restart for those changes to take effect. But if you want to change trace file location for running server then you can make those changes on the Runtime tab.