Interpreting Trace Files

Introduction to Runtime Tracing

When enabled, runtime tracing writes tuple trace information to StreamBase Server's console or to a trace file, one file per container. If any component or module in your application uses concurrency features, then a separate trace file is created for each separate parallel region. (See Execution Order and Concurrency for more on concurrency.)

The default trace information is a single timestamped line per tuple. Each tuple is shown as received at each operator and stream in the application. Trace files can grow quite large very quickly, so runtime tracing is best used only for short bursts, for debugging only, to follow a tuple's progress through an application.

You can limit the number of operators and streams that are subject to tracing by using a regular expression to narrow the list of the components of interest.

Tracing does not occur unless you enable tracing by setting streambase.codegen.trace-tuples to true in a HOCON configuration file of type c.t.e.streambase.c.sbengine, in the StreamBaseEngine root object. For example:

name = "sbengine"
version = "1.0.0"
type = "com.tibco.ep.streambase.configuration.sbengine"
configuration = {
  StreamBaseEngine = {
    systemProperties =
     "streambase.codegen.trace-tuples" = "true"

You can manage settings for your trace session as described in Configuring Runtime Tracing

Trace files have the extension .sbtrace, or .sbtrace.gz for compressed files. Trace files are stored with UTF-8 encoding, which preserves any Unicode characters in tuple fields in the trace file.

Tracing Versus Dequeuing

Runtime tracing is similar to, but not the same as using sbc dequeue to dequeue tuples from any stream in your application, including intermediate streams, if enabled (see Intermediate Stream Dequeuing). The following table shows the differences between runtime tracing and dequeuing.

Feature Standard Dequeuing Runtime Tracing
See tuple output from ... All explicit streams by default, and all intermediate streams if enabled. All operators and streams (optionally limited by regular expression selection).
Timestamp shown for each tuple No Yes
Save output to a file or console Must redirect console output or use an output adapter. Specify with a runtime option.
Starts with StreamBase Server No. It takes time to start the Server, then start a dequeuing client. The first few tuples can be missed. Yes. Even the first few tuples are captured.
Can see tuple output in StreamBase Studio Yes. Yes. Trace files can be opened, searched, and stepped through in Studio's SB Trace Debugger perspective.

Configuring Runtime Tracing

Configure runtime tracing with one of three methods:

  • Specify configuration settings in a HOCON configuration file of the type c.t.e.streambase.c.sbengine type, in the EventFlowDeployment root object. See the modules > trace properties, as described in the following table.

  • Use the sbadmin addContainer command at runtime with its --trace* options.

  • Use the sbadmin modifyContainer command at runtime with its trace true and trace false subcommands, and its --trace* options.

All three methods invoke the same options, described in the following table:

HOCON property sbadmin option Default Description
"matchOperatorAndStreamRegexp" = "pattern" --traceStreamPattern="pattern" none

Specify a regular expression pattern in the format of java.util.regex.Pattern. The pattern limits tracing to the operators and streams whose name matches the specified pattern.

If not specified, tracing is active for all operators and streams in the application.

fileBase="basename" --traceFileBase="basename" none

By default, trace output is written to StreamBase Server's console. To redirect trace output to a file, specify traceFileBase with a basename argument.

There is one trace file generated per module, including one trace file for each parallel region in a module. Specify a string to serve as the basename for trace files. Trace file names are generated as basename+containername.sbtrace. For modules running with parallel execution enabled, the module's path becomes part of the trace file name: basename+containername.modulepath.sbtrace.

overwrite="true" --traceOverwrite false

For the <trace> deployment file element, specify "=true" or "=false" (default). For the sbadmin option, use the option without arguments to set the true state.

Setting to true causes tracing to overwrite all trace files on StreamBase Server startup. Setting to false (the default) causes new trace information to be appended to existing trace files for each traced container.

compress="true" --traceCompress false

For the <trace> deployment file element, specify "=true" or "=false" (default). For the sbadmin option, use the option without arguments to set the true state.

Set to true to specify that the generated trace file is to be compressed with gzip. If true, the trace file's extension becomes .sbtrace.gz. Compressed trace files are readable by Studio's Trace Debugger perspective.

buffered="false" --traceBuffered=true


true When set to false, the output trace file is flushed on every trace line. This slows down performance considerably, but makes it easier to use tracing as part of debugging a live application. When set to true (the default), tracing output is buffered before the trace file is written, to minimize tracing's drag on performance.

Tracing is enabled by default when the application starts. You can disable tracing at runtime with sbadmin modifyContainer containerName trace false. In that case, re-enable tracing with sbadmin modifyContainer containerName trace true. As soon as you disable or stop tracing, all trace files are closed.

Format of Trace Files

Trace files consist of one header line (shown below on two lines for publication clarity), plus one trace line per tuple received at each specified operator and stream. The following example shows the start of a trace file for the Best Bids and Asks sample shipped with StreamBase, running in the default container named default:

# ms since epoch, tupleid, operator/streamname, tuple-data - \
  trace started: 2010-11-04 16:09:22.200-0400 - 1288901362200ms

Trace lines consist of at least four fields, described in the following table:

Field Description
1 Timestamp in milliseconds representing the interval of time since the epoch.
2 Tuple ID.
3 Fully qualified name of the operator or stream output port.
4 through n The comma-separated fields of the tuple as it exits the port described in field 3.

Back to Top ^