When to trace

You have to decide when you want tracing on and, once it is on, what entries to trace. Tracing is on when the application is creating some or all of its trace entries. Tracing is off when the application is not creating trace entries at any of its trace points. The decision to trace is based on the need to:

• Capture enough data to diagnose a problem.
• Minimize lines of code spent on tracing.
• Optimize the trace path when the trace is on so that tracing causes acceptable performance degradation.

The more trace entries you create, the greater the impact to performance.

Another consideration is whether you can recreate a problem if one arises. If you can recreate the problem, you might only turn tracing on after the problem occurs, and then restart the application. If you have to capture data about a problem before it occurs (frequently referred to as first failure data capture) you might choose to trace all the time, or at least at a minimum level. In summary, here are the options you should consider when deciding when to trace:

• Turn the trace on only when a problem occurs.
• Keep the trace on at all times, with the following choices:
  • Trace at a minimum level. (Tracing at a minimum level means creating trace entries at a minimum number of trace points, ignoring the remaining trace points.) This provides some data with a minimal impact to performance.
  • Define trace options to filter which trace entries will be created. By filtering out unneeded trace entries, the trace buffers will contain a higher proportion of useful data.
  • Create all trace entries. In this mode, the application does not support any options to filter the trace data or to turn off the trace. Use this mode if you are tracing a small number of events, or if your first failure data capture requirements outweigh the performance impact.