You can use trace to monitor and troubleshoot your environment.
You must provide trace for a server when you work with IBM® support.
About this task
Collecting trace can help you monitor and fix problems in
your deployment of
WebSphere® eXtreme Scale.
How you collect trace depends on your configuration. See
Server trace options for a list of the different trace
specifications you can collect.
Procedure
- Collect trace within a WebSphere Application Server environment.
If your catalog and container servers are in a WebSphere Application Server environment, see WebSphere Application Server:
Working with trace for more information.
- Collect trace with the stand-alone catalog or container
server start command.
You can set trace on a catalog
service or container server by using the
-traceSpec and
-traceFile parameters
with the start server command. For example:
startOgServer.sh catalogServer -traceSpec ObjectGridPlacement=all=enabled -traceFile /home/user1/logs/trace.log
The -traceFile parameter
is optional. If you do not set a -traceFile location,
the trace file goes to the same location as the system out log files.
For
more information about these parameters, see startOgServer script .
- Collect trace on the stand-alone catalog or container
server with a properties file.
To collect trace
from a properties file, create a file, such as a server.properties file,
with the following contents:
workingDirectory=<directory>
traceSpec=<trace_specification>
systemStreamToFileEnabled=true
The
workingDirectory property
is the root directory for the logs and optional trace file. If the
workingDirectory value
is not set, the default working directory is the location used to
start the servers, such as
wxs_home/bin.
To use a properties file during server startup, use the
-serverProps parameter
with the
startOgServer command and provide the
server properties file location.
For more information about the
server properties file and how to use the file, see Server properties file.
- Collect trace on a stand-alone client.
You can start
trace collection on a stand-alone client by adding system properties
to the startup script for the client application. In the following
example, trace settings are specified for the
com.ibm.samples.MyClientProgram application:
java -DtraceSettingsFile=MyTraceSettings.properties
-Djava.util.logging.manager=com.ibm.ws.bootstrap.WsLogManager
-Djava.util.logging.configureByServer=true com.ibm.samples.MyClientProgram
Fore
more information, see
WebSphere Application Server:
Enabling trace on client and stand-alone applications.
- Collect trace with the ObjectGridManager interface.
You can also set trace during run time on an
ObjectGridManager interface.
Setting trace on an
ObjectGridManager interface
can be used to get trace on an
eXtreme Scale client while it connects
to an
eXtreme Scale and commits
transactions. To set trace on an
ObjectGridManager interface,
supply a trace specification and a trace log.
ObjectGridManager manager = ObjectGridManagerFactory.getObjectGridManager();
...
manager.setTraceEnabled(true);
manager.setTraceFileName("logs/myClient.log");
manager.setTraceSpecification("ObjectGridReplication=all=enabled");
For more information about the ObjectGridManager interface,
see Interacting with an ObjectGrid using the ObjectGridManager interface.
- Collect trace on container servers with the xscmd utility.
To collect trace with the
xscmd utility,
use the
-c setTraceSpec command. Use the
xscmd utility
to collect trace on a stand-alone environment during run time instead
of during startup. You can collect trace on all servers and catalog
services or you can filter the servers based on the ObjectGrid name,
and other properties. For example, to collect ObjectGridReplication
trace with access to the catalog service server, run:
xscmd -c setTraceSpec -spec "ObjectGridReplication=all=enabled"
You can also disable trace by setting the trace specification to
*=all=disabled.
Results
Trace files are written to the specified location.