Trace

If you cannot get enough information about a particular problem from the entries that are available in the various logs described in WebSphere Event Broker logs and Local error logs, the next troubleshooting method to consider is using trace. Trace provides more details about what is happening while code executes. The information produced from trace is sent to a specified trace record, so that you or IBM support personnel can analyze it to discover the cause of your problem.

Trace is inactive by default, and must be explicitly activated by a command, or by the workbench.

There are two main types of trace available in WebSphere Event Broker: user trace and service trace.Typically, you utilize user trace for debugging your applications; you can trace brokers, execution groups, and deployed message flows. With service trace, you can activate more comprehensive broker tracing, and start tracing for the workbench, Configuration Manager, and User Name Server. You can also trace the execution of all the commands described in Commands.

When you start user tracing, you cause additional processing for every activity in the component that you are tracing. Large quantities of data are generated by the components. Expect to see some impact on performance while trace is active. You can limit this additional processing by being selective about what you trace, and by restricting the time during which trace is active.

Related concepts
Logs
Related tasks
Starting user trace
Checking user trace options
Changing user trace options
Retrieving user trace
Stopping user trace
Starting service trace
Checking service trace options
Changing service trace options
Retrieving service trace
Stopping service trace
Formatting trace
Interpreting trace
Clearing old information from trace files
Related reference
WebSphere Event Broker logs
User trace
Service trace
mqsichangetrace command
mqsiformatlog command
mqsireadlog command
mqsireporttrace command