InfoCenter Home >
8: Problem determination >
8.4: Traces
8.4: Traces
Traces are just logs.
Traces and logs differ in that you must turn traces on to see output in a
trace file. Logs are always enabled and log entries are automatically generated.
Tracing occurs at two levels:
- On administrative servers (usually one per node)
- On application servers
You can enable trace for each JavaTM class in the system.
The trace subsystem does not trace user code (such as
servlets or EJB components) unless System.err.println or System.out.println
statements are added to the code. Output from the println statements appears either
in the application server stdout or stderr logs.
See the stdout and stderr logs description for more information
on stdout and stderr logs.
Beginning with WebSphere Application Server Version 3.0,
an object level debugger is provided with the product to trace and debug user code.
See the Object Level Tracing and Debugging (OLT and OLD) section for information on object
level tracing.
Trace and log entry format
Since trace is just another log, both a WebSphere Application Server log entry and
a trace entry will have the same format. The following example of a log entry illustrates
the format:
Log entry example: [00.07.11 22:47:12:191 EDT] 53ccc3c5 ActiveEJBCont W Could not create bean
table xxx
The following table includes a description of each of part of the log entry:
[00.07.11 22:47:12:191 EDT] |
53ccc3c5 |
ActiveEJBCont |
W |
Could not create bean table |
xxx |
TS: The timestamp in fully qualified date (YYMMDD), Time (Millisecond precision), and Time zone format. |
TID: The thread ID or the hash code of the thread issuing this message. |
COMPONENT: The short name of component issuing this message. |
LEVEL: The level of the message or trace. Possible levels are:
- > Entry to a method (debug)
- < Exit a method (debug)
- A Audit
- W Warning
- X Error
- E Event (debug)
- D Debug (debug)
- TTerminate (exits process)
- F Fatal (exits process)
|
MESSAGE: The text of the message. |
ARGUMENTS: Optional message arguments. |
Types of traces
The following are the traces you will find in WebSphere Application Server:
View the following graphic for a description of the log and trace points in
WebSphere Application Server:
The trace file provides trace entries on the interaction of various WebSphere Application
Server components with the administrative server.
Use the trace file to identify a problem and to review events preceding the error situation.
Note: Always review trace entries prior to the error.
Trace entries recorded after the error has occurred represent program recovery and will not
help with problem determination.
Review the Collecting traces section for additional trace
documentation.
Trace file samples
On UNIX platforms, the nanny process starts the administrative server.
The nanny.maxtries parameter in the admin.config file tells the nanny process how many times
it should attempt to restart the administrative server.
On Windows NT, the nanny
service is part of the IBM WebSphere Administrative Server service that is registered with the
operating system.
Starting the IBM WebSphere Administrative Server service invokes adminservice.exe. If the
service does not
start, verify that:
- The service was installed and is available from Start > Settings > Control Panel > Services
- The userID under which WebSphere Application Server was installed has service privileges
If the nanny process fails to start the administrative server on UNIX or if the
IBM WebSphere Administrative Server service does not start on Windows NT, you can bypass the nanny
function and just start the administrative server. Follow these steps to start the administrative server:
- Go to the <WAS_root>bin/debug directory
- Invoke adminserver.sh on UNIX or adminserver.bat on Windows NT
Note: Starting the administrative server without using the
nanny function means that nothing is monitoring the administrative server. If it fails in this
state, nothing will restart it.
A nanny trace is only available on UNIX platforms.
On Windows NT, use the Event Viewer to view entries related to the WebSphere nanny service. Follow
these steps to view the Event Viewer :
- Select Start > Programs > Administrative Tools
- Select Event Viewer
- View events related to WebSphere Application Server
Nancy trace samples
The DrAdmin function generates thread dumps.
On UNIX platforms, the IBM JDK allows users to send signals to force javacore.txt files
to be created in the application server's working directory.
The application server continues to run and a sequence of javacore files are created. These files
can help in debugging "loop" or "system hang" problems.
To generate thread dumps similar to the javacore files, especially on a Windows NT
platform, use the DrAdmin function.
A unique DrAdmin port is generated each time an application server starts. To generate a thread
dump for that port:
- View the console messages area or the trace file
for message SMTL0018I "DrAdmin available on port."
- Enter the following command:
DrAdmin <port number> -dumpThreads
- Review the stderr log for the thread dump.
After installing and starting WebSphere Application Server, you will see DrAdmin entries in the
console messages area. These entries appear regardless of the options specified during installation,
and have the following format:
DrAdmin available on port 1,055
DrAdmin entries are also recorded in the trace file.
To locate the DrAdmin entry in the trace file:
- In the <WAS_ROOT>logs directory, open the trace file.
- Go to the bottom of the trace file and then scroll up until you locate the following entry:
DrAdmin available on port xxxx
DrAdmin is a service, provided by each of the servers, to enable and disable tracing. Each time a server starts, DrAdmin
registers itself on a different (next available) port number. There are no output messages associated with DrAdmin. The
DrAdmin entries in the console messages area are generated to tell users the port number where DrAdmin is listening.
You should always use the administrative console trace facilities to debug a problem.
DrAdmin is a diagnostic tool to be used when you have no other choices. It was designed to provide IBM support personnel
with another way of obtaining traces. Use DrAdmin in these situations only:
- When input to the administrative console is not accepted
- When the administrative server is in a wait state
- When the administrative server is not responding (e.g., in an infinite loop or
hung state)
- When you have to dump the thread stacks in a server
- When the administrative client topology tree disappears
Note:DrAdmin is an internal interface that is used to assist users with problem determination.
As an internal interface, it is subject to change at any time, and there is no national
language support for it.
The DrAdmin interface is the same on all platforms. Since DrAdmin is another way of
turning on a trace, the tracing mechanism is the same as the one used by the
administrative console trace facilities.
Therefore, whether you are looking at the trace file or a DrAdmin output file,
the trace entries will have the same format.
See the DrAdmin samples to learn how to invoke DrAdmin.
To specify the DrAdmin trace output in the admin.config file:
- In the admin.config file located in the <WAS_ROOT>bin directory,
append the following property where the file name consists of an absolute path and the file that you want to create:
com.ibm.ejs.sm.adminServer.traceOutput=<filename>
- Restart the administrative server.
The trace file specified in the admin.config file should be created during startup of the
administrative server. The administrative server might not start if the path specified for
file name does not exist, or if the directory permissions where the trace file
is to be created, are incorrect or insufficient.
- If the administrative server starts but the trace file is not created, ensure the traceOutput
parameter in the admin.config file is correct, and the path to the file exists.
DrAdmin samples
For more information on traces, see file What are messages, logs and traces?
|