WO2011069837A1

WO2011069837A1 - A method for processing trace data

Info

Publication number: WO2011069837A1
Application number: PCT/EP2010/068230
Authority: WO
Inventors: Alan James Chatt; Cyril Peter Stewart; Christopher Colin Paice
Original assignee: International Business Machines Corporation
Priority date: 2009-12-11
Filing date: 2010-11-25
Publication date: 2011-06-16

Abstract

A method for processing trace data, comprising the steps of: determining whether the trace data comprises a subset of non-user data and a subset of user data; in response to determining that the trace data does comprise a subset of non-user data and a subset of user data; generating a unique key; writing the non-user data with the unique key to a first component; and writing the user data with the unique key to a second component, that is logically separate from the first component.

Description

A METHOD FOR PROCESSING TRACE DATA

FIELD OF THE INVENTION

The present invention relates to a method for processing trace data.

BACKGROUND OF THE FNVENTION

Tracing capabilities are commonly used in computer systems during performance monitoring or fault diagnosis processes. Most functional elements of computer systems may generate trace data.

Trace data (including textual data) from a trace operation can be stored in a trace file. If a trace operation captures trace data, trace data associated with the function (e.g., a function name) as well as, for example, application data (e.g., customer account number) is captured and written to the trace file.

If such a trace file needs to be analysed by a third party (e.g., a service team), analysis of the trace file by the third party could involve exposure of user data that is confidential.

Current solutions to this problem comprise, for example, the user manually analysing the trace file and removing any sensitive user data before analysis by the third party— this solution is time consuming (especially, for example, if there are many trace records) and error prone.

If it is acceptable for the third party to view sensitive user data but the user does not wish to send the trace file to the third party, another solution is for the third party to physically visit the user and read the trace file at the user's machine - this is not a timely solution and is not cost effective. DISCLOSURE OF THE INVENTION

According to a first aspect, there is provided a method for processing trace data, comprising the steps of: determining whether the trace data comprises a subset of non-user data and a subset of user data; in response to determining that the trace data does comprise a subset of non-user data and a subset of user data; generating a unique key; writing the non-user data with the unique key to a first component; and writing the user data with the unique key to a second component, that is logically separate from the first component.

According to a second aspect, there is provided an apparatus for processing trace data, comprising: means for determining whether the trace data comprises a subset of non-user data and a subset of user data; means, responsive to determining that the trace data does comprise a subset of non-user data and a subset of user data; for generating a unique key; means for writing the non-user data to a first component with the unique key; and means for writing the user data to a second component, that is logically separate from the first component, with the unique key.

According to a third aspect, there is provided a computer program comprising program code means adapted to perform all the steps of the method above when said program is run on a computer.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will now be described, by way of example only, with reference to preferred embodiments thereof, as illustrated in the following drawings:

Figure 1 is a block diagram of a system in which the preferred embodiment is implemented;

Figure 2 is a more detailed block diagram of the system of figure 1 ; and

Figure 3 is a flow chart showing the operational steps involved in a process according to the preferred embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

A preferred embodiment will now be described with reference to the figures.

An example of a block diagram of a system (100) in which the preferred embodiment is implemented is shown in figure 1 and comprises an application (105) having a tracing function (110). The tracing function (110) writes trace data during certain functional operations of the application (105).

A more detailed block diagram of the tracing function (110) is shown in figure 2 wherein the tracing function (110) comprises an analyser (200); a key generator (205) and an output component (210) operable to interact with a plurality of files (220 and 225). Note that any number of components can be used instead of a plurality of files (e.g., a plurality of memory areas; a plurality of connections).

In another example, the tracing function (110) can be implemented with a transport mechanism (e.g., TCP/IP), such as a network, wherein data is put and flows to a remote application which gets the data. In this example, the data is traced on entry to the transport mechanism and on exit from the transport mechanism.

The preferred embodiment will now be described with reference to figure 2 and figure 3, the latter of which is a flow chart showing the operational steps involved in a process.

At step 300, the tracing function (110) is called by the application (105).

The tracing function (110) receives passed trace data and the analyser (200), at step 310, analyses the passed trace data in order to determine whether it comprises any sensitive information.

