Browse Prior Art Database

Dynamic scaling up or scaling down of the diagnostic trace level by mapping the scope to the problem area Disclosure Number: IPCOM000236960D
Publication Date: 2014-May-23
Document File: 7 page(s) / 103K

Publishing Venue

The Prior Art Database


Disclosed is a technique for dynamically adjusting the trace or logging level of the product component by defining the scope of the problem. This allows the effective problem determination by means of having an ability to set optimal tracing levels and at the same time reduce the overhead associated with excessive tracing or logging.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 47% of the total text.

Page 01 of 7

Dynamic scaling up or scaling down of the diagnostic trace level by mapping the scope to the problem area

In a Typical Software support methodology, any error reported that needs to be diagnosed, one of the most common and main approach is to enable the traces . The style of tracing may :

- create huge size of trace files if trace is enabled at the highest level of logging.
- make the system very slow due to high amount of I/O operations.
- can be restrictive on production machines due to performance overhead and hence difficult to obtain the traces from a production system .

- In case of cyclic or circular logging of trace , it may wrap or overwrite the trace and thus the chances of problem being captured in the trace reduces.

- Be difficult and time consuming to analyze the traces due to large data collected.

Another style of tracing is component based tracing. However, this captures only the problems happened in that particular component. The drawbacks of this technique could be :

- The error is captured in trace. However the root cause may not be in the component, but in the code that is surrounding the component. E.g. incorrect input value passed to the component, buffer not set properly etc.

- Once the control goes out side the component boundaries in case of the component making call to another component, the trace for external component is not captured .

- The trace is enabled for the component calls which may not be relevant to the error being diagnosed.

While diagnosing a specific error, generally the data around the affected functionality is looked at in more detail than the other instances of message processing.

Therefore all of that trace data which is captured far before or far after to the problem instance is not usually of that importance .

In order to control the trace around the affected area of a workflow, a methodology is described here to define the scope of the problem and logging level of tracing (normal / debug / FINE/ FINEST) for the suspected scope. A user may enable the trace at a 'normal' level for the entire workflow but can also define that - when the execution enters the defined 'scope' , the tracing level should get elevated to the more detailed level 'debug'/ FINEST. Thus, instead of having the trace running at debug (highest) level all the time, now it will be at the highest level only while message is being processed in that particular node/scope . Since the highest level of tracing is active only for subset of the overall workflow execution, the overhead will be relatively lower than the usual technique of tracing . There are no. of advantages of this proposed technique:

a)In case of the circular tracing mechanism, the trace wrap issues will be minimized


Page 02 of 7

which otherwise gets filled up very quickly due to end to end tracing activity (for highest level tracing) of the workflow .

b) More chances of problem getting captured in the trace even with smaller trace buffer sizes. Thus saving...