Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Storing diagnostic data in a database for offline analysis

IP.com Disclosure Number: IPCOM000188229D
Original Publication Date: 2009-Sep-28
Included in the Prior Art Database: 2009-Sep-28
Document File: 2 page(s) / 45K

Publishing Venue

IBM

Abstract

Offline analysis of diagnostic data is vital for understanding any issues that have occurred during the operation of a system. The storage of that offline data is in the form of files, whether in a proprietary format, XML, flat text. That data must then be parsed manually through the use of further analysis tools. Having multiple data files also results in the need to have a mechanism to cross-reference between the various files; tracking requests through a multi-tier system for example. This can be a complex task.

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

Page 1 of 2

Storing diagnostic data in a database for offline analysis

Offline analysis of diagnostic data is vital for understanding any issues that have occurred during the operation of a system. The storage of that offline data is in the form of files, whether in a proprietary format, XML, flat text. That data must then be parsed manually through the use of further analysis tools. Having multiple data files also results in the need to have a mechanism to cross-reference between the various files; tracking requests through a multi-tier system for example. This can be a complex task.

    Rather than storing the offline diagnostic information in the "traditional" way utilizing files or "flat formats" , a system stores its diagnostic information directly into a database. By utilising the "standard" storage mechanism of a database, the mechanism handles the fine details of the actual physical storage and formatting of the data. Multiple diagnostic outputs can be input into the storage mechanism providing a central location for all diagnostic information. By having all the diagnostic data within the one location, it then becomes possible to simply interrogate that storage medium to have suitable data returned, including "

j

    By providing a framework in a system that writes diagnostic information to the storage application rather than to files, when the system needs to output some diagnostic message (for example trace or logging output), it provides the message to the storage application in a pre-determined format whereupon the storage application assumes responsibility for the actual storage of that message. For a database, that format would be defined in a schema. By containing suitable table and column headers, it would be possible to track requests across multiple products that stored their information in the database.

Example:

    Application A (AppA) communicates with Application B (AppB) through the use of named pipes (ie. both AppA and AppB are resident on the same machine). Requests made from either application contain suitable eyecatchers allowing the request to be tracked in trace diagnostic output for the other application. Under "normal" trace/log infrastructure, the trace files for both applications would need to be investigated simultaneously to track requests. By implementing the invention, the diagnostics from both AppA and AppB are "written"...