The analyser (200) determines which portion of the passed trace data comprises non-user data (e.g., control information; execution path information) and which portion of the passed trace data comprises user data (e.g., personal information). This step can be implemented in a number of ways and details of example implementations are described below - examples of trace data to be used in the description are shown below.

Table 1 is a representation of trace data that is associated with an application and table 2 is a representation of trace data that is associated with a transport mechanism.

In table 1, the data comprises a function name (namely, "BalanceQuery"); a user's account name (namely, "John Doe"); and the user's account number (namely, "12345").

In table 2, the data comprises two IP addresses (namely, 9.20.1.1 and 9.20.4.6) and a user's name (namely, "Doe").

Table 1 :

BalanceQuery

AccountName=John Doe

AccountNumber= 12345

Table 2:

9.20.1.1

9.20.4.6 <data><Name>DOE</Name></data>

In one example, the analyser (200) uses a rule (e.g., wherein a first rule defines that the first parameter of passed trace data is associated with application (non-user) data and any remaining parameters are associated with user data). For example, in response to analysing the passed trace data represented in table 1 above in accordance with the first rule, data (e.g., "BalanceQuery") associated with the first parameter is identified as application data (e.g., wherein the application data comprises a name of a calling function associated with the application (105)) and data (e.g., "AccountName=John Doe" and "AccountNumber=12345") associated with the remaining parameters is identified as user data (e.g., wherein the user data is possibly sensitive information).

Similarly, if the preferred embodiment is used with a transport mechanism, typically, the passed trace data has some associated structure, such as header information (non-user data) and user data. Preferably, the analyser (200) uses the structure of the passed trace data such that the non-user data and user data can be identified. For example, when the passed trace data represented in table 2 is analysed in accordance with the structure, "9.20.1.1" is identified as non-user data and "9.20.4.6<data><Name>DOE</Name></data>" is identified as user data.

Alternatively, the analyser (200) can compare the passed trace data against a list of known parameters in order to determine non-user data and user data.

Alternatively, the analyser (200) can use a control block which can be used to pass information. An example of a control block is shown below wherein "count" is the number of data elements passed; "pfunctionName" is a pointer to the name of the calling function and "values[]" is an array of size "count" which points to the items:

{

integer count;

char pfunctionName

char values[]

} parms

In this example, using the passed trace data represented in table 1 :

"count" is equal to two (as there are two data elements, namely, "JohnDoe" and "12345"); "pFunctionName" is an address of "BalanceQuery";

values[0] is an address of "JohnDoe"; and

values[l] is an address of "12345". Alternatively, the analyser (200) uses a data structure having additional information passed in - for example type of data; length; and sensitivity level (e.g., wherein the latter data comprises a flag to denote whether the information is sensitive or not).

In the data structure below, "count" is the number of data elements passed in;

"pfunctionName" is a pointer to the name of the calling function; "values[]" is an array of size "count" which points to the items; "length[]" is an array of the lengths of the data in the values[] array; and "isConfidential[]" is an array which indicates whether values in the "values[]" array are sensitive:

{

integer count;

char pFunctionName

char values[]

long length[]

long isConfidential[]

} extendedparms

In this example, using the passed trace data represented in table 1 :

"count" is equal to two;

"pFunctionName" is an address of "BalanceQuery";

"values[0]" is an address of "JohnDoe";

"values[l]" is an address of "12345";

"length[0]" has a value of seven;

"length[l]" has a value of five;

"isConfidential[0]" has a value which maps to a flag "yes"; and "isConfidential[l]" has a value which maps to a flag "yes".

If the analyser (200), at step 310, does not identify sensitive data in the passed trace data (e.g., if there is no user data), the output component (210) writes (step 315) trace output to a first file (220). If the analyser (200) does identify sensitive data in the passed trace data, the key generator (210) generates (step 320) a unique key value.

The output component (210 writes (step 325) the key value and the identified non-user data to e.g., a first file (220) and writes (step 330) the key value and the identified user data to e.g., a second file (225). Thus, the non-user data and the user data are stored separately (e.g., logically or physically) from each other.

The key values in the first file (220are used as a locator for an associated record in the second file (225).

In an example wherein HTML files are used, the first file (220) is shown below, wherein "key 1" is associated with a first portion of user data and "key 2" is associated with a second portion of user data, wherein keyl and key2 are unique keys and the second file (225) (having an identifier "ConfidentialData.html") is also shown below:

File 1 :

<br><p>BalanceQuery</p>

<BR>

<a href="../ConfidentialData.html/keyl">Confidential data</a>

<BR>

<a href="../ConfidentialData.html/key2">Confidential data</a>

File 2:

<h3 id=keyl>JohnDoe</h3>

In another example, the first file (220) is shown below, wherein the values denoted by "ref=" are unique keys: File 1 :

"BalanceQuery",ref=3 ,ref=4

In the example, the second file (225) is shown below, wherein "ref=" is associated with a line number within the second file (225):

File 2:

In yet another example, a key value such as a time stamp can be used. In this example, representations of the first file (220) and the second file (225) are shown below, wherein the timestamps comprise "2009-11-0613:05:31.605932" and "2009-11- 0613:05:31.605937": File l :

"BalanceQuery",key=2009-l 1-0613 :05:31.605932,key=2009-l 1-0613:05:31.605937

File 2:

2009-11-0613:05:31.605932 JohnDoe

2009-11-0613:05:31.605937 12345

The present invention allows non-user data to be separately stored from user data. In comparison, examples of prior art trace output are shown below, wherein table 3 is a representation of trace output that is associated with an application and table 4 is a representation of trace output that is associated with a transport mechanism.

In table 3, non-user data is associated with a first parameter ("Function") and user data is associated with a second parameter ("UserData").

In table 4, non-user data is associated with a first parameter ("IP address") and user data is associated with a second parameter ("UserData").

Table 3:

Function : BalanceQuery

UserData:AccountName=John Doe

UserData: AccountNumber= 12345

Table 4:

IP address: 9.20.1.1 UserData:9.20.4.6<data><Name>DOE</Name></data>

With reference to the present invention, a third party, such as a service team, is preferably given access to the first file (220) and is preferably not given access to user data that is stored in the second file (225). The third party may require information from the second file (225) e.g., for debugging purposes. For example, this can occur because an error has been captured by a trace operation and the error appears to be associated with the user data - in this scenario, the third party may wish to review e.g., a certain field in the user data in order to understand an application flow. In such a scenario, the third party can send a request for the user data to a data owner (e.g., a customer) wherein the request preferably identifies the particular user data that needs to be sent— for example, if the second file (225) is in an HTML or XML format, XSLT can be used to select the relevant records. Alternatively, if a relative position in the second file (225) has been used as a key value, preferably, the relative position is used to select the relevant records. Alternatively, if the key value comprises a numeric value, a mechanism which selects records if certain criteria ("the value must match) are met can be used.

Subsequent to receiving the request, the data owner is able to determine whether the relatively small subset of identified user data can be sent (e.g., by determining whether the identified user data is of a sensitive nature). Advantageously, this process aids a third party to diagnose the error remotely, saving time and money. Advantageously, e.g., a customer can retain control over their sensitive information, and if disclosure of the information is required e.g., for debugging purposes, the customer need only examine the smallest possible portion of the information to determine whether it can be disclosed.

In another implementation , trace output can comprises binary data which needs to be formatted to make the trace output understandable - in such an example, a formatting tool can use a trace file(s) comprising the trace output and use a subset of the steps shown in figure 3 (steps 310 to 330) to produce formatted output in files 225 and 220

It should be understood that for each non-user data file, there can be zero or more associated user data files.

It should be understood that the output component (210) can use any number of media types. For example, non-user data can be written in main memory and user data can be written to a data space using e.g., operating system commands to dump data out to main memory and to dump data out to data space.

It will be clear to one of ordinary skill in the art that all or part of the method of the preferred embodiments of the present invention may suitably and usefully be embodied in a logic apparatus, or a plurality of logic apparatus, comprising logic elements arranged to perform the steps of the method and that such logic elements may comprise hardware components, firmware components or a combination thereof.

It will be equally clear to one of skill in the art that all or part of a logic arrangement according to the preferred embodiments of the present invention may suitably be embodied in a logic apparatus comprising logic elements to perform the steps of the method, and that such logic elements may comprise components such as logic gates in, for example a programmable logic array or application-specific integrated circuit. Such a logic

arrangement may further be embodied in enabling elements for temporarily or permanently establishing logic structures in such an array or circuit using, for example, a virtual hardware descriptor language, which may be stored and transmitted using fixed or transmittable carrier media.

It will be appreciated that the method and arrangement described above may also suitably be carried out fully or partially in software running on one or more processors (not shown in the Figures), and that the software may be provided in the form of one or more computer program elements carried on any suitable data-carrier (also not shown in the Figures) such as a magnetic or optical disk or the like. Channels for the transmission of data may likewise comprise storage media of all descriptions as well as signal-carrying media, such as wired or wireless signal- carrying media.

The present invention may further suitably be embodied as a computer program product for use with a computer system. Such an implementation may comprise a series of computer- readable instructions either fixed on a tangible medium, such as a computer readable medium, for example, diskette, CD-ROM, ROM, or hard disk, or transmittable to a computer system, via a modem or other interface device, over either a tangible medium, including but not limited to optical or analogue communications lines, or intangibly using wireless techniques, including but not limited to microwave, infrared or other transmission techniques. The series of computer readable instructions embodies all or part of the functionality previously described herein.

Those skilled in the art will appreciate that such computer readable instructions can be written in a number of programming languages for use with many computer architectures or operating systems. Further, such instructions may be stored using any memory technology, present or future, including but not limited to, semiconductor, magnetic, or optical, or transmitted using any communications technology, present or future, including but not limited to optical, infrared, or microwave. It is contemplated that such a computer program product may be distributed as a removable medium with accompanying printed or electronic documentation, for example, shrink-wrapped software, pre-loaded with a computer system, for example, on a system ROM or fixed disk, or distributed from a server or electronic bulletin board over a network, for example, the Internet or World Wide Web.

In an alternative, the preferred embodiment of the present invention may be realized in the form of computer implemented method of deploying a service comprising steps of deploying computer program code operable to, when deployed into a computer infrastructure and executed thereon, cause said computer system to perform all the steps of the described method.

It will be clear to one skilled in the art that many improvements and modifications can be made to the foregoing exemplary embodiment without departing from the scope of the present invention.

Claims

1. A method for processing trace data, comprising the steps of:

determining whether the trace data comprises a subset of non-user data and a subset of user data;

in response to determining that the trace data does comprise a subset of non-user data and a subset of user data; generating a unique key;

writing the non-user data with the unique key to a first component; and

writing the user data with the unique key to a second component, that is logically separate from the first component.

2. The method as claimed in claim 1, wherein a component comprises a storage medium.

3. The method as claimed in claim 2, wherein the storage medium comprises at least one of: memory and a file.

4. The method as claimed in claim 1, wherein a component comprises a connection.

5. The method as claimed in any preceding claim, wherein the determining step further comprises the step of at least one of: using a rule; using a data structure; and comparing the trace data with a set of known parameters.

6. The method as claimed in any preceding claim, wherein the unique key is used as a locator for user data associated with the second component.

7. An apparatus for processing trace data, comprising:

means for determining whether the trace data comprises a subset of non-user data and a subset of user data;

means, responsive to determining that the trace data does comprise a subset of non- user data and a subset of user data; for generating a unique key;

means for writing the non-user data to a first component with the unique key; and means for writing the user data to a second component, that is logically separate from the first component, with the unique key.

8. The apparatus as claimed in claim 7, wherein a component comprises a storage medium.

9. The apparatus as claimed in claim 8, wherein the storage medium comprises at least one of: memory and a file.

10. The apparatus as claimed in claim 7, wherein a component comprises a connection.

11. The apparatus as claimed in any of claims 7 to 10, wherein the determining means further comprises at least one of: means for using a rule; means for using a data structure; and means for comparing the trace data with a set of known parameters.

12. The apparatus as claimed in any of claims 7 to 11, further comprising: means for using the unique key as a locator for user data associated with the second component.

13. A computer program comprising computer program code stored on a computer readable medium to, when loaded into a computer system and executed thereon, cause said computer system to perform all the steps of a method according to any of claims 1 to 6.